途中、ダメ本かと思ったが一部を除いてまあまあの内容だった。
いまいちだったのはコーディングに関する記述の部分。もっとも私自身にグループでの開発経験が無いので、私のほうが間違っているのかもしれない。しかし以下のようなやり方はマズいと思う。
P19
私（駒谷）がプロジェクトリーダーをしていたとき、Ｃ言語でソースコードを開発しましたが、そのときは１関数１ファイルにしました。
…え？
P19
関数の数が数百個になるとファイルの数も数百個になります。しかしファイル名に同じ関数名をつけておけばわざわざ探す必要はありませんので、見やすくなります。これもひとつの考え方です。
確かにひとつの考えかたかもしれんが…。grepとか使えば？
MODULE とか http://www.cmagazine.jp/src/kinjite/c/volume.html#index25 にもあるように、ライブラリなどの特殊な場合を除いて１関数１ファイルにしないほうが良さそうである。この方法の最大の欠点はファイルスコープ(staticをつけた変数と関数)が使えなくなってしまうことにある。Ｃ言語には「関数」「ファイル」「グローバル」の３種類しかスコープが無く、ソフトウェアの規模が大きくなったときに情報隠蔽が難しくなるという弱点がある。Ｃ言語ではスコープは貴重な資源なのだ。特に組み込みソフトの世界では、ソフトウェアの大規模化が進んでいるため情報隠蔽の重要性は増している。これらのことからも、スコープをみすみす一つ無駄にするこのルールは悪いルールであると言わざるを得ない。
P20
共有フォルダの更新方法
更新のタイミングを決めます
絶対トラブル起こると思う。ここはバージョン管理システムが必須だろう。
P20
障害処理票の起票方法
バグが発生したら障害処理票を作成しますが、障害処理票の書き方、管理の仕方などを決めます。
バグトラッキングシステムではダメなのだろうか？
どうも手法やツールが古臭い。本書は現在（もしくは過去）に企業で行われている方法の解説という趣旨で書かれているのかもしれない。たしかにそれに慣れていれば入社後すぐに順応できるだろうから、ある意味「実用的」と言える。しかし、そういった方法で開発をしている日本のソフトウェア産業は国際的に弱いと言われている。次代を担う学生に現行の方法を教えるだけでは不十分だろう。
ずっと受けたかったソフトウェアエンジニアリングの授業(2)posted with amazlet on 07.01.31
