何が間違っているかについての知識の増加による遅い問題解決の克服[完了]

これはしばらくの間私を悩ませてきました、そして、私は本当に他の専門家の入力に感謝します。

短いバックグラウンド：1988年に両親が私の最初のコンピューターを買ったときにプログラミングを始めました（14歳のとき、私は今39歳です）。1997年にようやくプロのプログラマーになる前に、私は他の2、3の経歴をたどりました。私は今でも自分の選択に満足しており、プログラミングが大好きで、自分の仕事が得意だと考えています。

最近、経験を積むほど、プロジェクトまたはプロジェクトの特定のタスクを完了するのに時間がかかることに気付きました。私はまだ老いません。ただ、物事がうまくいかない可能性のあるさまざまな方法を見てきました。そして、私が知っていて覚えている潜在的な落とし穴と落とし穴はますます増えています。

些細な例：以前は「大丈夫、ここにファイルを書く」だけでした。今、私は権限、ロック、同時実行、アトミック操作、インダイレクション/フレームワーク、異なるファイルシステム、ディレクトリ内のファイル数、予測可能な一時ファイル名、PRNGのランダム性の質、あらゆる中の電力不足を心配しています操作、私がやっていることのための理解可能なAPI、適切なドキュメントなどなど

要するに、問題は「これをどのように行うか」から「それを行うための最良/最も安全な方法」に移りました。

その結果、初心者よりもプロジェクトを完了するのに時間がかかります。私のバージョンは堅実で、作成方法を知っているのと同じくらい侵入できないかもしれませんが、時間がかかります。

上記の「ファイルの作成」の例は単なる例でした。実際のタスクは明らかに複雑ですが、このような一般的な質問にはあまり適していません。私がこれでどこへ行くのか理解してほしい。効率的なアルゴリズムを考え出すのに何の問題もありません。数学が大好きです。複雑なテーマを楽しんでいます。集中力に問題はありません。私は経験に問題があり、その結果エラー（内因性または外因性）を恐れていると思います。

私は1日2時間近く、新しい開発、新しい技術、言語、プラットフォーム、セキュリティの脆弱性などを読んでいます。難題は、知識を増やせば増やすほど、プロジェクトの完了が遅くなることです。

これにどう対処しますか？

プロジェクトを完了するのに時間がかかりません。以前は、初心者のプロジェクトは実際には行われていないのに完了したと考えていました。この品質をクライアントに販売する必要があります。

「この会社はそれをより速く、より安くできるかもしれませんが、本当にできていますか？それとも、何年もバグを探しますか？」

それを超えて、「完璧は善の敵です」という古いイディオムを知って受け入れる必要があります。

暗い側面、つまり管理に参加する時が来たようです。

プログラミングをあきらめてマネージャーになることはお勧めしません。しかし、これまでに引用したすべての経験は本質的に技術的なものであるようです。ファイルを書き出すという単純な操作では、あまり成熟していない開発者が決して考慮しない10の異なる側面を考えることができます。必ずしも悪いことではありませんが、...

暗い面はすべて現在価値です。最大の利益を得るために最小限の投資を行うことです（費用便益分析）。ビジネスでは、すべてが最終的にどれくらいの費用がかかるか、成功の確率、失敗の確率、壮大な失敗の確率、潜在的な利益になります。計算する; それに応じて行動します。

これは、開発者の場合も同様に機能します。一時ファイルを作成し、権限と名前の衝突を無視します-5分。最終的には、チームの残りの部分は、そのファイルの存在に依存するコードで作業を開始できます。それは完璧な解決策ですか？絶対違う。99％、95％、おそらく90％になりますか？そうだろう。

別の質問：技術的負債についてどう思いますか？一部の人々はそれを排除しなければならないと考えています。それらの人々は間違っていると思います。ビジネスと同じように、技術的負債により、「現金」または「時間」を借りて、何かをより早く届けることができます。良い点：2年で完璧なソリューションになるのか、顧客が4か月で使用して購入できる完全なハックになるのか？状況はそれぞれ異なりますが、状況によっては、2年待つと、顧客が既に競合にサインアップすることになります。

重要なのは、よく運営されている企業が金融負債を管理するのと同じ方法で技術的負債を管理することです。十分に引き受けない場合、最適な投資収益率を得られません。あなたがやりすぎると、興味があなたを殺します。

