Chapter 3 - Working Code Isn’t Enough / A Philosophy of Software Design

本

第3章はWorking Code Isn’t Enough (Strategic vs. Tactical Programming)というタイトル。

Tactical Programming

近視眼的に目の前のタスクを終わらせるためにコードを書く
目の前のタスクを終わらせることが最優先になるので、これだといい設計はもたらされない
これが積もり積もってシステムに複雑性をもたらす
開発メンバー全員がこのアプローチで開発すると一気に複雑性が高まる
tactical tornado
- Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado.

The first step towards becoming a good software designer is to realize that working code isn’t enough.
- working code = 動くコードの意味？
Your primary goal must be to produce a great design, which also happens to work. This is strategic programming.
- 第一のゴールを素晴らしいデザインでかつきちんと動作するものにするべき
良いデザインに対して投資する、という考え方を持つべき
- 最初に思い浮かんだ設計のアイデアをそのまま実装するのではなく、少し時間をかけてよりシンプルな設計がないかを模索する時間をかけるべき
どのぐらい良い設計のために時間をさくべきか？
- 作業の10-20%とこの本ではいっている
- 良いデザインにそのぐらいコストをかけると、数ヶ月後にはそのベネフィットを感じることができる
スタートアップと良い設計への投資
- スタートアップで10-20%コストをかけることは現実的ではないと考えられているため、大抵のスタートアップではTacticalなアプローチが採用される
- Facebook is an example of a startup that encouraged tactical programming
- the company’s motto was “Move fast and break things.”
- Over time the company realized that its culture was unsustainable. Eventually, Facebook changed its motto to “Move fast with solid infrastructure”

本

第2章は"The Nature of Complexity"というタイトルで、ソフトウェアのComplexityつまり複雑性についてじっくり説明されている。

Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.

Complexityの3つの症状

- とある機能追加・変更をしたいだけなのに、いろんなところを変更しないといけない。以下の図で言うと、背景色を変更したいだけなのに`bg = "red"`の定義が複数箇所あるため、これらを全て修正しないといけない、みたいな。

認知負荷。開発者が機能追加・変更のタスクを完了させるためにどのぐらいシステムの内部を知っている必要があるか、と言うこと。多ければ多いほど把握できなくなり、修正漏れなどのバグが発生することになる。
システム設計者は時々コードの行数で複雑性を表そうとするが、1行に処理が集約されてすぎていて逆に認知負荷を高めるケースもある。1行より複数行のコードの方がシンプルになっている場合もある

開発者が機能追加・変更のタスクを完了させるために、どの部分を変更すればいいのかが明らかではないこと。もしくはどの部分を変更すればいいのかの情報が明らかではないこと
上の図だと、「背景色を変更したい」と言うタスクがある時に、bannerBgを変更しても全てのページの背景色が変わらないので、どの部分を変更すればいいのかが分かりにくい

これはテストです。

本

A Philosophy of Software Design の第1章を読んだのでそのまとめ。

プログラムは機能が増えるごとに複雑さが増していく。複雑さが増えると、開発スピードが遅くなりバグが増える
開発ツールは複雑性に対処するに役立つが、これには限界がある。一方、シンプルなソフトウェアのデザインはより大きくてパワフルなプログラムを導いてくれる。
複雑性に対処するには2つのアプローチがある。
- 1つ目はコードをシンプルかつ明らか（わかりやすく）すること。例えば複雑性は特殊ケースを削除することで減らすことができる。
- 2つ目のアプローチはカプセル化でmodular design とよばれている。
  - Modular designではソフトウェアをモジュールに分割して管理して(OOPだとクラスとか)それぞれのモジュールは他のものに依存しない。
  - そのため、プログラマーはあるモジュールの開発をするときに、他のモジュールの詳細を知らなくて済む。

ウォーターフォールだと基本的には設計フェーズではすべてを設計し、開発のフェーズでは設計をしない。ソフトウェアは物理的なシステムより複雑で目に見えないので、特に大きなシステムであるほど全体を細部まで理解することは難しい。
開発フェーズで初めて問題がわかるケースもよくあり、場合によっては設計のやり直しが発生する。ウォーターフォールモデルだとこれは大きな手戻りになってしまう。
この問題があるため、最近のソフトウェア開発ではアジャイルのようなインクリメンタルなアプローチが使われている。