どうやって自分の書いたコードが悪いか知るか？
この間、ロバート・マーティンのこのビデオを見ていました。彼が悪いコードを見分けるための三つの兆候について話していましたが、私は彼に全面的に賛成できました。
1. 堅いコード（Rigid Code）
あなたのコードが堅いというのは、あるコードの一部を変更する際に、そのコードと関係なく無関係な他のモジュールも変更しなければならない場合を言います。
堅いコードとは、多くの方向に依存関係が伸びていて、孤立した変更も全ての周りを変えずにはできないコードのことです。 — ロバート・マーティン
例えば、データ層のある低レベルの詳細を変更しようとすると、ビュー用のフォーマットを処理するクラスでコンパイルエラーが発生するような状態です。
もしあなたが、単一のクラスを変更するたびに、プロジェクトのほぼ全てのモジュールに手を加えることがよくあるのなら、それは堅いコードの症状かもしれません。
2. 壊れやすいコード（Fragile Code）
壊れやすいコードは、堅いコードよりもずっと悪い状態です。少なくとも堅いコードではコンパイルエラーが出ます。
壊れやすいコードでは、もしモジュールの小さな部分を変更すると、まったく異なるモジュールのまったく異なる機能が壊れてしまいます。そして、これらのエラーを開発中に簡単に見つけ出す方法はありません。
壊れやすいコードは、予測できない奇妙な方法で壊れます。 — ロバート・マーティン
もし、全く異なるユースケースに対する修正をプッシュするたびに、機能が壊れているとの顧客からの報告がよくあるなら、あなたのコードは壊れやすい可能性があります。
3. 再利用できないコード（Non-reusable code）
その名の通り、再利用できないコードとは、再利用できないコードのことです。
例えば、あなたがあなたのプロジェクトで、同僚が別のプロジェクトで行ったのと同じ機能を実装したくなったとします。しかし、そのプロジェクトのコードを簡単に再利用することができないのは、そのコードが、他の無関係な特徴に依存していたり、ある種のフレームワークやデータベースシステムに依存しているからです。それらはあなたのプロジェクトでは望まれていません。そして、その機能用の自分の実装を書いた方が良いでしょう。
これが有名なゴリラ-バナナ問題です：
あなたはバナナが欲しいのに、手に入るのはバナナを持ったゴリラとその周りの全てのジャングルです。 — ジョー・アームストロング
コードを書く時には、自分自身にこれらの質問をしてみてください：
-
このコードはあまりにも堅すぎますか？将来、このモジュールの内部を他のモジュールや他の層のコードに触れることなく変更することは可能でしょうか？
-
このコードはあまりにも壊れやすすぎますか？将来のあらゆる変更に対して、全部の修正箇所を見つけるのは困難になるでしょうか？
-
この機能は再利用可能であるべきですか？もしそうなら、このコードは避けられる不要なモジュールやフレームワークに依存していますか？
よく見ると、上記の三つの問題の共通点は、カップリングです。モジュールが望ましくない方法でお互いに依存し合っており、それでスパゲッティコードが生まれてしまいます。
コードはモジュールと層を通じて分離するべきです。高レベルのポリシーと抽象は、低レベルの詳細に依存してはいけません。必要な場所でモジュールの依存関係を逆転させます。そして、1つのことだけを行い、変更する1つの理由だけを持つクラスを作成しましょう。
良いコードは何をしているかを説明します。読むのは退屈です。全てが完璧に明白です。それが良いコードです。 — ロバート・マーティン
私のMediumの投稿でも公開されています。
こちらの記事はdev.toの良い記事を日本人向けに翻訳しています。
https://dev.to/bob/how-do-you-know-your-code-is-bad
