偶然によってプログラミングを克服する方法は？[閉まっている]

The Pragmatic Programmerの本では、作家はプログラミングを偶然の一致の概念に言及しています。それが何であるか、なぜそれが引き起こされるのか、あなたが遭遇するかもしれない危険は何かを説明し、戦争中の地雷原と比較します。

古い白黒の戦争映画を見たことはありますか？疲れた兵士は慎重にブラシから飛び出します。前にクリアがあります：地雷はありますか、それとも安全に渡れますか？地雷原であることを示す兆候はありません。標識、有刺鉄線、クレーターはありません。兵士は銃剣とひるみで彼の前の地面を突いて、爆発を期待します。ありません。それで、彼はしばらくフィールドを苦労して進み、彼が行くにつれて突き、突きます。最終的に、フィールドが安全であると確信して、彼はまっすぐになり、誇らしげに前進し、破片に吹き飛ばされるだけです。

兵士による地雷の初期調査では何も明らかにされませんでしたが、これは単に幸運でした。彼は誤った結論に至り、悲惨な結果をもたらしました。

開発者として、私たちは地雷原でも働いています。毎日私たちを捕まえるのを待っている何百ものtrapがあります。兵士の話を思い出して、私たちは誤った結論を出すことに注意する必要があります。偶然のプログラミング（幸運と偶然の成功に頼る）を避け、意図的にプログラミングを行うべきです...

しかし、私は彼らが「それを克服する方法」問題を説明する方法に本当に満足していません。ええ、あなたはコードを書く前に先を考えなければなりませんが、それをどのように実践するのですか？私が考えることができる唯一のことは、既存のオープンソースプロジェクトに機能を追加することです。ここでは、「今何をしているのか」と「他のコードの動作」の両方に関する知識が必要です。独自のプロジェクトを書いているとき。

編集：

投稿の要約：

• 次の動きを推測しないで、それが正しいことを証明してください
• 必要に応じて、可能な限り単体テストとリファクタリング
• 機能の追加-コンパイル-テストを頻繁に行う
• 初心者にコードを説明できない場合、おそらく偶然のプログラミングでしょう。

ところで、答えを受け入れるのは難しいです、本当に難しいです。すべての答えは本当に素晴らしいです:)

あなたは先を考える必要はなく、単に何が行われたのかを非常に明確にし、あなたが今何をしているのかを非常に明確にする必要があります。

サブルーチンは、何をすべきかを言い、彼らが言うことをし、隠された依存関係を持ってはいけません。そうすれば、誰かがそれらを呼び出すことで、彼らが何をするかについてより簡単に推論することができます。

グローバル状態を避けてください。（変数、シングルトンなど）物事が何をするかを理解するために頭の中にもっと多くの状態を持たなければならないほど、何が起こるかを理解してエッジケースを見つけることは難しくなります。

単体テストを作成します。単体テストは、探している理想的な動作ではなく、作成したばかりのコードの実際の動作をキャプチャするのに最適です。

編集/コンパイル/テストのサイクルを短くします。大量のコードを追加してテストを不十分にすると、予想とは異なる動作をする可能性が高くなります。次に、ランダムな変更を加えて「修正」し、今のところ正しい答えを得ましたが、実際にどのように発生したのかわかりません。偶然のプログラミングです。しかし、5行追加してからテストすると、正しいと思われるように動作するため、正しい答えが得られる確率ははるかに高くなります。経験から言えば、個別にテストされた各10行の5つのチャンクは、一度にテストされた50行のコードとは非常に異なるものです。

冷酷にリファクタリングします。多くの場合、コードをいくぶん単純にするリファクタリングを見つけましたが、やりたくない作業をたくさん取ります。優先事項としてこれらのリファクタリングに意図的に取り組み始めた後、通常は1か月以内に成果を上げることがわかりました。しかし、キーに注意してください、私が焦点を当てているリファクターは、日々の生活をよりシンプルにするものであり、より良いまたはより一般的な何らかのarbitrary意的な美学を満たすものではありません。私が学んだこれらのリファクタリングは、より慎重になりました。

