日々常々

ふつうのプログラマがあたりまえにしたいこと。

「現場で役立つシステム設計の原則」の感想

目次流しは以前書きましたが、読み終わってるので改めて。

一緒に開発する人には読んでおいてほしい。可能なら手元に置きながら開発してほしい本です。手頃なサイズ、重量、厚さ、価格ですし。鈍器本系に比べれば持ち運びやすい。実際レビューやペアプロの際、「あの本に書いてるんだけど・・・」という感じで何度か参照しています。

読書会をしてみて

4つのイベントに参加しました。うち2つは輪読形式の読書会で、最初から最後まで読み上げです。有用なのと同時に危険でもある、というのが読書会での感想です。

平易な文章で理解しやすいように思えるのですが、表面だけで理解した気になっていると間違いなく実践で役立たない 、そんな感じです。現場での実践をシミュレーションするだけでも多くの問題にぶち当たるでしょう。そういうのがあっさりした言葉でさっくり片付けられています。このようなことを通じて「ただの理想論」と片付けるのは簡単ですが、残念ながら本書の内容は殆どが実践されているものです。特殊な一つのプロジェクトではなく、複数の会社の複数のプロジェクトで。

実践しないとわからないことが膨大にあり、それを乗り越えてようやくさらっと書かれている1文に届く感じです。読み流せば「ふんふん、まあそうだよなー」で片付いてしまい、簡単に誤解できるし、ややもすれば実践不可な理想論にしか映らないのでタチが悪い。これを危険と言わずなんと言うか。。。

読む際に外すと誤解するポイント

この本は徹頭徹尾「変更を楽で安全にする」ことを書いています。

変更しないものには興味がなく、「どう作るか」ではなく「変更のためにどう作るか」が書かれています。書いていること全てが変更ありきなので、変更しないものや変更できないものに適用しようとしても無理があり、解釈が歪みます。(しかも歪んだまま解釈できてしまう。)

どんな本もそうなんですが、書かれていることはたいていそのまま適用できません。現場のコンテキストに応じて調整する必要があり、実践で学べば方針も変える必要が出てきます。その際に変更できるかは重要で、少なくとも変更できるように作っていなければ変更はできません。得た学びを反映するためにも「変更を楽で安全にする」必要があるわけです。

読み終えて

実は書かれている内容をあーだこーだと議論してもあまり意味がない本なのではないかと思いました。議論すべきは、書かれていることを実践した結果の経験に対してです。なのでコンテキストの共有できない状態で会話すると全く実になりません。話すのならば実践経験を語れる場で、できるならば同じ経験を共有した人たちがいいでしょう。そう言う場で実際のコードと本を突き合わせて話すと、短い言葉の随所に詰め込まれた情報がようやく読み取れます。

噛んでたら味が変わる系の本ですね。

おまけ(半年前のLTスライド)

ddd-alliance.connpass.com

このイベントでのスライドです。新幹線の終電に乗ろうとしたら、山手線を逆方向に乗ってしまって帰れませんでした。ドンマイ。