だから私のアドバイス：あなたの徹底を最大化するのではなく、あなたの価値を最大化しているかどうかに基づいてあなたの仕事を評価し始めてください。そして、これを実践すれば、技術分野ですでに開発したのと同じ直感を開発できます。

サイドノートとして、私は最近ポモドーロのテクニックを始めました、そしてそれは多くを助けました。接線の接線に移動する代わりに、短い時間間隔に焦点を合わせてから、将来の作業/研究のためにポモドーロを割り当てます。トピックを調査するために何度もメモをとったのは驚くべきことでしたが、その1時間後に、「今日の時間でもっと価値のあることができる他に少なくとも3つのことができる」と思いました。

私は何年も前に（おそらく）同じ問題を抱えていましたが、数年続き、それを克服しました。ですから、私のやり方があなたにも当てはまるかどうかわからない場合でも、私がそれをどのように達成したかを知ることは、あなたにとって興味深いかもしれません。

また、こちらもご覧ください。ソフトウェアエンジニアリングの7つの専門分野生産性がスキルレベルの副次的な影響であることを示しています。現在使用しているテクノロジのステージ3とステージ4の間のある時点にいる可能性があります（スキルの習熟度はテクノロジによって異なります。一部のテクノロジを習得しながら、他のテクノロジを習得できます）。

今、私は伝記の証言から始めます。

少しのコンテキスト。私は47です。80年代の12時にプログラミングを始めました。高校時代、私はパートタイムのプロのゲームプログラマーとしても働いていました。基本的に、ハードウェアを購入するのに十分なだけのお金は得られませんでしたが、楽しんで多くを学びました。18歳で、コンピューターサイエンスの正式な学習を開始しました。

その結果、20歳になったとき、プログラミングタスクを開始するたびに、与えられた問題を解決するための多くの方法を知っていて、手元にある多くのパラメーターと落とし穴、あらゆる方法の欠点と制限を非常に意識していました。

ある時点（たとえば26歳くらい）で、プログラムを書くことがまったく難しくなりました。非常に多くの可能性が開かれたので、私はそれらを選択することができなくなりました。数年間（6にする）、プログラミングをやめ、テクニカルニュースライターになりました。

それにもかかわらず、プログラムしようとして完全に停止することはありませんでした。そして、ある時点でそれは戻ってきました。私にとっての鍵は、極端なプログラミング、より具体的にはシンプルさの原則、「動作する可能性のある最も単純なものを書く」でした。

基本的には、コードの効率を気にせず（それが私の主要な障害であり、非効率な設計を避けます）、ただ最も簡単な方法で行っています。また、エラーを発生させるテストを作成した後、エラーについてあまり気にせず、エラー処理を遅らせることを強制しました（実際にはTDDです）。

それは私が書いていたときに学んだことです。ときに私が書くことかわからない、または私は私がいた書いていたものを知っていた悪いです。続けてください。実際に悪いものを書いてください。最終的には後で修正します。または、本当にそれが悪い場合は、それを消去して書き換えますが、最初に完璧なものを書くものを2回書く方が速いです。

実際、最初の記述が得意であると信じているコードは、実際に悪いコードと同じくらい改善する必要がある可能性が非常に高いです。

Simplicityパスをたどると、ボーナスも追加されます。初期設計/コーディングを簡単に削除/変更できます。あなたはより柔軟な心を得ます。

また、コードに一時的なコメントを入れる習慣を身に付け、今はやっていなかったことを説明し、後でコードが通常のユースケースで機能するようになるときに行うことを意図しました。

また、XP Dojoに参加し、他のプログラマーとコードカタを練習してXPプラクティスを内部化しました。助けた。上記の正式な方法を本能的にしました。ペアプログラミングも役立ちました。若いプログラマーと仕事をすることはある程度の勢いを与えますが、経験を積むと、そうでないこともわかります。例えば、私の場合、私は彼らが過度に複雑な設計に従事しているのをよく見ますが、設計の悪夢につながるかもしれません。そのようになった。やった 問題がありました。

私にとっての最大のポイントは、フローを維持することです。高速であることは、流れを維持することに本当に成功しています。

今、私はプロのプログラマーとして戻ってきており、自分が何をしているのかをより深く理解することで、より良く、より速くなると信じています。TDDの練習はまだ若い雄牛だったときよりも少し遅いかもしれません（そして何もテストしていません） ）。

