【開発哲学3_21】〜『CODE COMPLETE第２版 第21章(下巻)』の感想〜コラボレーティブコンストラクション
感想
本章で、
さまざまな不具合検出の方法を挙げてはいるんだけど、
全てを必ず実践しろとは言ってないし、
職場の状況で最適なものをいくつか選べばいいってスタンス。
全部を実施すれば、その分、不具合やエラーが減るってものでもないし。
むしろ育成やテストケースの作成やコードレビュー、インスペクションの経験が浅い人がやっても考慮漏れや確認漏れしか出さないしね。
最近、
絆とか信頼関係とか口にして、ホワイトな企業だとアピールしたい経営陣で、コードレビューとかに参加したがる人が増えてるけど、本章で書いてるとおり、コードのレビューなはずが、
「人事考課＝政治活動」
の場所に変わるだけだから、部下から結果の報告だけ待って参加するのはやめといた方がいい。
てか、コードがわからないのに散開して、「これどういう意味？」と口を挟まれたり、レビューで厳しく突っ込まないといけないのに、「先輩への話し方としてどうなんだろう？」とか言われても、コードレビューの目的から外れているから正直、鬱陶しがられるだけ〜〜〜。
システム品質に、礼儀作法カンケーないですから〜残念‼︎（古いか 笑）
絆を深めた部下を、本当に信頼してるなら、
💃専門部署の部下に、安心して任せましょう🕺
詳細
見出しとしては、
コラボレーティブ開発プラクティスの概要
ペアプログラミング
公式なインスペクション
その他のコラボレーティブ開発プラクティス
コラボレーティブコンストラクションテクニックの比較
参考資料
まとめ
って感じ。
うーん。
複数人で作業をする場合の、人数によりけりかな。
元々、２人しか同僚がおらず、あとは上司と管理者だけってプロジェクトであれば、必然的に「ペアプログラミング」になるだろうし、
それよりも人数が多いのであれば、「インスペクション」だろうし。
それ以前に、
そもそも人材不足でペアを組める相手がいない職場も多い気がする💦
きちんと複数人の組織でひとつのツールを作るにしても、
慎重すぎる国民性
過剰に高すぎる品質安全意識
一人よがりな職人気質
で、【開発すごろく】が始まる。
【開発すごろく】
何かコードを書く（＋0.5〜１日＝１営業日）
↓
机上デバッグでセルフチェック（＋１日＝２営業日経過）
↓
修正後、資料再作成（＋１日＝３営業日経過）
↓
ペアプログラミングでコードレビュー（＋１日＝４営業日経過）
↓
修正後、資料再作成（＋１日＝５営業日経過）
↓
会議でウォークスルー型のコードレビュー（＋１日＝６営業日経過）
↓
修正後、資料再作成（＋７日＝13営業日経過）
↓
部内でインスペクション（＋１日＝14営業日経過）
↓
部内フィードバックで修正後、資料再作成（＋14日＝28営業日経過）
↓
顧客や経営陣の前でドッグアンドポニーショー（＋１日＝29営業日経過）
↓
顧客や経営陣から新しい要求が出て、
１から作り直し
で振り出しに戻る（＋29日＝58営業日経過）
↓
[上記の流れを2〜3回繰り返す(58 × 2 or 58 × 3 = 116 ~ 174営業日が過ぎていく＝軽く１年近く経過 )]
👉いつまでも終わらない開発のエンドレスマーチ。最短でも、58営業日＝約３ヶ月。ステークホルダーから新しい要求も出るよなあ。
まさに、（開発における）パーキンソンの法則😅
（開発における）パーキンソンの法則
「与えられた時間の最大まで作業量は膨らんでいく。」＝【開発すごろく】
で結局、納期が守れずに、中途半端な品質のものでリリースせざるを得なくなる💦💦
だから、うまい管理者はガントチャートを
予定日数×1.5
で引く。
予定日数が、２ヶ月ならば、３ヶ月。１年ならば、１年半。
合理化、効率化と、誤った8割思考で、予定日数×0.8とかな管理者も多かったけどね。
まとめ
💃構想や詳細設計がまとまった段階で迷わず、早め（３日〜２週間以内）に
プロトタイピングで（操作画面など簡単な）モックアップを作って
顧客とか経営陣のイメージを固めた方がベター
コードなどの品質はそれから🕺
（要求もイメージも固まってないのに品質を維持しようとしても、
要求が変更されれば振り出しに戻るだけ）
本章以外の参考文献
パーキンソンの法則
については、こちら。
ガントチャート
については、こちら。
