【開発哲学3_29】〜『CODE COMPLETE第２版 第29章(下巻)』の感想〜統合
感想
データベースリファクタリング
に書いてる
「発展型プログラミング」
がここでいうインクリメンタル型統合戦略手法って感じかな。
オブジェクト指向言語では、インクリメンタル手法が向いてるなあ
て実感。
デイリービルドとスモークテストの親和性も高いし。
午前中にビルドが終わらないこともあまりないし、
もし、着手以前の段階で、時間がかかりそうなら素直に、
「時間がかかりそう」、「やったことがないからここはやってみないとわからない」
と事前に伝えておけば、みんな
「そうなんだあ」
って感じで、リスク対応（＝他のことに時間が使える、急かしても仕方ないな）しやすくなる。
ま、逆に
「なんでそんなに時間がかかるんだ」
「なんでコードを書いてないんだ」（WISCA症候群）
みたいに、会議や組織内で詰問したところで、
やったことがない以上、調べてみないとわからないものはわからないし、
「何時間以内にやれ」
と変なプレッシャーをかけたところで、
潜在的なバグが発生すれば、それ以上の時間が統合後に失われるから、
どの途、統合がうまくいかないだけなんだけどね。
詳細
見出しとしては、
統合手法の重要性
統合の頻度ーフェーズ型とインクリメンタル型
インクリメンタル統合戦略
デイリービルドとスモークテスト
参考資料
まとめ
て感じ。
オブジェクト指向言語以前から
開発してる会社だと、当時の名残なのか、組織としての秩序が開発力の向上や収益よりも重要なのか
いまだに、
ウォーターフォール型
＝ 上位下達の意志決定 ＋ 非現実的な緻密すぎる計画
👉フェーズ型
（＊他の記事で紹介したSDEMを採用してる会社が多い印象。）
で統合しようとして、結合テスト〜システムテストの段階でエラーや動作遅延が発生し、全面改修を余儀なくしてるなあ（【開発すごろく】）。
そもそもウォーターフォール型は、
「携わるエンジニアが、今回対象となるプログラミング言語の知識と経験と人格が十分備わっていて、監視しなくても机上デバッグ単体テストなどできちんと行う。」
＝ 超人か聖人君子みたいな、普通の会社員では当たり前の美徳
👉プログラマとしてはあり得ない美徳
を前提にしてるから、
現実を無視して、未だにメインフレーム時代から続くレガシーな統合手法を後生大事にしちゃってるなあって印象。
プログラマの三大美徳
を理解せずに、プログラマに一般人の美徳を押し付けて管理しようとしても、それで統合がうまくいくわけないのに。
（＊プログラマの三大美徳については、後の章で出てきてたと思うからそこで書く予定）
この章でも書いてるけど、
選択したプログラミング言語に合わせて臨機応変に、統合手法を変えること
まあ、臨機応変に色々な統合手法を変えられるようになるには、
ある程度経験を積んで、その経験から日々学んでいくしかないんだけどね。
まとめ
💃統合に関しても、やり方はひとつじゃない🕺
第6部も残りあとひとつ〜〜〜！