要約：アジャイルメソッド（XP）を使用してコードブロックを克服し、単純化してリファクタリングし、本能的になるように練習します。それは私のために働いた。他の人に一般化できるかどうかはわかりません。

スキルの習得レベルに関しては、テクノロジーを変更するたびに（新しい言語、新しいフレームワークなどを学ぶ）、ペースが落ちる段階を経ることを受け入れることをほとんど学びました。これは正常であり、最終的にはそれを克服します。優れた方法論と汎用プログラミングスキルでそれを補うこともできますが、それほど問題にはなりません。

プログラミングの重要な部分は、複雑さを管理および制御することです。私にとっては、それは最も重要な問題の1つです。無視すると、欠陥の頻度が急増するか、またはあなたの場合のように、完成したソフトウェアのETAが劇的に増加します。

ソフトウェアの複雑さはさまざまなレベルと方法で制御および管理できますが、ある程度の見通しを得るための大まかな目安は次のとおりです。

言い換えれば、ソフトウェアの複雑さは、顧客の期待をコントロールする能力に大きく依存します。

この考え方を採用すると、2つの重要なポイントが明らかになります。

1. 顧客の期待を明示的にする必要があります（どんな形式でも）。
2. 顧客の期待はいつでも修正することができ、それは交渉の手法によって行われます。

あなたの例は非常に良い例です。「簡単に書いてください」対「他の無数の考慮事項」です。考えてみてください-誰かが両方のバリアントの完全な要件を書き留めた場合、記述された機能に同等性があるかどうか？

F16の構築は、セスナの構築とは異なりますが、どちらも飛行できます。

簡単な答えは、それを受け入れます。

すべてのシステムで、信頼性、堅牢性、セキュリティ、速度、ハードウェアコスト、開発コスト、市場投入までの間にトレードオフが必要です。顧客がこれらのトレードオフをどのように行うかに常に同意するわけではありませんが、あなたはそれらの決定をするものではありません。あなたができることは、考えられた意見を提供することだけです。ソフトウェア開発は、「私の個人的なWebページ」から「原子炉の運転」までの全範囲をカバーし、それに応じてコードを作成する必要があります。クラッシュとは「個人のWebページをリロードする」ことを意味する場合、それが発生した場合に誰が本当に気にしますか？しかし、クラッシュが「チェルノブイリ」を意味する場合、堅実なコードを好むのは、私の好みにとって少しカジュアルなものです。

「概念実証」レベルのコードを喜んで受け入れてライブシステムで実行するクライアントもいますが、多くの場合、それに慣れているシステム管理者がいます。IMEのシステムは、通常、深夜に1時間程度使用できなくなり、スケジュールされた再起動が多数発生します。しかし、彼らはそれが彼らがどのように転がしたいかというビジネス上の決定をしました。理想的には、そのフィールドは非常に高速であるため、高品質のコードは準備ができていませんが、多くの場合、彼らは値を見ることができないため（システムが「ちょうど動作する」場合、彼らはそれに気付かないため、そのシステムはお金）。気になりすぎる場合は、それらのクライアントを避けるようにしてください。

最新の状態を維持することは、私たち全員が費やさなければならない、または少なくとも費やすべき時間です。時にはそれがあなたを働かせますし、他の時にはそれはあなたの心を良い状態に保ちます。どちらにしても、楽しんでみてください。

あなたのスキルは、金融/取引関連アプリケーション、放送、航空宇宙、防衛などの非常に高品質のミッションクリティカルなシステム開発に非常に役立つようです。

この種のアプリケーションのエラーは非常に高価であり、すべてのケースをカバーできるのであなたのように考える人々を雇います。

真実は、現代のシステムがますます複雑になっているということです。コンピューターは、ゲーム「ジェンガ」に似ており、これらのすべてのピースが他の多くのピースに依存しています。間違ったピースを引き出すとエラーが発生し、正しい/必要なピースを引き出してもエラーが発生する場合があります。システムが複雑になるほど、コードをより堅牢にし、できればより安全にする方法を考えるのに時間を費やす可能性が高くなります。「XYZ」という会社がハッキングされ、600万人の顧客のクレジットカード番号が盗まれたというニュースを聞くと、最近はスピードが後部座席に多くかかると思います。

