存在じゃなくて目的から名前を設計するのだー！ #ミノ駆動本

かなり良かった

「良いコード／悪いコードで学ぶ設計入門」を読んだ。読む前は特に書くつもりはなかったんだけど、かなり良かったからブログを書くことにした

gihyo.jp

どういう本？

この本は、読みやすくて変更しやすいコードの書き方と設計についての入門書

どのようなコードが悪いコードなのか、そこにどういう問題があるのか。それに対してオブジェクト指向設計で、どのように設計してコードを書けば、より良いコードを書くことができるのかを、分かりやすい例でコードを追いかけながら、学ぶことができる

読むと良さそうな人

2,3年目くらいで「もっと良いコードを書きたい！」とか「どんなコードが良いコードなんだろう？」って考えてる人や

もうちょっと経験があって、機能追加や改修をするときに苦労をしてきて「どんな風に作ればこの苦労を減らすことができるんだろう？」って悩んでる人には、特におすすめ

それ以外でも、今はコードを書くよりもマネージメントをしてる、って人が知識のアップデートをするのにも良さそう。そうすると、チームの誰かが「プロダクトを改善するのに挑戦してみたい！」って言ったときに、サポートしやすそう

ミドルからシニアなソフトウェアエンジニアは、自分の中にあるコードの書き方や設計の考え方との差分を楽しみながら読めば良いと思う

頭の中を見せてくれてるのがありがたい

読みやすくて変更しやすいコードを書くための設計についてめちゃくちゃ考えて実践してる人が、分かりやすくそのノウハウを共有してくれてるのが、とてもありがたい

「あの人の頭の中を開けて見てみたいわー」ってのを実際にさせてもらってる感じ

例が分かりやすい

コードのサンプルがゲームなので、自分にとって新鮮で楽しく読めた。そして、例の内容もコンパクトで要点が分かりやすい。ゲームの例だけじゃなくて EC サイトの例もあるので、飽きずに読み進めることができた

それに、文章も分かりやすくて読みやすい

推し章：第16章設計を妨げる開発プロセスとの戦い

僕の推し章を紹介しておく。いきなり終わりの方の章なんだけど、この章がいちばん好き

この本は、最初からすごい勢いで「悪魔だー！」とか「退治だー！」とか言ってるから、僕は内心（著者のミノ駆動さんは、実際の現場でどう向き合ってるんだろう？悪いコードを見かけたらすごい勢いで撲滅しようとしてるのかなぁ？でも、そんなの周りがしんどいだけだよなぁ？）とか思いながら読んでたのだけど、この章に答えが書いてあった

そんなことはやってない。よかった。欲を言えば、このことをもっと早く知りたかったｗ

この章では、そういった悪いコードが生み出される背景となっている開発プロセスに目を向けていて、その開発プロセスをどのように改善すると、より良いコードを生み出せる場になるか、また、どんな風にチームのスキルをあげていくか、について紹介している

Fearless Change を思い出させてくれる感じ

参考: Fearless Changeの48のパターンのチートシートを作りました。 - kawaguti’s diary

だから、この本を読んだからっていきなり「悪魔めー！退治だー！」って叫ぶんじゃなくて、まずは、仲間を集めてスモールステップで手を動かすところからね

開発プロセスやチームづくり・組織づくりのことを考えているチームリーダーやマネージャーも目を通しておくと良さそう

そして、この章の中でも「16.4.3 敬意と礼儀」が特に好き

コードレビューで最重要なのは、敬意と礼儀です。レビューを受ける側への敬意を第一に意識しましょう。技術的な正しさや有用性よりも、まずはともに働く、コードを書く仲間を尊重することです。敬意と礼儀を意識しながら指摘することが、コード品質を高める最短経路です。

ミノ駆動さんレビューのときめっちゃ怖そうとか思っててごめんなさいｗ

第10章名前設計

あと、普通に勉強になったのはこの章。この本の中心はここかなぁって感じがした

名前をどうつけるか。それ自体が設計だよねって話

商品が色んな役割を持って大きくなってしまうの、わかるー！現実のモノとソフトウェアのモデルが1:Nになるの、それなー！って気持ちで読んだし

存在ではなく目的から名前を設計することとか、利用規約を読んでみることとか、色んなノウハウが書いてあって、やったほうが良いことも、やらないほうが良いことも、なるほどなぁってなった

あとでもういっかい読んでおこうかなぁ

実は最初は抵抗があった

僕は、コードに対して「悪魔」や「クソコード」みたいに言う人が苦手なので、言葉選びがあんまり好きじゃないなぁって思いながら読んでたのだけど、途中からは「読み物」として楽しむことができた

最後まで読んで分かったのは、その強い言葉が「コード」それも「著者が過去に苦しめられたコード」に対してだけ向けられていて、決して「そのコードを書いた人」や「その環境」には向かってない、ということ

だから、苦手な言葉が並んでても「読み物」として読めたんだなぁ

もし、僕と同じように思って手にしてない人がいたら、手にとってみたら良いんじゃないかな

（「悪魔」や「クソコード」は、僕が苦手なだけなので、とくに使うのをやめてほしいとかは全然思ってないです。ねんのため）

とても良かった！

ということで、頭の中を見せてもらえてとても良かった！

あくまでも、ひとつの設計方針だから、書いてあることを全て鵜呑みにするんじゃなくて、自分の中で咀嚼して、素振りしてみて、手に合いそうだったら道具箱に入れておいて、必要に応じて取り出して使えたら良いかな！

次に読みたい

もし、まだ読んでなかったら、次は「現場で役立つシステム設計の原則」を読むと良いと思う。DB連携や画面まで含めて、どんな風にオブジェクト指向で設計すると、変更しやすいシステムになるか、ってことが書いてある。