プログラマーはほとんどの時間、コードを書くと誰もが考えています。 プログラマー自身に加えて。 彼らはほとんどの場合、このコードを読んでいることを知っています。 彼らは読んで、それがどのように機能するのか、なぜここに書かれているのか、そして今どうするのかを理解しようとしています。
読むのに最も長いのは、トリッキーなアルゴリズムではなく、代数的なデータ型とモナドのソリューションではなく、500行のメソッド、1000行のスクリプト、1500行のクラスなどの単純なコードの巨大な断片です。 それらはすべて、悪名高いNullPointerExceptionに劣らず、業界の問題をもたらします。
M. Fowlerによる古典的な本「リファクタリング」では 、ボリュームに関連する「疑わしいコード」には、「ロングメソッド」、「ラージクラス」、「パラメーターのロングリスト」の3種類しかありません。 現代の現実では、このリストは補充される可能性がありますが、これら3つの長い間知られている原則でさえ非常に頻繁に違反され、コードの大きな断片は多くの問題を引き起こし続けます。
最初の（そして主な）問題は、 費やされた時間です。 「大量のコード」とは、まず第一に読むべき大量のテキストです。 また、コードではすべてのニュアンスが重要であるため、ここでは速読テクニックは役立ちません。 「斜めに」読むことは、時間を無駄にし、それがどのように機能するかについて誤った結論を下すことを意味します。
システムの一部がどのように機能するかを誤って伝えることにより、プログラマは新しいコードを書くときに間違いを犯す運命にあります。
大量のコードをテストするのは困難です。 大量のデータを使用する大規模な方法は、ユニットをテストでカバーすることはほとんど不可能であり、統合テストは巨大で非常に複雑です。 これでテスト用のテストを作成するときが来ました。 ただし、プロジェクトには自動テストがまったくないふりをすることができ、すべてが正常です。 E.ヨードンの本「神風の道」はあなたにとって非常に役立ちます。
コードの大きな塊を確認するのは困難です。 同僚は非常に生産的で、週末にサブシステムを作成しましたか？ でも、マスターに送る前に、この作品を読むのに多くの工数を費やす必要があります！ 3番目の10個のファイルの変更を読んだ後、自分の現在のタスクは言うまでもなく、頭の中で最初から変更を維持するのは簡単ではありません。
大量のコードを再利用することはほとんど不可能です。 彼は一度にあまりにも多くのことを行い、通常はそれらの一部のみを再利用する必要があります。 「メソッドの選択」などのトリックを使用して状況を改善することも、常に可能であるとは限りません。これは、この巨大な部分がテストで十分にカバーされていないためです。
コードをまったく書かないようにしてください。
- このプロジェクトの前の誰かが同じ（または非常に類似した）問題を解決したかどうかを確認します。 コードを再利用し、抽象化を強調し、恥ずかしがらないでください。
- 独自のプロジェクトのユーティリティとAPIを知って愛してください。 特に彼が6ヶ月以上の場合。 数十行のコードを節約する真珠があるかもしれません。
- あなたの言語やプラットフォームで人気のあるライブラリを知り、愛してください。 Javaについて話をするのであれば、少なくともGoogle GuavaとApache Commonsファミリーに精通するために怠laにならないでください。 車輪を再発明しないでください。
結局コードを書くとき。
- ( , , , ). , , . .
if { … } else { … }
20 ? , . ( )? . - - . -
onSuccess()
200 400 , , . , (onSuccess()
) . - . - (, ) ( ).
— . , . ( callback-), ( , , . .) ( ).
,
- ( ) ( ).
- .
- .
- .
, , , . , . .