クライアントは、プログラムが安全で堅牢である必要があることを聞きたくないかもしれません。しかし、車にはシートベルトやエアバッグは必要なく、家には鍵やドアが必要ではないことを伝えることができます。それ？

あなたが考えすぎている場合、あなたは物事を正しい方法で進めていますが、「具体的」と思われる戦略を選択し、それをそのまま実行する必要がある場合を除きます。

間違っている可能性のあるものすべてについて考える傾向に気付いているようです。

経験豊富な慎重な開発者は、マントラに従うことを学ぶことがよくYAGNIありますが、失敗モード分析、ゴーンアモックの雑草に詰まってしまい、無駄のない、機敏で生産的なワークフローに戻ろうとするとき、あなたはそれを必要としません。

ただし、そのレベルの注意がプロフェッショナリズムが要求する以上の領域で実際に何かを書いているなら、あなたはあなたの「速度」、「生産性」が正味でどれだけ良いかで測定可能であることに気付くべきです（またはあなたの会社、顧客、ソフトウェアスイート、または構築または保守している製品ファミリに対して行っていることです。

忘れないでください：

• アプローチの変更を検討する場合、メンテナンスの総コスト、総所有コスト、およびソリューションの展開とメンテナンスの総コストを含めます。より速く進み、より多くの間違いを犯すと、物事が良くなる場合とそうでない場合があります。

• あなたが良い会社で働いているなら、あなたはおそらくあなたのチームで、そしてあなた自身のスーパーバイザーと、これをキャリア制限ムーブにならずに議論することができます。できないなら、今こそそれを見つけて新しい仕事を見つける良い機会です。

私が見ることができるのは、「あなたはますます貴重になっています」です。

より多くの経験を積むと、避けなければならないことについて学び、これが他の人よりもあなたを良くするものです。

コードの安全性と保守性が向上したことに気づいたと思います。

• あなたがする必要があるのは、なぜ時間がかかったのか、クライアントにとってどのように役立つのかをクライアントに説明することだけです。
• あなたは彼らにあなたの知識の深さを示す必要があります。
• なぜあなたがしたのか、何をしたのか、そして彼らと彼らのビジネスにとってどのように重要なのかを伝える必要があります。

私の提案は、この部分に集中することです。

疑わしい場合は、クヌートのクォートが不適切になります...

「早すぎる最適化はすべての悪の根源です。」

私が時々問題を抱えているように見えるので、ここに私が提案するものがあります...

私にとって本当に役立つのは...

1. すべてのコードが完了したかのように、単体テストを作成します。
   
2. インターフェイスを文書化します。
   
3. インターフェイスを実装します。

あなたが本当にしたこと：

1. モデルレイヤーの要件を処理する
2. 実際に作業区分を設定し、どのオブジェクトが何に責任があるのか
3. 実際に作業中のコードをステップスルーできる環境で作業するようになります。

また、初期の開発ではアサートに依存します...次に、どの救済策を実装する必要があるかを把握し、到達不能またはテストが困難なコードを書く必要はありません。

コーディングの標準を守る必要があると思いますが、クライアントと事前に対応していることを確認してください。多くのクライアントは、優れたソフトウェアを構築するために必要なコストを知りません。それらを教育することは、プロの開発者の仕事の一部です。

アジャイルであろうとウォーターフォールであろうと、クライアントがアプリケーションに何を期待しているのかについて、クライアントから何らかの同意を得ます。開発者が多すぎる（おそらく営業担当者も多い）ことは、サンドバッグの罪を犯しています。「彼らは高度に安全なウェブサイトが欲しいとは言わなかった。」ほとんどの場合、それは彼らが尋ねられなかったからです。「eコマースサイトがハッキングされてもかまいませんか？」もちろん、彼らは気にしているのですが、なぜセキュリティを浸透させるためにそれを構築するのですか？それらを教育する必要があります。

クライアントがあなたに支払っているものだけをしていることを確認してください。あなたのサービスの一部はあなたの経験です。クライアントは、彼らが尋ねることなく、落とし穴を知っていることを期待します。要件を含めるかどうかは彼ら次第です。安価なものを求めているクライアントを引き渡したい場合があります。

解決する必要がある他のすべての問題と比較して、バグの実際的な結果について考えてください。

不完全に記述されたコードを作成した場合、次の結果を考慮してください。

