導入
お久しぶりです。
三角関数ちゃそです。
皆さんはGWをどう過ごされましたでしょうか。
私は4/30-5/5と、1週間ほどTokyoで羽を伸ばしてきました。
久々に友人と会って飲む酒はうまい！
（×：酒はいつでもうまい。）
さて、1週間ほど遊び呆けたので、それを埋め合わせるために勉強しようと思いまして。えへへ。
1週間の怠惰を2日で取り戻せると思い込んでいるところから勉強しないといけないですかね。えへへ。
昨日と今日は以下の本を読みましたとさ。
Amazonはこちら：
はい。最近発売された設計技術書、いわゆる
#ミノ駆動本
ですね。
こちらを読んでの感想というか批評というかレビューというか。
それらをまとめようというのが今回のブログです。
自己紹介
さて、今回はブログ投稿ツイートにハッシュタグ「#ミノ駆動本」をつけたので、普段よりも多くの方々の目に留まる可能性があるかと思います。
その分、私とはじめましてのブログ閲覧者も増えるでしょう（増えなかったらそれはそれでさみしい）。
そのような方々へ向けて、一応自己紹介（という名の自身のバイアス説明）をいたします。
経歴
某大学院数学専攻修了。
学生時代はプログラミング未経験、現在社会人3年目。
世間一般で言うところの、所謂「駆け出しエンジニア」。
お仕事では、主に地理情報システムに関連するアプリを作成。
使用言語
- C#：一番好き。使えるのであればこれを使いたい。
- Java：読み書きはできる。機会があれば使いたい。
- Python：仕事の都合でたまに使う。あまり好きじゃない。
- JavaScript：仕事の都合でたまに使う。クソ。
技術に関する趣向
使用言語からわかるかと思うが、基本的にオブジェクト指向言語が好き。
特に、モデリングや設計についてあれこれ考えるのが好き。
（昨年度、結構クソコードに殴られる事案があり、その中で生き耐えるために勉強した節も大きい。愚痴は以下の記事へ。）
本を購入したきっかけ
先ほど
昨年度、結構クソコードに殴られる事案があり、その中で生き耐えるために勉強した節も大きい。
と書きましたが、「#ミノ駆動本」の著者、ミノ駆動さんのことはその過程で知り得ました。
一応Qiitaのページを以下にリンクしておきます：
Qiitaの記事はとてもわかりやすく面白く、クソコードと殴り合う良い武器になったことをよく覚えています。
そんな経験がありまして、その延長として今回ミノ駆動本を購入しました。
レビュー
…以上が自己紹介になります。
自己紹介を踏まえると、今回のレビューは
プログラミング・実務経験がともに浅い初心者が設計を学ぼうとして購入した
という視点と言えます。
そんな感じで、本題のレビューへ進みましょう。
内容は非常に良かった
記述されている内容は、わかりやすくかつ合理的で、非常に良かったと思います。
特に、コードに頻出するアンチパターンとその対処法が充実していたため、TIPSとして便利だと思いました。
サンプルはJavaで記述されていましたが、Java固有の機能やフレームワークを使用することは少なかったように思います。*1
ほかの言語でも使えるようにしたい！といった筆者の意思がビンビンに感じ取れて、そこは評価されるべきかと思います。
まとめると、
様々なアンチパターンに対して様々な言語に通ずる解決策を提示してくれる技術書
といった印象を受けました。
困ったときの良い相談役として、この一冊。
それが、この本の有用な使い方ではないでしょうか。
設計は正解/不正解に2極化されるのか
と、ここまでべた褒めな感じですが、
以降、批判的？な意見を少し述べていきます。
この本は、タイトルにある通り、
「良いコード」と「悪いコード」を例に出し、その比較によって設計を学ぶ流れとなっています。
しかし。
そもそも、世の中には「良いコード」と「悪いコード」しかないのでしょうか？
多分そうじゃないはず。
もちろん、ミノ駆動本に書かれたアンチパターンをすべて排除したら、変更可能性やテストのしやすさが担保されたコードになるといえるでしょう。
しかしながら、納期、すなわち時間の締め切りがある場合はどうでしょう。
ミノ駆動本に書かれた技術の多くは、その有用性を理解したうえで、導入する時間を設けられるのでしょうか。
先に
昨年度、結構クソコードに殴られる事案があり、その中で生き耐えるために勉強した節も大きい。
と述べたのですが、そういうクソコードをつくるような連中に限って、直せと言うと真っ先に返ってくる言葉が
「そんな時間はない」
なのですよ。
- interfaceを作って継承しろ→interfaceを書く時間がない
- このクラス名変更しろ→クラス名を考える時間がない
- このプロパティreadonlyにしろ→readonlyを書く時間がない
- テストコードを作って動作を保証しろ→テストコードを書く時間がない
こんなことを言われます（これは私の実体験です）。
あれ、本のレビューと愚痴が混在していないか？
クソコードを書く人間の多くって、
時間までに正しく動いた実績が欲しくて、保守や拡張が見えていないタイプ
ではないでしょうか。
あいつら、基本クズなんですよ。
そういったタイプの人間に対して、この本の内容はその有用性を理解したうえで、導入されないんだろうなと思いました。
というのも、これらの技術を実践するのは、案外手間だからです。
一方で、このミノ駆動本で本来刺すべき対象は、そういったタイプの人間であるべきだと思います（実際16章にも似たようなことが書かれています）。
そういったタイプの人間を少しでも刺すためには、どのようなアクションをとればいいかについても、この本の中でフォローがあるのですが。
そのフォローがいまいち弱いというか。
うーん。
何といえばいいんですかね。
この本では「良いコード」と「悪いコード」の2極化がされているような気がするのですよ（少なくともそんな印象を受けるような言い回しが多いです）。
実際のアンチパターンには
- これだけは絶対にするな
- 時間があれば解決したい
といった強弱があるはずです。
この本の中ではその強弱がなく、すべてのアンチパターンが同列の問題として語られているのは、少し違和感があります。
逆に、アンチパターンに強弱があれば、
「まずはここから実践してみよう」
といった形で、段階を踏んだ実践ができたのに…と思います。
（似たようなことは16章に書かれているので、そこまで読めばある程度考えられると思うのですが、16章が結構終盤なのとそこに至るまでの内容が濃いのもあり、道中上記の不安が読んでて大きかったです。16章の内容が導入にあるだけでも印象が異なると思うのですが…）
いや、まあ。
究極的には全部できたらそれが一番良いことですし、作者としてはそういう意向なのでしょう。そもそも、作業の優先度は現場の主観で決めるべきですし。そういうスタンスの本なのかしらね。
この本での学びをどう演習すればよいかがわからない
少し、毛色を変えて。この本を教材に勉強することを考えます。
コードは基本複数人で書くものですから、この本による学びは他者と共有されて意義を持つと思います。
例えば、プロジェクトに10人開発メンバがいるとします。
そのプロジェクトに対してこの本の内容を生かす場合を考えてみましょう。
例えば、メンバーのうちの1人が読破したところで、そこまで意味がないでしょう。
1人が「良いコード」を書く横で、残り9人が「悪いコード」を書いた日には、その1人が苦しむことになるでしょう（その1人こそが、本来正しいことをしているはずなのにね）。
他方、10人の開発メンバがみんな同じようにこの本を読み進めて、同じレベルで実装をすれば、その効果は絶大でしょう。悪いコードが生まれる可能性が減って、リファクタリングなどの手間が減りますからね。
コードを複数人で書く以上は、この本による学びはその複数人全体で共有されている必要があります。
みんながみんな、この本の内容を正しく咀嚼して、正しくアウトプットできればそれにこしたことはないです。
でも、人間って、そんな完璧じゃないので、ある程度の演習は必要だと思うのです。
なので、この本をチームで輪読するだけではダメで、実際に手を動かして技術を身に着けるというフェーズが欠かせないでしょう。
さて、どのように演習をするか。
この本には、サンプルが多くありますが、演習問題は用意されていないのですよ。
じゃあ、自分で演習問題を用意するしかない。
この本の内容は、アンチパターン矯正が主ですから、この本で学んだ内容を試すには、身の回りにクソコードがある必要があります。
つまり、この本で学んだことを演習するには自前でクソコードを用意する必要があります。
これが結構大変そう。
わざわざクソコードを書くのもあれですし、プロダクションコードを引っ張ってくることが難しい環境もあるでしょう。
プロダクションコードを引っ張ってきた場合は、生産者の顔が見えるところでコードに対する批評をするわけですから、議論の場で正しく議論する姿勢を保つことができるかどうかも気になる点です（案外、そういう議論ができない人間は多い）。
なので、演習版みたいな追加テキストが出ると嬉しいかしら。
共通の敵となるクソコード。
実際に「悪いコード」を「良いコード」に修正しながら読み進める演習テキスト。
これを希望します。
その他
著者の書くサンプルコードも、
あるときはゲームを題材に、あるときはECサイトを題材に、…
とコロコロ変わるのはなんだか気になりました。
私も簡単なゲーム（シューティングゲームやブロック崩し）はつくったことはありましたが。サンプルコードに出るようなRPGは作ったことがなかったので、そういった例示は正直分かりにくかったです。
私の知識がないのが悪いのかしら？
あとは、この本独特？の用語が気になります。
生焼けオブジェクトとか神クラスとか。
多分、他で見聞した記憶がないので、この著者が考えた造語なのだと思いますが、それらがフラグ引数や値オブジェクトのような外でも見る語と並列に語られているのは、どうなんだろうと思ったり（設計の入門書のような立場をとるのであれば、なおさら）。
なんというか、用語が定義されるスコープが揃っていないような。そこがすごく引っ掛かりました。
----------------------------------------
終わりに。
結構ぱーっと読んだので、熟読はできていないです。
後でまた何かあれば、続編を書くかもしれません。
とりあえず。今日はこんな感じ。
クソ真面目なGWだったなあ～…
