イントロダクション

製造工程が最適化されていると、死に物狂いになって仕事をしなくたって効率よくやれるよっていう話。正しいプログラム製造がおこなわれていれば、小規模少人数で、十分な成果があげられる。確かにその通りだと思う。同時に、「でも難しいよな」というのが率直な感想だった。

設計とアーキテクチャ

■所感
なかなか面白かった。引用されたグラフも、確かにその通りだよなって納得できるものだった。
技術書って、読み慣れている我々でも眠くなることしきりだが、本書に限ってはそれがなかった。とても読みやすい、1章を読み終えた率直な感想だ。

■内容について
設計とアーキテクチャは、粒度こそ違うけれど結局おんなじものだよと言っている。なるほど、DFDみたいなものだろうか？レベル０のDFDがあって、レベル１、２と細分化されている感じだ。でも、レベルの差こそあれ、同じDFDだよ、と。今どきDFDかよって突っ込みが入るだろう構造化設計なので、あまり深くは触れないが、エンジニアにはわかりやすい例じゃないかな。。？

この設計が汚いと、後でえらい目に合うよということがわかりやすくグラフで示されていた。例として、ウサギとカメの話をだして、世の中のプログラマはウサギばかり。正しいのはカメなんだ理論を展開する。わからないでもないが、これは著者がアメリカ人という、地域がらによるところが強いんじゃないだろうか？スピード重視のウサギ、堅実なカメ。日本においては、経営者側がエンジニアにウサギであることを要求するケースが多いと思う。国民的な気質でいえば、カメエンジニアが圧倒的なんじゃないだろうか？

このカメのジレンマ≒VBが淘汰されない現実につながっているような気がするが、話がそれそうなので深くは突っ込まない。。

まぁ、中にはウサギもいる。とりあえず速度重視で、リファクタリング作業は後回し。テストコードを書くなんてもってのほか。そう主張する人も多々いる。往々にして、そういう人の書いたコードを保守メンテかけると、とんでもないコストがかかるのもよくわかる話。でも、日本ウサギの本当の怖さは、自身がウサギであることに気付いていないことだと思う。「私SQL得意だから」と言って、ビジネスロジックをSQLにごりごり書いちゃうような、そんな人に出会ったことはないだろうか？ブラックボックスだらけになったとしても、「SQLだけを直せばいいんだから、このほうが効率的だ」と言ってきかない人、あなたのまわりにいないだろうか？アメリカウサギは、ウサギたらんとしてウサギだから、それこそウサギ小屋を準備できる分ましなんじゃないだろうか。

次の例として、TDDの有無で開発効率にどのくらい差が出るかの話だった。まぁ、TDDの圧勝。アーキなしのフルスクラッチより、TDDでコードを書いたほうが早い、その理屈はよくわかる。何かしら指標があったほうが、最適化の指標が見えているので変に考えなくても済むからだ。

だた、これもちょっと微妙で、TDDのような、背筋というか道筋というか、そういった一本線があればアーキがあろうがなかろうが関係ないような気もする。まぁ、その一本線に当たるものがアーキテクチャなんだろうけどね。