1. データベース全体が隔月でダンプされます。バックアップの復元中の48時間のダウンタイム。
2. 顧客レコードはクロスリンクされます。1か月あたり200ドル相当の注文が間違った顧客に発送されます。
3. 1週間に1回、注文が間違ったステータスでスタックします。注文は発送されますが、倉庫は発生するたびにヘルプデスクに電話する必要があります。
4. 約2週間ほどで、アプリがクラッシュし、ユーザーは2分のデータを再入力する必要があります。
5. 月に一度、アプリは起動時にハングします。ユーザーはプロセスを強制終了し、最初からやり直す必要があります。

最初のものは明らかに受け入れられません。＃2-＃5は、ビジネスの性質によって異なる場合があります。＃2-＃5は、ビジネスが直面している他の問題のコンテキストで評価する必要があります。

理想的には、＃2-＃5は決して起こらないでしょう。現実には、優先順位が対立するため、給与に署名する人は、問題が発生することのない完璧なコードを書くのではなく、他のことに取り組むことを望みます。＃5が修正されても、別のプログラムのより深刻なバグを修正しないという犠牲を払っても、彼らは感心しないでしょう。

解決策は、プロジェクト全体で再利用できる一般的に使用される機能を備えたライブラリのコレクションを作成することです。たとえば、エンコーディング、暗号化、復号化、正規表現の評価などを行うStringFunctions.dll .NETライブラリがあります。このように、変更しないものを継続的に書き換える必要はありません。

ファイル作成タスクのラッパーを持つことも非常に理にかなっています。ライブラリは、GetFile（）と呼ばれるメソッドを公開できます。このメソッドは、すべてのチェックを行い、nullまたはファイル（または有用と思われるもの）を返します。

どのプロジェクトでどれだけの作業を行う必要があるかを判断する必要があると思います。いくつかのプロジェクトは些細なことかもしれませんし、あなたは本当にそれを完成させるためにそのすべての時間を費やす必要はありません。すべてが堅固な暗号化を必要とするわけでも、すべてが100万人のユーザーに拡張されるわけでもありません。

100万人以上のユーザーに対応できるプログラムを作成するには、現在の時間と経験が必要になりますが、アプリケーションが最大1000人のユーザーによって使用されることはないことがわかっている場合、すべてを使う意味はありませんその時それを完成させます。

これはあなたのプログラミングキャリアの重要な段階であり、次のレベルに進む必要があると思います。これはプログラミングではなく、成熟に関係しています。特定のプロジェクトに必要な時間とコードの量を正しく決定できる必要があります。

そして、他のすべてと同様に、あなたも練習でこれを達成することができます。そのため、プロジェクトを開始する前に、プロジェクトに取り組んでいるときでさえ、いつかこれを決めてみてください。経験を積むと、それを乗り越えることもできます。最初はいくつかのヒットとミスがあるかもしれませんが、時間が経てば完璧になります（コードではなく、意思決定）。

@Zilk、私は素晴らしいプログラマーではなく、1998年からプログラミングをしています。今でもこの問題に直面しています。しかし、私が気づいたのは、最終的に品質の問題です。今日私が死ぬと、誰かが私が今していることを私が去った場所から拾うことができるはずです。これはプログラミングの標準（ユニバーサル）でなければなりません。

私は開発者から建築家になりました。管理への移行は、ラインを変えています。情熱を持ち続けたいのなら、建築家になろう。

当初はテクニカルアーキテクト->ソリューションアーキテクト->エンタープライズアーキテクト->チーフアーキテクトなど。

アーキテクトとして、人々を成功へと導きます。何十年もプログラミングを続けてきたあなたのような人たちは、他の人を導くために利用することができます。

鳥が高くなるように、より多くの土地を見ることができるので、あなたの経験もそうです。

また、間違った実装をより速くプログラミングするよりも、正しい実装をプログラミングすることが重要であることを教えてください。最近、私の後輩の一人が何か間違ったことをプログラムし、銀行に多額の費用がかかりました。もちろん時間通りに配達しましたが、それは役に立ちませんでした！同じ後輩が問題を起こさなかったことをコーディングしていたとしても、私は指導する役割を与えられましたか。この例を挙げて、適切なガイダンスを提供することも重要であることを強調します。この仕事をコンサルタントと呼ぶ人もいます。

別のオプションは、コードの記述を停止し、代わりに事前に問題を発見する専門知識を売り込むことです。

