本棚登録 : 
感想 : 
最近、新規プロジェクトが少なくなってきたと聞く。
そうであれば、今後は、既存システムの改修案件が増えてくるであろうということで、読んでみた本。
よくあることだが、ソースを書いた人と保守する人は別の人。
だから保守する人はどこを直せばよいのか、わからないことがある。
そんな時、「部分理解」な人でも、できる限り手戻りなく修正するプロセスを確立しておけよってことがこの本の趣旨。
ごもっともです。
主軸は、レビューの大切さ。そしてレビュアーに気づいてもらうように（アンカー効果が働かないように）、変更内容の事前準備をすること。
その方法として、手順は５つ。
・変更内容とその理由を記載した、変更要求仕様書を作成すること。
・縦軸に変更内容、横軸に画面一覧（ソースファイル一覧）としたトレーサビリティマトリックスを作成すること。これで、修正漏れを少しでも防ぐ。だって同じようなソースが至る所にあること多いもん。
・どのように変更するかを記載した、変更設計書を「プログラム言語」ではなく「文章」で作成すること。before/afterを文章で書く。
・レビューを実施して、勘違い・考慮漏れなどを無くすこと。
・ここでようやくソースコード修正。これ直してよ。ちょろです。直しますね。は、ご法度。
まあ、C言語っぽい言葉がやたらと出てきて、SVNとか差分管理ツールとかないんかいとか思わせる言い回し、オブジェクト指向を前提としていないよねとか、オフショア開発ではなく1人プロジェクトを主体としていることが前提となっているように読めたから、使えるところだけ使おう。
0
- 感想投稿日 : 2014年12月28日
- 読了日 : 2014年12月28日
- 本棚登録日 : 2014年11月23日
みんなの感想をみる
