Best effort JavaScript

Guilty talk about DDD without Implements Code.

「レガシーソフトウェア改善ガイド」読書会 #1

今週から会社で読書会を始めました。(毎週水曜1時間)
現状定期的な読書会はなく、以前不定期にやっていた読書会はしっかりと議論する、本を持っていない人に印刷して配る、などのコストが高かったためか自然消滅していまいました。

電子書籍をプロジェクターに映して本を持っていない人も準備不要、
VOYAGEさんの読書会を参考に、作業しながら聞きが出来るようになスタイルで業務の負担にならず継続出来ることをコンセプトにしています。

techlog.voyagegroup.com

今回は 前書き から 位置No.556 知識の孤立 まで進みました。

印象に残った箇所

レガシープロジェクトとはなにか

  • レガシーコードはあなたが最初にHello Worldを書いた時よりも前から製品化され、もう何十人もの開発者が入れ替わり立ち代り保守している
  • 「レガシー」の定義は保守または拡張が困難なプロジェクト
  • 何世代かのメンテナが交代することによってシステム元来の設計や前のメンテナの意図に関する知識も失われる
  • コードが多ければバグも多い。新しい変更によってリグレッションを引き起こす可能性も高い
  • 優れたテストスイートは事実上のドキュメンテーションとして機能する
  • 「完璧なものは十分に良いものの敵だ」けれどもそういう次善の策をプロジェクトに追加する場合はあとで時間があるとき、そのコードを見直してクリーンアップすることを、必ず計画に入れるべき
  • 一時的な、あるいはハックのようなソリューションは、どれも製品全体の品質を低下させ、将来の仕事を困難にする
  • それがあまりにも多くなったらいつかはプロジェクトの進行が停止してしまう

レガシーカルチャー

  • 変化が怖い
    • どの機能なら、もう使われていないので安全に削除できるか?
    • どのバグならば修正しても安全なのだろうか?
    • 振る舞いを変更する前に、どのユーザーに問い合わせる必要があるだろうか?
  • こういう情報が欠如しているので、多くのチームは現状を最も安全な選択肢として尊重するようになり、ソフトウエアに「不必要な変更」を加えることを恐れるようになってしまう
  • どのような変更も、まったくのリスクとみなされ、変更によって利益が得られる可能性は無視される
  • このためプロジェクトは進展のない沈滞の状態に陥り、開発者は現状を維持することに精力を注ぎ込み、まるで琥珀の塊に封じ込められた蚊のように、ソフトウエアをあらゆる外敵影響から保護しようとする
  • 彼らがリスクを嫌悪するあまりソフトウェアの進化を許さないために、彼らの組織が競合他者に遅れを取るという非常に大きなリスクにさらされることが多い
  • もし他社が新しい機能をあなたの組織より早く追加することができるのなら、彼らがあなたの組織から顧客と市場を奪い取るまで、あまり時間がかからない