What is it, naokirin?

きのこ本 感想 Part3

きのこ本こと

プログラマが知るべき97のこと

プログラマが知るべき97のこと

の感想、Part3です。

他の方々より読み始めるのが遅かったというのが、上のきのこ本の紹介を含むブログの件数だけでわかりますね。

07 共有は慎重に (ウディ・ダーハン, Udi Dahan)

ここではコードの再利用を進めるときの注意点が記されています。

著者自身の実体験として、初めてのプロジェクトでコードの再利用を推し進めた結果、依存関係を促進してひんしゅくを買ったという話が語られています。

確かに再利用というのは凄く重要で、上手くするととても便利なのですが、異なる2点の部分のコードを再利用可能なコードによってまとめたとしても、もともとその異なる2点が別の役割を持たされていたとすると、のちにその片方の役割が少しでも変更されれば、面倒な修正が待っていることになります。

たまたまその時同じようなコードになっていると言うだけで、その部分をライブラリ化して再利用を推し進めると、後々痛い目にあってしまう。

これは何がいけなかったのかというと、「コンテキスト」を見逃していたことが問題だったと著者は語っています。

つまりはコードの持つ役割、状況などをしっかりと見極めたうえで、「共有」を進めるべきだということですね。

08 ボーイスカウト・ルール (ロバート・C・マーティン, Robert C. Martin アンクル・ボブ)

この「ボーイスカウト・ルール」というのは、「来た時よりも美しく」というルールのことのようです。

この「来た時よりも美しく」という言葉に倣って、「モジュールをチェックインする際には、必ずチェックアウト時よりも美しくする」という風にしようと言っています。これを行うことでシステム全体の品質もおのずと向上されるという確かにとても良いルールだと思います。

ただ、「美しくする」とはいっても「完璧にする」必要はないと言っています。つまり、「一つでもよいので良くする」ことを目指そうと言っています。

これは心構えとして、そして常識として持っておくべきですね。

09 他人よりもまず自分を疑う (アラン・ケリー, Allan Kelly)

他人よりもまず自分を疑う。これって意外と難しいんですよね。

ただ、確かにプログラミングでコードを書いていて起こる失敗は、自分の間違いであることが多いのは事実ですね。

そうでなくとも、基本的に相当マイナーなツールを使っていたり、α版などを使っているときは、バグの根本にそう言ったツールやライブラリが関与している可能性もありますが、そうでない、一般的に使われているようなツールではめったにないと思われます。

とはいえ、これが一概には言えない時もなくはないのが残念とも言えます。(某社の某IDEコンパイラなどは特に怪しげな時があります。確かにそういうものが絶対ないとは言えません。)

しかしながらこういうことよりも、やはり疑うべきはまずは自分であることには違いありません。
そちらの方がずっと確率的に高いからです。

またプロジェクトで複数のプログラマが関わるときも、そのような考えでバグに臨むべきだと思います。

最後に

「最後に」という言葉で大体締めくくっていっているわけですが、今回は感想が少々短めですかね。
プログラマではないので、この辺りは自分の体験がないため、「おそらくそうだろう」というのが大半を占めてしまっていて、感想が (いつも以上に) 薄い内容になってしまいました。

今回の3つのエッセイに関しては、ある程度もともと意識できているかな、とは思います。
08のエッセイについては特に、TDDの考えからするとチェックアウト時よりチェックイン時のほうが汚くなっているというのは普通はあり得ませんし、良い方向に向かっていないというのも何のためにチェックインするのか私には分かりません。

いろんな場所でこの本についてのすすめを聞いてきたのですが、確かに良い本だと思います。
お勧めをするにはまだ読み足りないですが、それでもおすすめ出来る本ではないでしょうか。