これらはどれも事前の計画を必要としません。しかし、これらはすべて既存のコードを理解しやすくするため、次の小さなチャンクを意図的な方法で簡単に実装できるようにします。

推測しないためにかなり煮詰めます。ほとんどの新しいプログラマーがそれを行いますが、ベテランもそれを行うのを見てきました。なぜなら、彼らは研究時間を節約できると思うからです。あなたが追加して何かが、ない仕事をし+1たり-1、変更するtrueにはfalse、いくつかのステートメント並べ替え、またはその逆の追加や、それが動作するまでの変化の遅延、変更スレッドの優先順位、およびその他の小さな変換は、基本的にランダムな順列をテストします。

これは主に既存のコードの変更に適用されますが、真にゼロから始める人はいないため、新しいコードの要因でもあります。常に標準ライブラリ、オペレーティングシステム、または少なくともプロセッサアーキテクチャの上に構築します。

つまり、修正が機能する理由がわかるまでは完了しません。そこにたどり着くまでの道はそれほど重要ではありません。ランダムな並べ替えでさえ、「OK、trueからfalseに修正したが、なぜですか？」

私がこれまでにプログラムで遭遇した最も恐ろしいコメントは

これに触れないでください。できます。方法や理由はわかりませんが、機能します。¹

そして、それはコードの一部が偶然のプログラミングの結果であることを認めているという理由だけで怖いです。

偶然のプログラミングを避けるために、コードが何をするのか、なぜ機能するのかを（同僚、自分、またはゴム製のアヒルに）正確に説明できる必要があります。意図的にプログラミングするための箇条書きは、コードを説明できるという目標に向かって進むための助けになります。

¹コンテキストについては、このコメントはプリミティブOSのコンテキストスイッチを処理するコードに登場しました。このコードは、私が遭遇した数年前からすでに本番環境にありました。

新しいプログラマーにとって、これを克服するための最も重要な部分は、彼らが何をしているかを本当に理解することです。

多くの分野で、何かをする方法がわからないときは、試行錯誤を繰り返します。何か試してください。それが機能する場合、素晴らしい、そうでない場合は、何か他のものを試してください。

プログラミングでは、特に未定義の動作（CやC ++など）の概念を持つ言語を使用する場合、成功はもはやブール値の決定ではないため、このアプローチは単純に機能しません。「ある種の」機能、時には機能するもの、一部の入力に対しては機能するが他の入力に対しては機能しないものを持つことができます。

私は時々新しいプログラマーを指導しましたが、ランダムなものをタイプして、それが機能するかどうかを確認する傾向があります。彼らは線をタイプしてから、私に向かって「このように機能しますか？」と尋ねます。一方、彼らがそうするかどうかについてはまったく手がかりがないことは明らかでした。

重要なことは、新しいプログラマーとして、コードが何をするのかを本当に説明できなければならないということです。コードを書くだけでなく、コードを読むことを学ぶ必要があります。

（もちろんそれはベテランのプログラマーにも当てはまりますが、ここでの私の経験は主に完全な初心者です。）

「レーシングライン」でコーディング、テスト、修正するのは非常に簡単です。XとYを与えてZを生成する機能があります。しかし、Xが破損し、Yが使用できない場合はどうでしょうか。Zを出力できない場合はどうしますか？何が間違っているのかを常に念頭に置き、テストサイクルのためにそれを書き留めます。

ルーチンを短く、わかりやすいものにしてください-最適なコードには、コメントはほとんど必要ありません。

意味のあるメソッド名、クラス名、変数名は、読みやすさの向上に役立ちます。

コードの匂いに出会ったら、やめてください。その匂いが消える可能性は低く、今は少し努力すれば、後で大きな悲しみを救うことができます。

開発プロセスにテストを含めます。TDDではなくBDDを使用することをお勧めします。これは、誤った安心感を与える可能性のある一連のテストに盲目的に頼るのではなく、達成することを目指していることを説明することを強制するためです。

特別なクールな機能を追加する衝動に抵抗します（それがあなた自身のペットプロジェクトでない限り）。余分なコードは、設計、作成、テスト、および保守する必要があります。クライアント/ビジネスで必要とされていない場合、これがリソースの膨大な流出になるリスクがあります。