英語で読む「達人プログラマ#7」
１週間に１章ずつ読み進めてきた「達人プログラマ」も全８章のうち７章「Before Projects」まで読み終わった。
If the requirement is stated as "Only personnel can view an employee record," the developer may end up coding an explicit test every time the application accesses these files. However, if the statement is "Only authorized users may access an employee record," the developer will probably design and implement some kind of access control system.
プロジェクトで必要な要求条件を「収集」するだけでは駄目な例として、「Only personnel can view...」と書く場合と「Only authorized users may access...」と書く場合を挙げている。アクセスコントロールの話が出てきて、前の章のメタデータの話ともリンクしてくる。
It seems incredible to us that anyone would seriously consider documenting information this dense using only simplistic stick people such as Figure 7.3. Don't be a slave to any notation; use whatever method best communicates the requirements with your audience.
1996年に出たばかりのUML(Unified Modeling Language)のuse case diagram記法に対してincredibleだと批判的だ。そして、notation（記法）の奴隷になるのではなく、要求事項を決めるベストなコミュニケーションをすべきと言っている。
Sometimes you will find yourself working on a problem that seems much harder than you thought it should be. Maybe it feels like you're going down the wrong path—that there must be an easier way than this!
難しい問題に直面したと思ったら、より簡単な方法があるはずだと。「達人プログラマ」が米国で出版された1999年にはエドワード・ヨードンの「デスマーチ」も出版されており、プロジェクト運営の難しさはプログラマの共通課題になっていた頃だ。
最後の章「Pragmatic Projects」は、どういう内容で終わるのだろうか。
この記事が気に入ったらサポートをしてみませんか？