結論：変な技術力皆無のインフルエンサーの言っていることに惑わされてはいけない
ミノ駆動本に書いてあること、書かれていないこと
この本書かれているのはコードの修正の仕方である
この本にはコードの書き方が書かれていない
繰り返すが良いコード/悪いコードで学ぶ設計入門にはコードの書き方が書かれていない
多分お前一体何を言っているんだと感じていることだろう。だがこれは著者のツイートからも明らかな事実である
何と著者は設計とリファクタリングを同じ意味で使っている
すなわちミノ駆動本に書かれているのは「誰かが書いた悪いコード」を「ミノ駆動が思ういいコード」に直す方法である。実際に本文を読めばわかることなのだが、恐らくミノ駆動氏にはゼロからコードを起こす能力はない
実際にミノ駆動本を読めばわかるのだが、あの本、コード例が全て「既存のソフトウェアの”悪しきコード”を"いいコード"に直す方法」しか書かれていない。すなわち、修正対象となるコードはあらかじめ与えられている前提なのである。前任者が頑張って書いたコードをミノ駆動氏が「これは悪しきコードだ」とか独断と偏見で断罪しながら修正しているだけの本であり、何とミノ駆動氏自身がゼロから書いた”いいコード”は全く含まれていないのである
ミノ駆動本の問題点
本当は技術的な問題点にも触れたかったのだが、あまりにも問題点が多すぎて1ヶ月頑張ってもまとめきれなかったので以下の点を指摘するにとどめる
- データクラス害悪論が主張として謎すぎる
- 綺麗なコードの書き方の本なのにマジックナンバーが現れている箇所が大量にある
- DBアクセス等のIOレイヤーが全く意識されていないコード例となっている箇所が多い。これ永続化どうすんのという箇所が複数ある
- 何故そう言った明らかに問題のあるコードが現れてしまうのかという技術的な理由や歴史的な経緯に著者が一切興味を示していない
例えばだがデータクラスの代わりに値オブジェクトを使えとはエリック・エヴァンスは一言も言っていないし、ドメイン駆動設計的にも正しくない発想だが…(データクラスを排除して複雑性を増すのであればそれはDDDの思想に反する)
本書にはこの程度では済まないもっと重大な問題点がある。文章がSNSやQiitaでバズる書き方の水準にとどまっており、そもそも出版水準に達していないのである
良いコード/悪いコードで学ぶ設計入門を読み始めると冒頭10ページで「技術駆動命名」「バグ化」「生焼けオブジェクト」なる著者独自用語が3つも導入される。しかもこれら3つのどれもが著者独自用語なのか一般用語なのか見分けがつかないような説明がなされる。挙句バグ化に至っては本文中に一度も定義が書かれていない。いや、マジでバグ化って一体何？
ミノ駆動氏は大学院を出ているとのことだが、著者は大学でアカデミックライティングを指導されなかったのだろうか
また、それがいいコードであるか悪いコードであるかをミノ駆動氏の主観で決められているため、その点にも問題がある。はっきり言ってしまえばコードレビュー時に「俺が気に入らないから直せ」と言ってくるような内容のため、私はミノ駆動氏のような人物とは一緒に仕事をしたいとは思わない(そもそもデータクラスを完全に禁止されかねない環境で働きたくないが)
ミノ駆動氏について
ミノ駆動氏は組み込み出身とのことだが、私が思うに恐らく彼はハードウェアに近いレベルは触った経験はないと思われる
これに関しては私の組み込みエンジニアとしての経験に基づく推測に過ぎないのだが、恐らく組み込み時代にミノ駆動氏が触っていたのは画面等の装置のユーザインタフェース側だと思われる
例えばだがミノ駆動氏は以下の問いに答えられるだろうか
- 組み込みエンジニアの世界では1バイトが10ビットになったり11ビットになったりすることがある。それは何故か
- 装置によくついている緊急停止の赤いボタン。人命にかかわるのでこのボタンのコードは絶対にバグがあってはいけない。この赤いボタンには典型的な設計パターンがある。それは何か
最初の1つについては補足説明しておく。実は世の中に1バイト=8ビットなる定義は存在しない。組み込みの世界ではとある理由から1バイトを10ビットとして扱った方が都合がいい状況が存在するのだが、それは何故かという問いである
また、元組み込み出身のエンジニアの特徴としてRDBがわからないという症状があるのだが、恐らくミノ駆動氏もRDBはあまりわかっていないと思われる。実際、良いコード/悪いコードで学ぶ設計入門の本文中に「nullを未設定の意味で使ってはいけないからObject.emptyのような値を持たせましょう」のような記述が現れる。しかし未設定をNULLでなくそれ特有の値で表現するのはRDBの世界では逆に典型的なアンチパターンである。要するにミノ駆動氏はアプリケーションプログラム側の都合だけで判断しており、RDBまで含めたシステム全体を見れていない。ミノ駆動氏はアーキテクトとのことだが、DBがわからずアプリケーションプログラムしかみないアーキテクトなどあり得るのだろうか
また、ミノ駆動氏がいわゆるクソコードに揉まれて非常に苦労したのは事実だと思われるので、その点については同情するのだが、だからってその結果
「自分の書くコードこそが絶対の正義。お前の書くコードは悪しきコード」という思想になってしまった人物を擁護することはできない。
最後に本書に「コードの修正の仕方」は書かれていても「コードの書き方」が書かれていない理由であるが、一般論として配属後のITエンジニアがやるのはすでに作成されたプロダクトの修正だとか新規画面追加とかであるため、単にミノ駆動氏にゼロからプロダクトを新規に作成するプロジェクトに参画した経験がないだけだと思われる
恐らくミノ駆動氏には要件定義して、それにそったUMLをゼロから起こす能力すらない。確かに詳細設計の能力は高めだと思われるのだが、それも既に完成したプロダクトが手元にあるからそれをリファクタリングしているだけであり、つまりミノ駆動氏自身のコードを書く能力はあまり高くないというのが実際だと思われる
どうしてもミノ駆動本型の他人の書いた悪いコードを断罪する本を読みたいならかなり古いがCプログラミング診断室の方をお勧めする