Magnolia Tech

いつもコードのことばかり考えている人のために。

『改訂新版　良いコード／悪いコードで学ぶ設計入門 ―保守しやすい　成長し続けるコードの書き方』で学ぶコードの”価値観”

改訂新版　良いコード／悪いコードで学ぶ設計入門 ―保守しやすい　成長し続けるコードの書き方

改訂新版　良いコード／悪いコードで学ぶ設計入門 ―保守しやすい　成長し続けるコードの書き方

Amazon

本書の冒頭に悪いコードの例として「連番命名」という、メソッド名を単なる連番で命名する手法が出てくる。メソッドの目的や振る舞いと関係なく、単に「method001、method002、method003...」と連番で名前を付ける手法のことを指す。

環境上の制約でこのような命名をしている場所でも、意外と中に居る人たちは環境に最適化され会話は案外成立しているものだったりする。

それに「命名の妥当性」で設計内容がレビュアーや、発注者からリジェクトされるリスクを負うより、単なる連番にしてしまう方が合理的な場合もあるのだろう。

ミノ駆動さん（仙場大也さん）著の『良いコード／悪いコードで学ぶ設計入門』が早くも改訂され『改訂新版　良いコード／悪いコードで学ぶ設計入門 ―保守しやすい　成長し続けるコードの書き方』として出版されたので早速注文し、お正月のまとまった時間の間に読み終わった。

設計に関する本なので、わずか数年のうちに設計パラダイムの大きな変化や、特定言語機能やライブラリの大きな変化が有った訳ではなく、説明の仕方や、特に注力して説明する内容が変わった点が改版の中心となっている。この辺りは筆者自らの解説記事に詳しい。

gihyo.jp

一通り読んだ感想として、個人的にこの本で一番気に入ってるのは、第11章「名前設計 ー あるべき構造を見破る名前」で、「どうすれば良い名前になるのか」「こんな名前の付け方になっていると危ない」という事例が数多く収録されている。

正しいコードであるために適切な名前をつけよう...これは非常に大事な考え方の一方で、既存のコードベースがそれなりの規模で存在すると必ずしも「正しいからとってできるわけではない」状況に遭遇することもある。

冒頭に出てきた「連番命名」が適用されているプロジェクトだって、中の人はずっとその状況を変えたいのかもしれない...だけど、変えるよりも現状のまま維持した方が、（その場における）生産性はそれなりにキープできる、ということが判断されているのかもしれない。

だからこそ「何が良いコードなのか」ということを理解しておいて、それとの差異を把握することが大事なんだと思う。人は、「現状を正しい」と思いたい正常性バイアスに囚われているものだけど、それを打ち破るには違う価値観を学習するしかない。

いきなり全部は変えられないし、命名規則を変えたからといって突然明日からの生産性が上がる訳でもない。

でも知っておくことで、それを選択すべきときに「選べる」というのは大きな違いだったりする。

そういう知見がたくさん詰まっているので、全部一気に読み込む必要はないし、全部を頭から信じる必要もないし、全部を教条的に明日から適用する必要もないけど、自分のデッキの中のカードを増やすつもりで読むといいな、と思います。

で、という話は、この本の中にも出てくる...第16章の「理想系を知ってはじめて課題を知覚できる」を参照のこと

あと、一方で「悪いコード」ちょっと言葉が強いので誤解を生みやすいかな、とも思った。

実際には分かりやすく「悪い人」が居て、意図的に生産性の低いコードを入れていくわけではなく（そりゃ業務妨害だ...）、さまざまな制約の積み重ねを途中で補正しないまま放置されることで結果的に「後世の人にとって都合の悪いコード」ができあがってしまうわけで、「罪を憎んで人を憎まず」という言葉がありますが、「悪いコードを憎んで人を憎まず」という姿勢が大事だよな、とも思いました。

（なので、皆さん、あまり職場や、OSSコミュニティなど、他者との対話において「これは悪いコードだ！」という言い方はやらないようにしましょうね...無用な軋轢を生んでしまう時があります）

というわけで、改訂版も代わらずお勧めの1冊なので、皆さん買いましょう、読みましょう

そしてレビューのときに「この本に書かれている、こんなやり方もあるよー考えてみてねー」とさらっと言ってあげましょう！

命名は大事だよなー、と思いながらポストしたら、思いの外反響が有ったので、リンクを張っておきます。引用とか、リプライでの意見も興味深いですね。