設計段階の瑕疵は、実装段階で治癒しない。
そして、そのプロジェクトの進め方の瑕疵は、どう転んでも治癒しない。
世の中の炎上現場、底なし沼現場はこうして生まれる。
でもって、そういう現場を生み出した、牟田口廉也的な「高級エンジニア」は、これを成功と吹聴して実績として担いで、悲劇の現場から逃げ出して、反省することなく次の現場をぶっ壊しに行く。
プロダクトの規模が年々大きくなっていく分、ヤバさは累乗的にデカくなっていく。
経営者さん、理解していますか？ w
ドキュメントが大量に積み上がってる現場は、「頑張ってる」んじゃなく、基本的に「やばい」 death。
なぜって？
プログラムは、柔軟に変化していく、変化できることが、ゼネコンが建てる建物との大きな違い。
ゼネコンの設計書一式とは訳が違う。
固まったドキュメント。
なんてもの存在しない。
影響範囲を確認しようにも、そのドキュメントが現時点の正しい姿であるとは限らない。
いや、正しい姿であるはずがない。
作ったら作りっぱなしだから。
そして、影響範囲は、ドキュメントからは推測できない。
だからこその、DDDやTDDなんだが、形式的に適用しているから、正しく作用しない。
DDDやTDDの効用(安全かつ素早い変更等)が正しく得られないということは、間違えているということだ。