#はじめに
今回『プリンシプル オブ プログラミング』という本を読みましたので、自分なりにアウトプットしていく目的でまとめます。
リンク：『プリンシプル オブ プログラミング ３年目までに身につけたい一生役立つ101の原理原則』
#第７章 法則〜プログラミングのアンチパターン〜
アンチパターンとは、成功しなかったソフトウェアや開発の中から失敗に至る原因となった悪質なパターンをまとめたパターン集のことである。これらを知ることで、トラブルを未然に防ぐことが出来る。
##一言まとめ
- ブルックスの法則
- スケジュールが押しているときは、人材投入ではなくリスケジュールする。
- コンウェイの法則
- 組織形成の前に、適切なアーキテクチャを設計する。
- 割れた窓の理論
- コードは一部でも汚れていると、プログラマ全体の心理に悪影響を及ぼす。
- エントロピーの法則
- 問題を引き起こすコードには予兆があり、それを見つけ次第潰すべきである。
- 80-10-10の法則
- どのような状況にも対応できる万能なソフトウェアは存在しないため、状況を見て適切にツールを使う必要がある。
- ジョシュアツリーの法則
- チーム内での開発における共通語を適切に作って使用すべきである。
- セカンドシステム症候群
- 多機能にし過ぎず、需要にあったシンプルなソフトウェアをリリースする。
- 車輪の再発明
- 既存のものを再発明しないよう、コードを書く前にライブラリ等を調べる。
- ヤクの毛刈り
- 目的やコスパを見失わずに、本来解決したい問題以外の問題に時間を取られ過ぎている場合は一度切り上げる。
##補足
###ブルックスの法則
プロジェクトのスケジュールが遅れているからといって、新しく人材を投入するのは得策ではない。完全に分離できる仕事というものは少なく、また新入の人材を教育することにも時間と労力が取られてしまうからである。このような場合はリスケジュールを行う他無い。また、遅れていない場合でも、人と人とを交換する、ということもまたできない。人によって作業能力や質は大幅に違うためである。
###コンウェイの法則
自然に任せて開発を行うと、組織に沿ったアーキテクチャが生まれる。しかし、アーキテクチャを先に適切に構築した後で、それに沿って組織を形成していくほうが得策である。組織の都合でできたアーキテクチャはソフトウェアの観点から見て最適とは言えないからである。ただ、早期に形成されるアーキテクチャは不備のある場合が多いため、十分な検証のもと設計する必要がある。
###割れた窓の理論
割れている窓が一枚でもあると、人々の意識に影響を与えて周囲全体の環境が悪くなるように、悪いコードを放置していると他のプログラマの意識にも影響し、ソフトウェア全体のコードの質を落とす結果となってしまう。開発する中で、まずコードをきれいに保つこと、そして汚いコードを発見したら直ちに修正、またはその旨がわかりやすいようコメントを残すなどの管理を行う必要がある。それによって、プログラマの心理に、コードを汚してはならないというストッパーが働き、コードの質の向上に繋がる。
###エントロピーの法則
コードは放っておくと、無秩序に増大していってしまう。保守しづらくなり、運用に大きな労力を必要とするコードとなる。それを防ぐためにコード腐敗の兆候を掴んで対処していくことが必要である。主なものは以下である。
- 硬さ
- 何か１つの変更を行った際、連鎖的に多くの変更をしなければならないようなコードは「硬い」コードと言える
- 脆さ
- １つの変更によって他の多くの部分が壊れてしまったり、何度も修復されていたり、障害リストに残ってしまうコードは「脆い」コードと言える。
- 移植性のなさ
- 環境依存の部分から、他の環境へ移植しづらい場合「移植性のない」コードと言える
- 扱いにくさ
- 設計構造を保持したまま一部を変更することが難しい、また、開発環境が遅くて非効率である場合「扱いにくい」コードと言える
- 複雑さ
- 今後を見越し不必要な構造が含まれたコードは「複雑」なコードと言える
- 繰り返し
- 似たコードが少し違う形で何度も現れるソフトウェアは「繰り返し」の多いコードと言える
- 不透明さ
- 度重なる修正などで読んだ時に構造がわかりづらくなってしまったコードのことは「不透明」であると言える
このような予兆をアジャイル型の開発や、チームのコードの腐敗を見過ごさない行動指針で潰していく必要がある。
###80-10-10の法則
80-10-10の法則とはユーザーの求めることのうち80％は容易に実現でき、10％は実現可能ながら大きな労力を必要とし、残り10％は実現不可能であるという法則である。単独のツールだけで、広範囲の問題をすべて解決できる「万能薬」のようなソフトウェアは存在しない。ただ、適応分野を絞り、バランス良く高品質なツールは存在するため、これを上手く使っていく必要がある。
また、80-20の法則というものもあり、これは全体を構成する要素のうち、8割の数値は2割が生み出しているという法則である。開発の場でも適応できるため、参考にすること。
###ジョシュアツリーの法則
物事や概念に対して、その名前を知ることによって存在を初めて認知することが出来る、ということをジョシュアツリーの法則という。これは開発の場にも言えることであり、チーム内で「ユビキタス言語」すなわち、きちんと統一された共通語を使用することで言語の認知が正しくなる。また普段の会話だけでなく、コードにも使用し、言語を日々洗練していくことが必要である。
###セカンドシステム症候群
ファーストバージョンをリリースした後のセカンドバージョンでは、機能を盛り込みすぎてしまう傾向にある。これをセカンドシステム症候群という。２度目のリリースでは、既知のことが多く自信があるため、このようなことが起こるが、これによって、コードの保守性や使い勝手が悪くなってしまう。ユーザーのことを考え、需要に合ったシステムを目指すべきである。
また、ユーザーからの多岐に渡る要望を盛り込みすぎてしまうことでも、このようなことは起こる。他のソフトウェアと組み合わせて実現できるものに関してはNOを言えるようにし、どうしてもNOと言うことができない場合は、ソフトウェア本体ではなく、本体をラップする形の拡張で実現するようにし、あくまで本体はシンプルに保つ。
###車輪の再発明
既にあるものを再発明してしまうことを「車輪の再発明」という。これが起こる原因としては２つあり、まずその既存のものを知らない場合と、知っている上で自分で作りたいという考えのもと作る場合である。コードを書く前に同じ機能が標準ライブラリやオープンソースライブラリに無いか確認してから必ずチェックを行う、チームミーティングなどで別のプログラマからアドバイスをもらう、などの対処を行うべきである。また、ソフトウェアはユーザーのためのものであるという意識を持って開発を行い、普段から使えそうなものを調査し、高品質のオープンソースや商用ツールを把握しておく必要がある。
###ヤクの毛刈り
問題を解決する際に、芋づる式に様々な別の問題が発生し、本来の問題を解決できないまま、その発生した問題に時間を取られてしまうことを「ヤクの毛刈り」という。このような状況に陥った際には、早々に切り上げ、状況を俯瞰してみて別の道を考えるほうが効率的である。見切りを付けるためには、本来の目的やコストパフォーマンスを頭に置いて、開発することが求められる。また、他の人が同じ状況に陥らないようメモを取っておくことで、ロスを削減することができる。
どうしても「ヤクの毛刈り」を行わなければならない際には、適宜手順や状況をメモしつつ行い、思考のループに陥らないよう気をつける必要がある。
##参考文献
『プリンシプル オブ プログラミング ３年目までに身につけたい一生役立つ１０１の原理原則』上田勲 著 株式会社秀和システム 2016年3月29日 p.268~295