開発現場の掟

夜に立ち寄った図書館でコンピュータ関連の棚を眺めていたら、この本が目についたので、その場で読んで帰ってきました。

記憶に残ったところを3箇所だけメモしておきます。

「基本設計では実装のことを考えてはいけない、は間違い」という話。

たとえ顧客に見せる基本設計書の中には技術的詳細を書かなくても、実装のことを考えなくてよいわけではない、常に考えるべし、とのことです。技術的な側面からの見解（要検討事項）を"テクニカルノート"として書き、基本設計書に別紙として添える方法も、紹介されていました。

こういった警句が必要ということは、それだけ我々は、文字に起こさないものを、思考のスコープから外してしまいがちなのかもしれませんね。

この話から、goyokiさんが以前ブログに書かれていた「メソッドのブラックボックステストをするとき、メソッドの内部実装の詳細を参考にしてはいけないわけではない」という記事を思い出しました。

ブラックボックスのテスト設計手法でもコードを見なくていいわけではない http://goyoki.hatenablog.com/entry/20120221/1329828232

単体の物をモデル化しようとしても、目的を見失うよという話。

本文では、「車」のモデル化ではなく、「車を運転する」をモデル化することに意味があるという例が挙げられていました。

昨日、「思考のおもちゃ箱」からの連想で、オブジェクト指向の解説で現実の写像の話を使うとなぜ非難されることがあるのかよく分かっていない、と書きましたが、こういったことも関係があるのかもしれませんね。井庭先生の文章にも、「人によって目的が違うため、（標準化しないかぎり）モデル化したい部分や方法は異なる」といった旨のことが書いてありました。

帰宅してからの作業を完全にルーチン化したら、夜に仕事（この本の著者の場合は執筆作業）ができるようになった、という話。一種のライフハックのようです。

数日前にも、はてなで次の記事が話題になっていましたね。

やりたいことを帰宅後にもっとできるように、自分もルールを決めようかなと思いました。