simple-engineering

シンプルなエンジニアリング

シンプルで洗練された状態を保つ

過剰なエンジニアリングは恥ずべき愚かな行為であり、常にシンプルで洗練された解決策を追求することが重要です。

機能を実装したりバグを修正したりする前に、あらゆる選択肢を検討してください。似たような選択肢を列挙するだけにとどまったり、先入観や過去の考え方に縛られたりするのではなく、まったく異なるアプローチも含め、あらゆる選択肢を検討してください。利用可能な選択肢の中から、最も明快でシンプルで、コードの行数が最も少なく、ユーザーの要件を満たすものを選んでください。破れた服を直すのに、鉄板や釘を使う必要はありません。大きすぎて複雑なアプローチではなく、適切な規模のシンプルなアプローチを選んでください。

また、コードに不要な複雑さを持ち込まないようにしてください。関連する処理を注意深く調べ、実行不可能な条件分岐や不要な try-catch ブロックがないことを確認してください。型定義と実際の処理を確認し、実行不可能な条件分岐を取り除いてください。通常は例外が発生しそうにない場合や、呼び出される関数内にすでに try-catch がある場合、新たに try-catch ブロックでコードを囲む必要はありません。

過剰なバリデーション、過度に防御的な実装、不要な中間表現、コードの本来の目的に役立たない複雑さを見つけたら、指摘してください。たとえば、特定のウェブサイトの商品リンクを開く関数では、ホスト名を確認するだけで十分な場合があります。パス名まで確認しても、セキュリティが向上しないまま複雑さが増すことがあります。関数の引数を https://example.com/product/{string} のような型で定義したり、商品 ID のみを受け取り、関数内でリンクを組み立てたりすれば、バリデーションを削除できるかもしれません。これらはあくまで例ですが、同様のシンプルな実装を探してください。コードの目的は何か、そして実装にその目的の達成に必要なものだけが含まれているかを考えてください。

車輪の再発明を避ける

車輪の再発明は避けてください。コードを追加する前に、プロジェクト内の既存コードやプロジェクトの依存関係に、その処理の一部またはすべてを担う機能がないか確認してください。複雑な処理を実装するときは、同等の機能を実現する、広く使われていてメンテナンスの行き届いたライブラリが存在するか調査し、存在する場合はユーザーにその利用を提案してください。

必要な変更だけを残す

YAGNI（You aren't gonna need it）の原則を念頭に置いてください。将来必要になるかもしれないというだけで、複雑さを持ち込むべきではありません。また、未リリースの機能について後方互換性を維持する必要もありません。

最終的にユーザーへ届けるコードでは、変更したすべての行が必要であり、不要なコードが残っていない状態にしてください。変更が本当にすべて必要かを確認するため、ファイル単位ではなく、差分を行ごとに注意深く見直してください。

コードベースをクリーンに保つ

コードを書くことは、既存のコードに単に追加することと同じではありません。不要になったコードは削除してください。意味的に異なるコードを無理に既存のコードへ追加するのではなく、必要に応じてコードを分割し、再設計も含めてリファクタリングすることで、クリーンなコードを保ってください。

リファクタリングは特別な時期だけに行うものではありません。現在の変更範囲に、通常の作業中に小規模なリファクタリングで解決できる設計の悪い箇所があれば、積極的にリファクタリングしてください。ただし、大規模なリファクタリングを行う前には、ユーザーに明示的な許可を求めてください。

DRY 原則と変更のしやすさ

DRY 原則と変更のしやすさを念頭に置いてください。同じことを何度も定義するのではなく、1 か所を変更すれば関連するすべての処理が自動的に更新されるような、変更しやすいコードを目指してください。たとえば i18n では、利用可能な言語とそのラベルを 1 か所で管理し、言語の追加や削除には、その 1 か所を更新し、対応する翻訳ファイルを追加または削除するだけで済むのが理想的です。