何がうまくいかないかについての知識の増加による遅い問題解決の克服
これはしばらくの間私を悩ませてきました、そして私は他の専門家の意見を本当に感謝します。
短い背景：1988年に両親が最初のコンピューターを購入したときにプログラミングを始めました（14歳で、現在は39歳です）。私は他のいくつかのキャリアパスをたどり、1997年にようやくプロのプログラマーになりました。後期ブルーマーかもしれませんが、それはそうでした。私はまだ自分の選択に満足しており、プログラミングが大好きで、自分の仕事に長けていると思っています。
最近、経験を積むほど、プロジェクトやプロジェクトの特定のタスクを完了するのに時間がかかることに気づきました。私はまだ老人になりません。それは私が物事がうまくいかないことができる非常に多くの異なる方法を見てきたことです。そして、私が知っていて覚えている潜在的な落とし穴や落とし穴がどんどん増えています。
簡単な例：以前は「大丈夫、ここにファイルを書き込んでください」でした。現在、権限、ロック、同時実行性、アトミック操作、間接指定/フレームワーク、さまざまなファイルシステム、ディレクトリ内のファイル数、予測可能な一時ファイル名、PRNGのランダム性の品質、途中での電力不足について心配しています操作、私がやっていることのための理解可能なAPI、適切なドキュメントなどなど.
要するに、問題は「これをどのように行うのか」から「それを行うための最良/安全な方法は何か」に移ってからずっと長い間です。
結局のところ、プロジェクトを完了するには、初心者よりも時間がかかります。私のバージョンはしっかりしていて、私がそれを作る方法を知っているのと同じくらい浸透できないかもしれませんが、それはもっと時間がかかります。
上記の「ファイルの作成」の例は、まさにその例です。実際のタスクは明らかに複雑ですが、このような一般的な質問にはあまり適していません。私がこれでどこへ行くのか理解していただければ幸いです。私は効率的なアルゴリズムを考え出すことに問題はありません、私は数学が好きです、私は複雑な主題を楽しんでいます、私は集中力に問題はありません。私は経験に問題があると思います。その結果、エラー（本質的または非本質的）の恐れがあります。
私は1日2時間近くかけて、新しい開発、新しい技術、言語、プラットフォーム、セキュリティの脆弱性などについて調べています。難問は、私がより多くの知識を得るほど、プロジェクトを完了するのに時間がかかるということです。
これにどう対処しますか？
プロジェクトの完了が遅くなることはありません。以前は、初心者のプロジェクトは実際には行われていなかったときに行われると考えていました。この品質をクライアントに販売する必要があります。
「この会社はそれをより速く、より安価に行うかもしれませんが、それは本当に行われますか、それとも何年もの間バグを捜し求めますか？」
それを超えて、あなたは古い慣用句を知って受け入れる必要があります：「完璧は善の敵です」。
ダークサイドに参加するときがきたようです。管理です。
プログラミングをあきらめてマネージャーになることはお勧めしません。しかし、これまでに引用したすべての経験は、本質的に技術的なもののようです。ファイルを書き出すという簡単な操作では、成熟度の低い開発者が決して考慮しない10の異なる側面を考えることができます。必ずしも悪いことではありませんが...
ダークサイドはすべて現在の価値です。最大の利益を得るために最小限の投資をすることです（費用便益分析）。ビジネスにおいて、すべては、これが私にどれだけのコストをかけるか、成功の確率、失敗の確率、壮大な失敗の確率、そして潜在的な利益に要約されます。計算する;それに応じて行動します。
これは、開発者の場合も同様に機能します。一時ファイルを作成し、権限と名前の衝突を無視して-5分。最終的に、チームの他のメンバーは、そのファイルの存在に依存するコードに取り組み始めることができます。それは完璧な解決策ですか？絶対違う。 99％、95％、たぶん90％になりますか？そうだろう。
もう1つ質問：技術的負債についてどう思いますか？一部の人々はそれを排除する必要があると思います。それらの人々は間違っていると思います。ビジネスと同じように、技術的負債は「現金」または「時間」を借りて、より早く何かを提供することを可能にします。何が良いか：2年間で完璧なソリューション、または顧客が4か月で使用して購入できる完全なハック？すべての状況は異なりますが、場合によっては、2年待つと、顧客はすでに競争にサインアップします。
重要なのは、よく経営されている企業が金融債務を管理するのと同じ方法で技術債務を管理することです。十分に引き受けないと、最適な投資収益率が得られません。やり過ぎると、興味が殺されてしまいます。
だから私のアドバイス：あなたの徹底を最大化するのではなく、あなたの価値を最大化するかどうかに基づいてあなたの仕事の評価を開始します。そして、これを実践すれば、あなたの技術分野ですでに開発したのと同じ直感を開発するでしょう。
補足として、私は最近 pomodoroテクニック を始めました、そしてそれは多くを助けました。接線の接線をとるのではなく、短い時間間隔で焦点を合わせて、将来の作業/研究のためにポモドーロを割り当てます。トピックを研究するために何度もメモをとったのは驚くべきことですが、その時が来て1時間後には、「今日の時間を使ってできることは他にももっと価値のあるものは少なくとも3つある」と私は思いました。
私は（おそらく）同じ問題を何年も前に経験しましたが、数年続き、それを克服しました。私のやり方があなたにも当てはまるかどうかわからない場合でも、私がそれをどのように達成したかを知ることは、あなたにとっていくらか興味があるでしょう。
こちらもご覧ください： ソフトウェアエンジニアリングの専門知識の7つの段階 生産性の大部分がスキルレベルの副作用であることを示しています。現在使用しているテクノロジーについて、まだステージ3とステージ4の間のどこかにいる可能性があります（スキルの習熟度はテクノロジーに依存します。他のテクノロジーを習得しながら、いくつかのテクノロジーを習得できます）。
今私は伝記の証言から始めます。
少しコンテキスト。私は47歳です。80年代の12歳からプログラミングを始めました。高校在学中は、非常勤のゲームプログラマーとしても働いていました。基本的に、ハードウェアを購入するのに十分なだけのお金はありませんでしたが、楽しんで多くを学びました。 18歳で、コンピュータサイエンスの正式な学習を始めました。
その結果、20歳になったとき、プログラミングタスクを開始するときはいつでも、与えられた問題を解決する多くの方法を知っていて、手元にある多くのパラメーターと落とし穴、あらゆる方法の欠点と限界を非常に意識していました。
ある時点（例えば26歳くらい）で、プログラムを書くのが本当に難しくなりました。非常に多くの可能性が開かれたので、私はそれらから選択することができなくなりました。数年間（6にする）、プログラミングをやめてテクニカルニュースライターになりました。
それにもかかわらず、プログラミングを完全にやめようとはしませんでした。そして、ある時点で戻ってきました。私にとっての鍵は、極端なプログラミング、より具体的には、シンプルさの原則、「おそらく機能する最も単純なものを書く」でした。
基本的に私は自分自身にコードの効率性（それが私の主要な障害であり、非効率的な設計を回避すること）を気にしないように強制しましたが、最も簡単な方法を実行します。エラーを発生させるテストを作成した後、エラーについてあまり気にせず、エラー処理を後で実行するように強制しました（実際はTDDです）。
それは私が書いているときに学んだことです。何を書けばよいかわからないとき、または書いていたことが悪いだとわかったとき。続けて。実際に悪いものを書いてください。最終的には後で修正します。あるいは、それが本当にそれを消去して書き換えるのが本当に悪いのですが、最初に完璧なものを書くものを2回書いた方が速いです。
実際、最初に書くのが得意であると信じるコードは、本当に悪いコードと同じくらいの改善が必要になる可能性が非常に高いです。
Simplicityパスをたどると、ボーナスも追加されます。初期設計/コーディングの削除/変更を簡単に受け入れることができます。あなたはより柔軟な心を得ます。
また、コードに一時的なコメントを付けて、今やっていなかったことを説明し、通常のユースケースでコードが機能するときに後で実行するつもりでした。
私もXP Dojoに参加しましたXP実践を内面化するために他のプログラマーと一緒に実践的なコードカタに参加しました。それは助けになりました。それは上記の正式な方法を本能的にしました。ペアプログラミング若いプログラマーと一緒に作業することで勢いが増しますが、経験を積むと、そうでないこともわかります。たとえば、私の場合、彼らが過度に複雑なデザインに従事していることがよくあり、それにつながる可能性のあるデザインの悪夢を知っています。 。それをした。問題があった。
私にとって最も重要な点は、流れを保つことです。高速であることは、流れを維持することに本当に成功しています。
今、私はプロのプログラマーとして戻ってきました。自分が何をしているのかをより深く理解することで、私はより良く、より速くなったと信じています。 TDDを練習しているときは、私が若い雄牛だったとき（そして何もテストしなかったとき）よりも少し遅いかもしれませんが、リファクタリングの心配はなく、デバッグに費やす時間もほとんどありません（ほとんど時間がないため、時間の10％未満にしてください） ）。
要約：アジャイルメソッド（XP）を使用してコードブロックを克服し、単純化してからリファクタリングを行い、本能的にするために練習しました。それは私のために働いた。他の人に一般化できるかどうかはわかりません。
スキル習得レベルに関しては、テクノロジーを変更するたびに（新しい言語、新しいフレームワークなどを習得すること）、減速している段階を通過することを受け入れることを主に学びました。これは正常であり、最終的にはそれを克服します。私はまた、優れた方法論と汎用プログラミングスキルでそれを補うことができ、それほど問題にはなりません。
プログラミングの重要な部分は複雑さの管理と制御であり、個人的には、これは最大の問題の1つです。無視すると、欠陥の頻度が急増するか、またはあなたの場合のように、完成したソフトウェアのETAが劇的に増加します。
ソフトウェアの複雑さは、さまざまなレベルと方法で制御および管理できますが、ある程度の見方を得るための良い経験則は、「ソフトウェアプロジェクトの最優先事項は、期待の関数である顧客満足度です」です。
言い換えれば、ソフトウェアの複雑さは、顧客の期待をどのように制御できるかによって大きく左右されます。
その見方を採用すると、2つの重要な点が明らかになります。
- 顧客の期待を明示する必要があります（どのような形式でも）。
- 顧客の期待はいつでも変更でき、それは交渉の芸術を通して行われます。
あなたの例は非常に良いものです、「単にそれを書いて」vs「他の無数の考慮事項」。それについて考えてください-誰かが両方のバリアントの徹底的な要件を書き留めた場合、説明された機能に同等のものがあるかどうか？
F16の構築はセスナの構築とは異なりますが、どちらも飛行できます。
簡単な答えは、それを受け入れることです。
すべてのシステムで、信頼性、堅牢性、セキュリティ、速度、ハードウェアコスト、開発コスト、製品化までの時間の間でトレードオフが発生します。顧客がこれらのトレードオフをどのように行うかに常に同意するわけではありませんが、それらを決定するのはあなたではありません。あなたができるすべては考慮された意見を提供することです。ソフトウェア開発は、「私の個人的なWebページ」から「原子炉の運転」までの全範囲をカバーしており、それに応じてコードを記述する必要があります。クラッシュが「個人のWebページをリロードする」ことを意味する場合、それが発生した場合、誰が本当に気にしますか？しかし、クラッシュが「チェルノブイリ」を意味する場合、堅実なコードの好みは、私の好みに少しカジュアルなものです。
「概念実証」レベルのコードを喜んで受け入れ、実際のシステムで実行するクライアントもいますが、多くの場合、それに慣れているシステム管理者がいます。 IMEのシステムは通常、一連のスケジュールされた再起動が行われている真夜中の1時間程度は使用できません。しかし、彼らはそれが彼らが転がしたい方法であるというビジネス上の決定をしました。理想的には、彼らの分野は非常に動きが速く、高品質のコードを準備することができないためです。お金）。煩わしすぎる場合は、それらのクライアントを避けてください。
最新の状態に保つことは、私たち全員が費やさなければならない時間、または少なくとも費やすべき時間です。時にはそれがあなたを働かせてくれることもあれば、単にあなたの心を良い状態に保つだけのこともあります。どちらにせよ、楽しんでみてください。
あなたのスキルは、金融/取引関連アプリケーション、放送、航空宇宙、防衛などの非常に高品質のミッションクリティカルなシステム開発に非常に役立つと思われます...
この種のアプリケーションのエラーは非常にコストがかかり、すべてのケースをカバーできるため、あなたのように考える人を雇います。
真実は、現代のシステムがますます複雑になっているということです。コンピュータは、今ではゲーム「ジェンガ」に似ており、これらのすべてのピースが他の多くのゲームに依存しています。間違った部分を引き出すとエラーが発生し、正しい/必要な部分を引き出すと、エラーが発生する可能性があります。システムが複雑になるほど、コードをより堅牢にする方法を考えるのに費やす時間が長くなり、うまくいけばより安全になります。速度はいいですが、最近、「XYZ」会社がハッキングされ、600万人の顧客のクレジットカード番号が盗まれたというニュースを聞くと、速度は後回しになります。
クライアントは、プログラムが安全で堅牢である必要があることなどを聞きたくないかもしれません。しかし、車にはシートベルトやエアバッグは必要なく、家にはロックやドアも必要ないということを伝えることができます。それ？
考えすぎている場合は、「具体的」と思われる戦略を選択してそれを実行する必要があることを除いて、正しい方向に進んでいます。
問題が発生する可能性のあるすべてのものについて考える傾向に気づいているようです。
経験豊富な慎重な開発者はしばしばマントラYAGNIに従うことを学びます。失敗モードの雑草に詰まりすぎて無駄のない、俊敏で生産的なワークフローに戻ろうとするとき、あなたはそれを必要としないでしょう。分析が消えてしまった。
ただし、そのレベルのケアがプロフェッショナリズムが要求するもの以上の領域で実際に何かを書いている場合、「速度」、「生産性」は正味の点でどれだけ優れているかで測定できることを理解する必要があります（または害）あなたはあなたの会社、あなたの顧客、そしてあなたが構築または維持しているソフトウェアスイートまたは製品ファミリーに対して行っています。
覚えておいてください：
アプローチの変更を検討する場合は、保守の総コスト、総所有コスト、ソリューションの展開と保守の総コストを含めます。より速く進み、より多くの間違いをすることは、物事をより良くするかもしれませんし、しないかもしれません。
あなたが良い会社で働いているなら、あなたはおそらくあなたのチームで、そしてあなた自身のスーパーバイザーとこれについて話し合うことができます。それができない場合は、今こそそれを見つけて新しい仕事を見つける良い機会です。
私が見ることができるのは「あなたはますます価値が増している」ということです。
あなたがより多くの経験を積むと、あなたは避けるべきことについて学びます、そしてこれは他の人よりあなたを良くするものです。
コードの安全性と保守性が向上することにお気づきでしょう。
- あなたがする必要があるのは、なぜそれが時間がかかったのか、そしてそれが彼らにとってどのように役立つのかをクライアントに説明することだけです。
- あなたは彼らにあなたの知識の深さを示す必要があります。
- あなたは彼らになぜあなたがしたのか、あなたが何をしたのか、そしてそれが彼らと彼らのビジネスにどのように関係するのかを伝える必要があります。
私の提案は、この部分に集中することです。
私はコーディング標準に固執する必要があると思いますが、クライアントに前向きであることを確認してください。多くのクライアントは、優れたソフトウェアを構築するのに必要な費用を知りません。それらを教育することは、プロの開発者の仕事の一部です。
アジャイルであろうとウォーターフォールであろうと、アプリケーションから期待されることについてクライアントから何らかの同意を得ます。 sandbagging の罪を犯している開発者が多すぎます（多分もっと多くの営業担当者）。 「彼らは彼らが非常に安全なウェブサイトを望んでいると言っていませんでした。」ほとんどの場合、それは彼らが尋ねられなかったからです。 「eコマースサイトがハッキングされてもよろしいですか？」もちろん彼らは気にしているのですが、なぜセキュリティを侵入させるためにそれを構築するのでしょうか？あなたはそれらを教育する必要があります。
クライアントがあなたに支払うように支払っていることだけを実行していることを確認してください。あなたのサービスの一部はあなたの経験です。クライアントは、質問することなく、落とし穴を知っていることを期待しています。要件を含めるのは彼ら次第です。あなたは何か安いものを望んでいるクライアントに伝えたいかもしれません。
疑わしい場合、デフォルトでKnuthをひどく引用する...
"早期最適化はすべての悪の根源です。"
私が時々問題を抱えているように見えるので、これが私が提案するものです...
私にとって本当に効果的なのは...
- すべてのコードが実行されたかのように、単体テストを記述します。
- インターフェースを文書化します。
- インターフェイスを実装します。
あなたが本当にやったこと：
- モデルレイヤーの要件に取り組む
- 実際に作業の分割を設定します。どのオブジェクトが
- 実際に作業中のコードをステップ実行できる環境で作業できるようになるため、物事がより速く、より正確になります...
また、開発の初期段階ではアサートに依存しています...次に、実装する必要のある救済策を見つけ出し、到達不能なコードやテストが難しいコードを記述しないようにします。
バグを解決する必要がある他のすべての問題と比較した場合の実際的な結果について考えてください。
不完全に記述されたコードを作成した場合の以下の影響を考慮してください。
- データベース全体が隔月でダンプされます。バックアップの復元中の48時間のダウンタイム。
- 顧客レコードは相互リンクされます。毎月200ドル相当の注文が間違った顧客に発送されます。
- 注文が週に1回、間違ったステータスでスタックします。発送は注文しますが、倉庫は、発生するたびにヘルプデスクに連絡する必要があります。
- 2週間ほどでアプリがクラッシュし、ユーザーは2分のデータを再入力する必要があります。
- 月に一度、アプリは起動時にハングします。ユーザーはプロセスを終了してやり直す必要があります。
最初のものは明らかに受け入れられません。 ＃2-＃5は、ビジネスの性質によって異なります。 ＃2-＃5は、ビジネスが直面している他の問題のコンテキストで評価する必要があります。
理想的には、＃2-＃5は決して起こらないでしょう。現実の世界では、優先順位が競合しているため、給料に署名する人は、決して問題が発生しない完璧なコードを作成するのではなく、他のことに取り組んでほしいと思うかもしれません。別のプログラムのより深刻なバグを修正しないことを犠牲にして＃5が修正されても、彼らは感心しないでしょう。
解決策は、プロジェクト全体で再利用できる、一般的に使用される関数を含むライブラリのコレクションを作成することです。例えば。エンコード、暗号化、復号化、正規表現の評価などを行うStringFunctions.dll .NETライブラリがあります。これにより、変更されないものを継続的に書き直す必要がなくなります。
ファイル作成タスクのラッパーを持つことも、非常に理にかなっています。ライブラリは、すべてのチェックを行い、nullまたはファイル（またはユーザーが有用と考えるもの）を返すGetFile（）と呼ばれるメソッドを公開できます。
どのプロジェクトに対してどれだけのことをする必要があるかを決めることを学ぶ必要があると思います。一部のプロジェクトは簡単なものであり、完全にするためにそのすべての時間を費やす必要はありません。すべてが堅固な暗号化を必要とするわけではなく、すべてが100万人のユーザーに拡大することはありません。
100万人以上のユーザーに適切に拡張できるプログラムを作成するには、現在の時間と経験が必要ですが、アプリケーションが最大1000ユーザーを超えて使用されないことがわかっている場合、すべてを費やす意味はありません。その時それを完成させます。
これはあなたのプログラミングキャリアの重要な段階だと思います。次のレベルに進む必要があります。これは、プログラミングではなく成熟度に関係しています。特定のプロジェクトに十分な時間とコードで十分かどうかを正しく判断できる必要があります。
そして、他のすべてのように、あなたも練習でこれを達成することができます。そのため、プロジェクトを開始する前に、すでにプロジェクトに取り組んでいるときでも、これを決定してみてください。経験を積むと、それを乗り越えることもできます。最初はいくつかのヒットとミスがあるかもしれませんが、時間の経過とともにそれを完成させます（コードではなく、意思決定）。
もう1つのオプションは、コードの作成をやめることです。代わりに、問題を事前に発見するための専門知識を売り込んでください。
つまり、コンサルタントになります。
多くの組織は、誰かが問題を発見するために前に問題を引き起こすコードの作成に何ヶ月も費やすために、高額のドル（高額でない場合）を喜んで支払います。設計のバグを修正することは、コード化、テスト、および配備した後で修正するよりも桁違いに安価/簡単であることはよく知られています。
あなたはそれほど多くのコードを書かないでしょう、そしておそらくそれを逃すかもしれません、しかしそれからコードの実際の行はあなたのコアの強さではないようですが、whichコード行を記述する必要があります-記述すべきではありません。
あなたの強みに焦点を当ててください。
（まあ、それがあなたが楽しむものなら...）
@Zilk、私は素晴らしいプログラマではなく、1998年からプログラミングをしています。今でもこの問題に直面しています。しかし、私が気づいたのは、最終的には品質の問題です。今日私が死んだら、誰かが今行っていることを去ったところから拾うことができるはずです。これはプログラミングの標準であるべきです（ユニバーサル）。
私は今、開発者から建築家に転向しました。管理に移行することで、状況が変わります。情熱を持ち続けたい場合は、建築家になるために移動できます。
最初はテクニカルアーキテクト->ソリューションアーキテクト->エンタープライズアーキテクト->チーフアーキテクトなど。
アーキテクトとして、あなたは人々を成功へと導きます。何十年もプログラミングをしているあなたのような人々は、あなたが他の人を導くために利用できるそれらの長年の経験を持っています。
より高い鳥のように、それはそれが見ることができるより多くの土地を飛ぶので、あなたの経験もそうです。
また、間違った実装をより速くプログラミングするよりも、正しい実装をプログラミングすることが重要であることも教えてください。最近、私の後輩の一人が何か間違ったことをプログラムしました、そしてそれは銀行にたくさんのお金を要しました。もちろん、以前に予定どおりに配達していたのですが、それは無駄でした。同じ後輩が問題が起こらなかったであろうことをコーディングしたとしても、私はガイドする役割を与えられましたか？この例を挙げて、良い指導をすることも重要であることを強調します。この仕事をコンサルタント業と呼ぶ人もいます。
あなたへの私の最高の推奨は、ビルディングブロックです。
常に信頼できるファイルビルディングブロックを作成し、APIのために作成して、同じものを何度も何度も書く時間を無駄にしないでください。すべての問題について1度考え、それを1度とすべて修正します。
誰もがそれに追いつくことはないでしょう。確かに、理解できないコーナーケースで失敗するコードのデバッグに80％の時間を費やす初心者ではありません。
何よりも、許可の誤りなど、起こり得ない問題を修正しないでください。
権限が間違っている場合は、すでに何かが間違っているので、プログラムを完全に証明するのではなく、修正する必要があります。
ある時点で、自分が撃ったかどうかを常に確認するのではなく、自分の足を撃たないようにする必要があります。
ドキュメントに時間を費やす代わりに、コードを自己文書化し、できるだけ短くすることに時間を費やしてください。これらの重複した機能をすべて置き換えます。ライブラリを縮小し、正確に名前を変更します。
あなたと同じように、私は14歳でプログラミングを始めました。最初のコンピューターを手に入れたときも（その時点で数か月間勉強していましたが）。しかし、私は33歳です。 :-)
私の提案は、何かを開発するときは、それらの心配事（ファイルのアクセス許可、ディレクトリ内のファイルの数など）を1つずつ取り、すべての豊富な経験を使用して、この精神についていくつかの質問に答えることです：
- その問題をコードで適切に処理するのにどのくらいかかりますか？
- あなたがそれを適切に処理しない場合、これが後であなたを噛む可能性はどのくらいありますか？
- それがあなたをかむ場合、結果は何ですか？
それらの答えで武装して、そのような経験豊富な男は賢明な決断をするのに問題はありません。 ;-)
この種の要件を考案するのはあなたのような「退役軍人」の責任であり、これには何がうまくいかない可能性があるかを特定し、注意すべき潜在的な問題を決定することの両方が含まれます。
自分に無理をしないでください。あなたは複雑さが増している専門職で働いており、これまで以上に人間の知性、知識、経験を必要としています。
コンピューターの処理能力が低下している-おそらく間もなく停止する-マルチコアチップ、GPU駆動の数値、並列処理などを導入する必要が生じた。チップ上に配置できるトランジスタは非常に多くある。
したがって、現在および将来の大きな進歩は、プログラマー、つまり高度なアルゴリズムとより効率的なコードによってもたらされます。
GTA 4とGTA 5を見ると、その違いは驚くべきものです。ただし、どちらも同じハードウェアで実行されます。これは、10年前には必要でなかった、または利用できなかった、非常にインテリジェントで高度なプログラミング手法の結果です。
また、経験豊富なプログラマーは将来、より価値が高くなる可能性があることを意味する可能性もあります-エンジニアリングなどの他の専門職と同様に、通常、キャリアの後半でピーク収益が発生します。
Edsger Dijsktra氏の言葉：「デバッグがソフトウェアのバグを削除するプロセスである場合、プログラミングはそれらを組み込むプロセスである必要があります。」後者をあまり実行しないので、前者をあまり実行する必要はありません。それは、正しいコーディングに時間を費やすことを学ぶことの問題です。私はまだ比較的若いプログラマー（20度を読む）で、一度完全に正しくコーディングできることを望んでいます。 1時間の計画と10分のコーディングは、10分の計画、1時間のコーディング、および3つのデバッグよりもはるかに優れています。
アプリの開発中にすべての可能な基準を知ることは、高品質の製品を開発する上で最も重要なことです。あなたはこれでうまくやっています。できることの1つは、要件を品質レベルに分類して、指定された期限にレベルをマッピングすることです。このようにして、プロジェクトの期限を簡単に満たすことができます。