TL;DR
- 動くだけのコードでは不十分で、優れた設計を目指すなら戦略的プログラミングを選ぶ必要がある。
- 良い設計は、総開発時間の 10〜20% 程度の小さな投資を、明日ではなく今日から続けることで実現する。
内容
戦術的プログラミング
戦術的プログラミングは、動くことを最優先し、タスクをできるだけ早く終わらせようとする。より良い設計を探さずに妥協を重ねるので、システムの複雑さは少しずつ増えていく（第2章 The Nature of Complexity）。問題が起きてもリファクタリングより目先の機能実装を優先するので、複雑さはさらに増える。気づいたときには、複雑さを一掃するのに数か月かかる状態になっており、それでも目先の機能を優先してしまう。一度戦術的プログラミングを選ぶと、そこから抜け出すのは難しい。
戦術的プログラミングを極限まで突き詰める開発者を、Tactical Tornado と呼ぶ。どの組織にも少なくとも 1 人はいる。他の人よりはるかに速くコードを書いて機能を実装するので、経営陣からは英雄視される。しかし、そのコードに後から触れるエンジニアから英雄視されることはない。
戦略的プログラミング
優れた設計者になるための第一歩は、動くコードだけでは不十分だと理解することである。目先の仕事を早く終わらせるために、不要な複雑さを持ち込むべきではない。大切なのは、将来の拡張を容易にする長期的なシステムの構造である。動くだけでなく優れた設計を生み出すことを目標にするのが、戦略的プログラミングである。
戦略的プログラミングには、投資のマインドセットが必要である。プロジェクトを最速で終わらせる道ではなく、システムの設計を改善するために時間を使う。短期的には開発速度が落ちるが、長期的には上がる。たとえば、新しいクラスを追加するときに代替案をいくつか考えて将来変更しやすいものを選んだり、分かりやすいドキュメントを書いたりする。
それでも、設計上の判断の誤りは避けられない。時間が経てば誤りは明らかになるので、少し時間をかけて直すことが大切である（継続的な投資）。ここで無視したり場当たり的に対応したりすれば、戦術的プログラミングと同じになる。戦略的プログラミングは少しずつ改善を加えていくが、戦術的プログラミングは将来問題を起こす複雑さを少しずつ加えていく。
どれだけ投資するか
システム全体を前もって設計するような大きな先行投資は効果がない。これはウォーターフォールモデルであり、うまくいかないことが分かっている。最善なのは、小さな投資を継続して数多く行うことである。目安は総開発時間の 10〜20% 程度である。初期のプロジェクトでは戦術的プログラミングより 10〜20% 長くかかるが、その分良い設計が生まれ、数か月後にはメリットを実感できる。戦術的プログラミングは初期の開発速度こそ速いが、複雑さがたまるにつれて遅くなる。
スタートアップと設計
スタートアップは戦術的プログラミングに走りがちである。成功すればエンジニアを増やす資金が手に入るので、後から直せばよいと考える。しかし多くの場合、修正できないまま、プロダクトの寿命が尽きるまで高い開発コストを払い続けることになる。戦略的プログラミングに切り替える余裕もない。
企業が成功するための重要な要素は、優秀なエンジニアを雇うことである。優秀なエンジニアは優れた設計にこだわる。ひどいコードだという評判が広まると採用が難しくなり、システムの構造はさらに悪くなる。
どちらを選んでも成功した前例はある。Facebook（現 Meta）は長年 Move fast and break things をモットーにし、入社 1 週間目の新人でも本番環境にコミットするのが普通だった。会社は成長したが、コードの多くは不安定で理解しづらく、コメントやテストも少なかった。最終的に Facebook は優れた設計への投資を奨励し、モットーを「Move fast with solid infrastructure」に変えた（CNET の記事）。一方、Google や VMware は戦略的プログラミングを採用した企業の例である。ソフトウェア設計に気を配り、クリーンなコードを持つ会社で働くほうが楽しい。
キーワード
- 戦術的プログラミング
- 戦略的プログラミング
- Tactical Tornado
- 複雑さ
- 継続的な投資
- マインドセット
- リファクタリング
- ウォーターフォールモデル
- Move fast and break things
自分の理解
Tactical Tornado の話は、自分のことを言われているようで耳が痛い。スタートアップが「成功すれば人を雇って直せる」と考えてしまう話もぶっ刺さった。Facebook のレベルですらこうなるのだ。
継続的なリファクタリングは、継続的な設計の一部だと捉えている。
クリーンなコードを持つ会社で働くほうが楽しいというのは、確かにそうだと思う。