つまり、コンサルタントになります。

多くの組織は、問題を特定するコードを作成するのに数か月を費やす前に、誰かに問題を発見するために高価なドル（最高ではないにしても）を喜んで支払います。設計上のバグを修正することは、コーディング、テスト、および展開後に修正するよりも桁違いに安く/簡単であることはよく知られています。

あなたはそれほど多くのコードを書くことはないでしょうし、おそらくそれを見逃すかもしれませんが、実際のコードの行はあなたのコアの強さではないようですが、どのコード行を書くべきか、そしてどの行を書くべきではないかを知っているようです。

あなたの強みに焦点を当てます。
（まあ、それがあなたが楽しむものなら...）

あなたへの私の最高の推薦は：ブロックを構築することです。

常に信頼できるファイルビルディングブロックを作成し、API用に1つ作成し、同じことを何度も書き続けることをやめます。すべての問題を一度考えて、それを一度だけ修正します。

誰もそれに追いつくことはできません。確かに、自分の時間の80％を理解していないコーナーケースで失敗するコードのデバッグに費やす初心者ではありません。

何よりも、許可の誤りなど、発生しない問題を修正しないでください。

パーミッションが間違っている場合は、何かがすでに間違っているので、プログラムを防弾にするのではなく、修正する必要があります。

ある時点で、自分がやったかどうかを常に確認するのではなく、足で自分自身を撃たないでください。

ドキュメントに時間を費やす代わりに、コードを自己文書化してできるだけ短くすることに時間をかけます。これらの重複した機能をすべて置き換えます。ライブラリを縮小し、正確に名前を変更します。

自分に無理をしないでください。あなたは、ますます複雑化する専門職で働いています。これは、これまで以上に多くの人間の知性、知識、経験を必要とします。

コンピューターの処理能力が低下している-おそらくすぐに失速-マルチコアチップ、GPU駆動の数値、並列処理などを導入する必要性につながります。チップに配置できるトランジスタは非常に多くあります。

したがって、現在および将来の大きな進歩はプログラマーからもたらされます-高度なアルゴリズムとより効率的なコード。

GTA 4とGTA 5を見ると、その違いは驚くべきものです。ただし、どちらも同じハードウェアで実行されます。これは、10年前には必要でなかった、または利用できなかった、非常にインテリジェントで高度なプログラミング手法の結果です。

また、経験豊富なプログラマーは将来的に価値が高くなる可能性があることを意味する可能性があります。これは、通常、キャリアの後半でピーク収益が発生するエンジニアリングなどの他の職業と同じです。

ちょうどあなたと同じように、私は14歳でプログラミングを始めました。最初のコンピューターを手に入れたときも（その時点で数か月間勉強していましたが）。しかし、私は今「33」だけです。:-)

私の提案は、何かを開発するとき、あなたはそれらの心配（ファイル許可、ディレクトリ内のファイルの数など）のそれぞれを取り、それからこの精神でいくつかの質問に答えるためにあなたの広大な経験のすべてを使用することです：

• コードでその問題を適切に処理するのにどれくらい時間がかかりますか？
• あなたがそれを適切に処理しない場合、この事が後であなたを噛む可能性はどのくらいありますか？
• 噛まれた場合、結果はどうなりますか？

これらの答えで武装して、そのような経験豊富な人は賢明な決定を下すために問題を抱えません。;-)

このタイプの要件を思い付くのは、あなたのような「ベテラン」の責任であり、それは何が間違っているのかを特定し、注意を払うべき潜在的な問題を決定することの両方を伴います。

アプリの開発中に可能な基準をすべて知ることは、高品質の製品を開発する上で最も重要なことです。あなたはこれでうまくやっています。できることの1つは、要件を品質レベルに分類し、指定された期限にレベルをマッピングできることです。このようにして、プロジェクトの期限を簡単に満たすことができます。

Edsger Dijsktraの言葉を借りると、「デバッグがソフトウェアのバグを削除するプロセスである場合、プログラミングはそれらを組み込むプロセスでなければなりません。」それは正しいコーディングに時間を費やすことを学ぶことの問題です。私はまだ比較的若いプログラマーであり（20を読んでください）、一度完全に何かをコーディングできるようになりたいと思っています。1時間の計画と10分間のコーディングは、10分間の計画、1時間のコーディング、および3つのデバッグよりもはるかに優れています。