はじめに
この記事は「プリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則」を読んだ際に記した議事録です。
著作権の関係により、詳細には書きません。詳しい詳細を知りたい方はぜひ本書を読んでみてください。
プリンシプルオブプログラミングをPOPと訳します。
What : コードは自然と腐っていくということ
エントロピーとは「無秩序な度合い」を表すパラメータです。機械系の学生には馴染み深いと思います。熱力学の法則によると「全宇宙のエントロピーは増加していく」ことが証明されています。
ソフトウェア開発はエントロピーの法則に強く縛られます。コードは自然に任せて書くと「限界を超えるまで」無秩序になっていきます。いわば腐ったコードです。
Why : コードは無秩序へと向かうから
最初は良いスタートを切ったとしても規則に則っていなければ腐敗し始めてゆきます。そして、腐敗は非線形的にひどくなり、保守しにくくなり、多大な労力が必要となり、最終的には再設計を余儀なくされます。そして再設計に関しても、さらに難しくなっています。ソフトウェアは世の中のニーズであるため、進化し続けるからです。
How : コード腐敗の前触れをつかもう
コードが腐敗へと向かう（スパゲッティーコード）になるにはいくつかの前触れがあります。見過ごさないようにしてソフトウェアを腐敗から守りましょう。
・硬さ
すなわち「変更のしにくさ」です。硬いコードはたった一つの変更に影響されやすく、依存関係のあるモジュールを連鎖的に変更しなければなりません。一見簡単そうな変更でも、難しく感じたり、依存関係が多かったりする「硬さ」を感じたら、それは腐敗の前触れです。
・脆さ
硬さと似ていますが、一つの変更で依存する多くの部分が壊れてしまうことです。グローバル変数を設定すると脆さが大きくなっていきます。コードを変更した際に、関係ないところまで壊れてしまった際は注意しましょう。
毎回修正しているモジュール、障害が消えない箇所は特に注視します。
・移植性のなさ
すなわち、他の環境への移植のしにくさです。
どんな環境でも動作する部分を含んでいても、依存部分を切り離すことが困難であれば「移植性の低いコード」と言えます。
・扱いにくさ
2種類の意味があります。「コードの扱いにくさ」と「開発環境の扱いにくさ」です。
コードの扱いにくさは、設計構造上の柔軟性のなさのことです。悪い設計構造はコードの変更に柔軟さがありません。OCPでない設計は悪い設計のことが多く裏技を使った変更が容易で、正しい
方法での変更が困難な状態です。
後者は、開発環境が非効率なことです。２、３のコミットに数時間もかかるような場合は、注意が必要です。
・複雑さ
複雑なコードすなわち、不要な要素の多いコードであるとも言えます。【POP1】でも解説しましたが「偶有的な部分」と「本質的な部分」をしっかりと見極める必要があります。
プログラマが仕様の変更を先取りして、容易に変更できる仕組みをあらかじめコードに仕込んでおくことで発生します。しかし、これはほとんどが逆効果で終わります。プログラマは頭の回転がはやく、今不要だが後から使うだろうみたいなコードを書いてしまうと、一度も使わないコードが散見される状態になってしまい、結果として複雑なコードを作り上げてしまいます。
YGNIを意識しましょう。
・繰り返し
同じようなコードが何度も書かれていることです。DRYの法則でもあったようにコピペは文書作成には最適な方法ですが、コード編集には悲惨な結果を生みます。ソフトウェアを完成させてから重複コードを取り除く作業はとても骨が折れます。大事なことは「抽象化」です。似たような箇所、共通項を見つけ出して、適切に抽象化することで重複を避けることができます。重複を避けると理解と保守のしやすい、ソフトウェアと化します。
・不透明さ
不透明さは表現の分かりにくさのことでです。一つの問題を解決したい、実現したいと言った時でもコードの書き方は千差万別です。略しすぎたコードやアルゴリズムの複雑すぎる表現は他の人には理解しにくく、また、時間をおいてから自分さえも理解するのが難しいコードになってしまいます。
不透明さを避けるには「読み手の立場に立ったコード」を意識します。難しいことを簡単なコードで表現できるのが優秀なプログラマです。
終わりに
この記事ではプリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則の議事録を自分用に記しています。
この記事ではカバーしきれていない部分も多いので、是非本書を手にとって読んでみてください。
次回、「【POP97】80-10-10の法則」です。ぜひ、次の記事も読んでみてください。
