“良いコ/悪いコ”で悪魔討伐! (お排泄物)コード撲滅!
#ミノ駆動本 の感想記事の後編です。よき設計を妨げる様々な悪魔を紹介した後は、まことの名をもって悪魔を封じ打ち払う命名の章から...
- “良いコ/悪いコ”で悪魔討伐! (お排泄物)コード撲滅!
- 10 名前設計 ―あるべき構造を見破る名前―
- 11 コメント ―保守と変更の正確性を高める書き方―
- 12 メソッド(関数) ―良きクラスには良きメソッドあり―
- 13 モデリング ―クラス設計の土台―
- 14 リファクタリング ―既存コードを成長に導く技―
- 15 設計の意義と設計への向き合い方
- 16 設計を妨げる開発プロセスとの戦い
- 17 設計技術の理解の深め方
- まとめ:見習いエクソシストエンジニアに悪魔を見破る目を授けてくれる福音の書
10 名前設計 ―あるべき構造を見破る名前―
「名前重要」で有名な名前付けで悪魔を追い払う章。本書では名前から目的や意図が読み取れるようにした「目的駆動名前設計」というワードを定義して論じていきます。
Managerクラスの悪魔がまた出てきて、ああァ昔の黒歴史が...となりました。(2回目)
会話で出てくるがコードに出てこない名前や形容詞に注意する話など、まさに開発現場の豊富な経験が反映されていて学びが深いです。本章のサンプルコードも実際にありそうで真に迫っていますね。
CQRS
パターンはクラスレベルのデザインパターンよりより大きい粒度のアーキテクチャパターンの世界で、クラウドの文脈で時々登場します。DTO:Data Transfer Object
クラスの話がここで出てきますが、DTOはCQRS
に限った話ではないので初見の方は注意すべきかなと思います。
11 コメント ―保守と変更の正確性を高める書き方―
コメントも注意して扱わないと悪魔になってしまうそうです。
本章は短いのですが、長く使われるコードはほんとこれ!と納得の章でした。僕はクラスやメソッドの日本語コメントはたとえ冗長でもいいからしっかり書く派なんですが、後々の保守や機能追加の時にこれが効いてくるんですよね...。
JavaでJavaDocを書くのは2000年代からもうやって当然の認識でいたのですが、本書にこれだけ丁寧に書いてあるということは、JavaDocが活用できていないプロジェクトもまだまだあるのかな?と思います。恐ろしや悪魔の前兆ぢゃ...
12 メソッド(関数) ―良きクラスには良きメソッドあり―
あらためて取り上げる関数設計の章。
自分を振り返るとメソッドの解説コメントに「XXの場合はnullを返す」などした上でnullを返してる時もあるのですが、本書を機に見直したほうがいいかなあなどと考えました。
メソッド引数でnullを渡さないのは、型サポートなどで制御できる言語もありますね。C#やJava的にはエラーは例外で扱うのが基本の基本のお作法ですが、近年ですとGo言語のように最初からエラーも戻り値で扱うようにした言語もあります。
13 モデリング ―クラス設計の土台―
物事の特徴や関係性を図式化したのが「モデル」、これを作る活動が「モデリング」と定義し、解説する章。
ネットでも話題になったクソコード動画「Userクラス」が淡々と紹介されていてシュールな笑いを誘います。Userクラスは確かにこの手の巨大クラスでありそうなネタですね。
オブジェクト指向の解説だとよく動物の子供が魚類や哺乳類、その子供に実際の種類...とやってしまいがちですが、目的をベースにした目的駆動設計は大事な視点だなと思いました。
14 リファクタリング ―既存コードを成長に導く技―
リファクタリングとは「外から見た挙動を変えずに、構造を整理すること」。マーチン・ファウラー大先生の同名の本に詳しいですが、本書でもコード設計や後々の変更容易性を保つために重要な作業として取り上げています。
コラムにRailsアプリのリファクタリングの話があり、動的言語なので静的言語のC#よりリファクタが高難易度という話があり納得です。Active Record
がどんどん大きくなった、Controller
がFatになった...などの話はよく聞きますね。
ここでのリファクタリングの話を読むとフレームワークの特性を考えて設計、Railsと関係しないところにロジックを分離配置していく...というのが想像でき、『Clean Architecture』で度々語られているようなフレームワーク非依存のコード構造になっていっているのが伺えます。
15 設計の意義と設計への向き合い方
本書の根底のテーマである変更容易性がソフトウェアとエンジニアの価値、成長に大きく結びついているという話がしっかり書いてあって良いです。
エンジニアだけに可能な悪魔を発見する目、レガシーコードを発見できる目を訓練し、無駄な時間を減らして未来の時間を操れる人、時間を操る超能力者になろうという締めが熱い。
16 設計を妨げる開発プロセスとの戦い
コード以外のところにも潜んでいる悪魔を論じる章。
様々な技術書に出てくるワードがあちこちに登場し、そうした本への入り口的な内容にもなっています。様々な手法だけでなくチームへの展開方法も書いてあるのがよいですね。
僕はGitHubの関連機能は使えていないですが設計・実装標準を定めたりレビューする立場ではいろいろ関わってきたので、これは分かる...!となりました。本書に出てくる過去実際にあった設計レビューの会話例が日常みたいなプロジェクトでは悲しいですよね...
17 設計技術の理解の深め方
本書は設計の入り口、設計の初級レベルから中級レベルへのステップアップをフォローし、さらに上のレベルのこれらの本へ進んでほしい...ということで、著名な本をミニ解説付きで紹介しています。
『現場で役立つシステム設計の原則』
『リーダブルコード』
『リファクタリング』
『Clean Code』
『レガシーコード改善ガイド』
『レガシーソフトウェア改善ガイド』
『レガシーコードからの脱却』
『エンジニアリング組織論への招待』
『プリンシプル オブ プログラミング』
『Clean Architecture』
『セキュア・バイ・デザイン』
『ドメイン駆動設計入門』
『ドメイン駆動設計 サンプルコード&FAQ』
『テスト駆動開発』
載っている本はエンジニア界隈でもお馴染み、本書のお墨付きだけあってどの本もお勧めですね。自分は『セキュア・バイ・デザイン』はセキュリティ専門の本かと勘違いしていたので、後で読んでみようかと思いました。(Kindleの奥に眠ったままのエリックエヴァンス本を隠しつつw)
まとめ:見習いエクソシストエンジニアに悪魔を見破る目を授けてくれる福音の書
本が出ると聞いたのは2021年夏ごろ?確か『悪魔の設計(仮)』とかそんな仮題でしたが、待った甲斐がありました。
「バグ化」とか「ダラダラ」とか「べた書き」とかお堅めの技術書だとあまり見ないような平たい文章、技術同人誌っぽい雰囲気もあります。しかし逆に平易な文章はこれから設計力を上げたい人にはとっつきやすいでしょう。
設計関連の良書によく出てくる法則や原則、キーワードも多く散りばめられており、これからスキルアップと悪魔討伐の旅に出かける方へのよい道しるべにもなります。混じって本書独自の造語も幾つか出てきますが、悪魔はまず名をつけて知覚できるようにしないと気付けない訳で、名付けが行われたことにも価値があると思います。
サンプルコードもかなり充実していてRPG風のコードはゲーム世代には懐かしいですし、主にEC2サイトを例にとったまずいコード例もリアリティに満ちています。かなり多岐に渡る悪魔退治のご経験がコードにも文章にも滲み出ている気がします。
自分も駆け出しJavaエンジニアの頃に産み出してしまった何とかManager
クラスとか黒歴史を思い出したり、デザインパターンを知ってとりあえず適用したけど効果がよく分からなかったコードを思い出したり、ヘルプで入った炎上プロジェクトで見かけた酷いコードや酷い現場のことを思い出したり、様々な想いと共に楽しく読みました。
僕も本書に紹介されている技術書類は大体読んでいるしコードレビューする側の立場なので、すでに実践している内容もあれば新たな気づきもあり、本書の主張だとこうだけど自分の思想ならこうだな、と思うところもありました。登場した様々なキーワードについて、関連した本をもう一度参照してみたくもなりました。
読む方によってそれぞれでしょう。新たに学びになったり改めて考え直したり、現場での適用を考えてみたり、人それぞれ様々な刺激を受けるところにも大きい意味があると思います。
これから設計力を高めたい方には、本書の内容が100%正しくて絶対こうだ!という悪魔根絶の原理主義的狂信者スタイルではなくて、こういう考え方もある、自分で考えてから自分の目の前の悪魔にはこの書からこのテクニックを適用してみよう、というスタンスで実践してみると良いと思います。書にある通り「設計にbestはなくbetterのみがある」わけですね。
作者さん自らご登壇による資料。ここにもあるように本書は「変更容易性」をひとつの核にしているんですね。『レガシーコード改善ガイド』も大まかにはそうかもしれませんがこれは今らしい着眼点だと思いました。
ビジネスのスピードがより高まり、いったん作ったコードも後から直す機会が増え、コードも価値も成長していくことが多くなる時代。10.9%のクープマン目標値を超え、コード設計の大きな価値や技術的負債のインパクト、そして悪魔に対抗できるクラスのエンジニア育成が重要であることがより認知されますように!