この記事では、コードの内部品質と外部品質、プログラミングの価値観、コードの品質を評価する基準、端正なコードの職人技、既存のコードを維持する方法に焦点を当てます。
外部品質：ユーザーが感じる部分、正確さ、使いやすさ、効率、信頼性。
内部品質：保守性、柔軟性、移植性、再利用性、可読性、テスト性、理解しやすさ。
22の教訓は以下の通り：
- コードは外部品質と内部品質に分けられ、良い製品と良いコードはイコールではありません。
- 氷山効果：プロダクトマネージャーやユーザーが注目する製品の部分は、氷山の水面上にある部分に過ぎず、その下に隠れているのは見えないさらに大きな部分であり、それは膨大な量のコードです。
- プログラミングの価値：コミュニケーション、シンプルさ、柔軟性。
- コードの最も重要な機能は、プログラマーの設計と思考を伝えることであり、次に実装の機能です。優れたプログラマーは、機械が理解できるコードではなく、人間が読めるコードを書くべきです。
- 効率は明瞭さを犠牲にする理由にはなりませんし、主観的な「知覚的」トリックのために、パフォーマンスを向上させようとして不明瞭なコードを使用することは不可能です。むしろ、コンパイラ自体の最適化や、性能の低い箇所を評価するツールに頼って、的を絞った最適化を行うべきです。
- スピードアップのためにコードを死ぬほど叩こうとしないで、もっと効果的なアルゴリズムを見つけてください。
- コードは、速くする前に、まず正しく作るべきです。まず信頼できるものにしてから、速くしましょう。まずコードをきれいにして、それから速くしましょう。
- 良いコードは悪いコードではありません。悪いコードは、いくつかのメトリクスで測定することができます。悪いコードが機械によって固められ、コードが悪化しないように時々チェックされることを可能にするメトリクス。
- 多くの "主流 "の見解に反して、関数そのものは再利用するためのものではありません。関数は主に、責任を分離し、細かい操作を隠し、コードを読みやすくし、拡張に対応し、単体テストを容易にするために存在します。ちなみに、関数は再利用のために使われることもあります。
- 関数は、抽象度の原則、短さの原則、単一責任の原則に従うべきです。
- 抽出関数は、次のような特徴を持つ関数が見つかった場合に検討する必要があります：
- 長すぎる
- 入れ子のレイヤーは深すぎます。
- プロシージャのチャンクを記述するためにアノテーションを使用する必要があります。
- 判定条件が複雑すぎる
- 関数の判定分岐の一部が常に変化していること
- パラメータが複雑すぎる
- 論理は繰り返す
- ローカル変数は単一の目的のために使用されるべきです。
- 新しく書くコード・ロジックは、ユーザーのシナリオとクラスの責任に焦点を当てるべきで、どのパターンを使いたいかを考えるために出てくるべきではありません。これは必然的に過剰設計につながります。パターンは、変更に対応するためや、その後のバージョンで変更が発生したときに既存のコードをリファクタリングするために使われます。
- 常にリファクタリングを行い、コードをクリーンに保ちます。
- コードは負債であり、プログラマは返済しなければならない負債を負っています。古いコードをメンテナンスするプログラマは、コード考古学者とも呼ばれ、多くの場合、無数の変更の歴史の中で失われがちな元のユーザー要求を見つけるために、乱雑なコードの山を掘り起こします。古いコードの保守は時間のかかる作業です。古いコードを修正するリスクを減らすには、いくつかのテクニックが必要です。
- プログラマーは、きちんとしたコードスタイルを習慣化し、きちんとしたコードの重要性を常に意識し、リファクタリングのスキルを常に向上させるべきです。
- 意図主導のプログラミングは思考を助け、理解しやすいコードを生成します。
- デザインパターンそのものは、変化に対応するために使われるものです。開発中に「パターンを使おう」と考えることは、過剰設計につながる可能性が高いです。デザインパターンは、問題を解決するためにコードをリファクタリングするときにのみ考慮すべきです。
- 関数の名前は重要です。
- コードを書き換えるタイミング
- 開発チームは時間の20％をレガシーシステムのリファクタリングに当てます。残りの時間は新機能の開発に費やします。
- 可能な限り、リファクタリングする部分には漸進的な変更を加え、たとえ作業に時間がかかったとしても、ユーザーが改善を実感できるようにします。
以上のような経験を共有し、具体的な仕事と組み合わせることで、検討すべきシナリオがあるかもしれません：
既存のコードをメンテナンスする場合、リファクタリングをほとんど考慮せず、元のコードにロジックを蓄積し続け、その結果、元のロジックがどんどん複雑化し、理解しづらくなるというのは、往々にして真っ当で野蛮なことです。これはもっと注目されるべきです。
最後に引用します：
知識とは、どれだけ覚えているかではなく、どれだけ考えさせるかです。一度コードを振り返り始めると、そのコードは二度と同じものにはなりません。
