Working Code Isn't Enough (Strategic vs. Tactical Programming)

Tactical programming

「動けばよかろう」で、可能な限りすばやく作り上げる姿勢
- 機能追加
- 不具合修正
犠牲をともなう
- 複雑性を持ち込んでしまう
- その場しのぎの解決策
目先のことしか見えておらず、将来のことが二の次
この取り組み方では、良い設計を生むのはほぼ不可能
複雑性は蓄積する(再掲)
- 1つ1つの妥協は理にかなって見える
- しかし、開発者全員の全変更分が蓄積すると、システムは急速に複雑化する
悪循環を抜け出せなくなる
- 複雑性の問題が顕在化し、後悔しはじめる
- が、改善はしない
  - リファクタリングは長い目で見れば助けになろう
  - が、目先のタスクの完了が遅くなってしまうので、やらない
- 結局つぎはぎだらけになり、さらに複雑化する
- ついには掃除に数カ月もかかるようになり、スケジュール上、手を付けられなくなる
  - 問題を2,3解消したところで焼け石に水なので、突き進むしかない
- 【所管】前職のコードを思い出す
tactical tornado
- どんな組織にも一人くらいいる、tactical極振りな人
- 実装の速さは他の追随を許さない
- 管理者は彼らをヒーロー扱いしがち
- 彼らが汚した跡は、他の技術者 -- 本当のヒーローが掃除することになる

よいソフトウェア設計者になりたくば「動くだけでは不十分」
タスクを早く終えるために不要な複雑性を持ち込むのはNG
長い目で見よ
- ほとんどのコードは「既存のコードベースの拡張」
- ゆえに将来の拡張を容易にするのが最重要
- コードは「動く」必要があるが、それを最優先目標には据えない
「戦略的プログラミング」のためには投資的な考え方が必要
- あとで効いてくる
先を見越した投資の例
- クラスの作成
  - 最初に思いついた案ではなく、別の設計をいくつか比較検討し、最もきれいなものを採用する
- ドキュメンテーション
  - 将来の変更を助ける内容を書く
後から行う投資
- どれだけ先行投資しても、設計の選択をしくじることはある
- 設計の問題点を見つけたら
  - 無視したりツギハギで直したりしない
  - たえず少しずつ設計を向上させる
    - cf. 「戦略的」ではたえず複雑性を導入し続けてしまう

どれだけ投資する？
システム全体を予め設計する？
- それウォーターフォールやんけ！
- ソフトウェア設計ではうまくいかない(ch1)
  - 触っている内に適切な設計が湧いてくるもの
小さな投資をたえずたくさん行うのが最良
全開発工数の10-20%くらいがちょうどよい
- はっきりとスケジュールに影響が出るほどではなく
- はっきりと利益を享受できるくらい
数カ月以内に効果が出る
- 最初はtacticalよりも10-20%時間を食う
- 開発速度が10-20%速くなるまでそう時間はかからない
  - もとを取れる
逆もまたしかり
- 戦術的姿勢でつくられたまずい設計のコードベースは、生産性を20%は下げる

反・戦略的立場の言い分
- スタートアップではすばやいリリースが重要
- 稼いだら掃除のために追加人員を雇う
戦術的姿勢をとってもコストは下がらない
- ひとたびスパゲッティになったコードベースはほぼ修復不能
- 設計の質の良し悪しの影響はすぐ出る
コードベースがひとたびめちゃくちゃになると、悪い噂がたち、平凡な技術者しか雇えなくなる
- 技術者の質は最重要事項のひとつ
- コストを下げるためには良い設計者を雇え
  - 平凡な技術者と比べて、コストは大差ないわりに、生産性が途方もなく高い
  - 最も優れた技術者は、設計について深い思慮をもつ
Facebook
- 戦術的姿勢で積み上げてしまった負債を掃除した例
- 前: Move fast and break things
- 後: Move fast with solid infrastructure
Google, VMWare
- もともと戦略的姿勢だった例
- シリコンバレーで名を轟かせ、技術的トップ層の雇用において他の追随を許さなくなった
設計に気を配っていて、きれいなコードベースな現場で仕事するほうが楽しいよ