Code Complete１人読書会 その２

花金ですが、第２回目です。

まだしばらくは要求について。

　顧客が要求を承認したら、後で変更が発生しませんようにと願うのはかまわない。しかし、一般的なプロジェクトでは、コードが書かれる前に顧客が必要なものを正確に説明することはできない。これは顧客が下等生物だからではない。あなたがプロジェクトに長く従事するほどプロジェクトをよく理解できるようになるのと同様に、顧客もプロジェクトへのかかわりが長くなるにつれて、その内容をよく理解するようになるからだ。（中略）・・要求に断固として従うような計画は、顧客の意見を正しく反映させない計画である。
《Code Complete 第2版 上, 2005/03/28, 日経BPソフトプレス, p.45》より

だから変更管理の仕組みが重要ですと。どうしても変更要求が来るとネガティブに受け止めちゃうなー。「淡々と変更管理するだけだからー。」と言っていた某Kさんの境地にたどり着けるのはいつのことやら。

　プロジェクトが発足したビジネス上の理由を振り返ってみると、さまざまな要求が目の前から消えていく。「機能」として考えたときは良さそうに思えた要求も、「ビジネス上の価値」として評価すると、とんでもない考えに思えるかもしれない。
《Code Complete 第2版 上, 2005/03/28, 日経BPソフトプレス, p.47》より

この視点は忘れちゃだめよね。「便利機能」を提供するのではなく、「ビジネス上の価値」を提供する。区分けはなかなか難しいけど。
あと、この後に続く要求に関するチェックリストは良い。見直し必須で。

　設計プラクティスの調査によって、設計の根拠が設計自体と同じくらい保守にとって重要であることがわかっている。
《Code Complete 第2版 上, 2005/03/28, 日経BPソフトプレス, p.52》より

そう思ってた。めっちゃ思ってた。でも出来てなかった。どんな風に書いてもらうべきか、決められないまま時は流れて、浮かんでは消えていったから。ありふれた言葉だけ。あの日あの時あの場所で。
いわゆる開発標準で用意されているドキュメントのフォーマットって、設計根拠を書くようには出来てないよなー。少なくともうちのは*1。みんなどうしてんだろ。木になるね。

　アーキテクチャは、使用する主なファイルやテーブル設計を説明できるものにする。他に検討されていたデータ構造を説明し、最終的な選択が正当であったことを説明する。顧客IDのリストを管理するアプリケーションのアーキテクチャで、顧客IDのリストをシーケンシャルアクセスのリストで表すことにした場合は、ランダムアクセスリスト、スタック、ハッシュテーブルよりもシーケンシャルアクセスリストが適している理由を説明すること。このような情報は、コンストラクションの際にアーキテクトの考えを理解するのに役立つし、保守作業の際にもかけがえのないヒントになる。アーキテクトの考えがわからなければ、字幕なしで外国映画を観ているようなものである。
《Code Complete 第2版 上, 2005/03/28, 日経BPソフトプレス, p.53》より

これも上で書いてあるのと同じことですね。根拠は大事だよー。という話。
てゆーか、この3.5.1 一般的なアーキテクチャの構成要素(p.51〜p.64)に書かれてることはプロジェクト開始前に絶対読み返そう。コピーしてメンバ全員に配りたいぐらいだ。

眠い。のでおひらき。

*1:知らないだけの可能性もあるけど