2022年8月31日に出版された本『Clean Craftsmanship』を読みました。

その中で、個人的に印象に残ったこと、学んだことを備忘録としてまとめようと思います。

こんにちは。最近SIerからスタートアップに転職しました。プログラマー歴３年の駆け出しエンジニアです。プログラマーとして、もっと成長するために、何を学ぼうかと悩んでいたところ以下の記事に出会い、今回紹介する『Clean Craftsmanship』を読もうと思いました。

『Clean Craftsmanship』は界隈ではボブおじさんという愛称で知られている著者の「クリーン」シリーズの5作目です。

過去作には『Clean Code』『Clean Coder』『Clean Architecture』『Clean Agile』があります。

『Clean Architecture』は少し前に、巷で話題になっていたこともあり既に読んでいる方も多いと思いますが、

僕にとっては、今作が「クリーン」シリーズで最初に読む1作目になります。

『Clean Craftsmanship』では、序文からインパクトのある言葉が出てきました。

流石に言い過ぎな気もしますが、ソフトウェアの重要度が高まっていることに関しては誰も異論はないでしょう。

最近注目を浴びた記事 の中で紹介されたスライドでも、「ITはビジネスのコアになった」と記述されていました。

ビジネスとITの関係図解 | サーバントワークス株式会社より引用

そして、そのITを取り巻く環境自体も大きく変わってきており、それは、「誰も答えが分からないものを模索しながら作り続ける」世界に突入してきているとのことです。

そのような時代の流れに、対応するための方法が「アジャイル開発」や「デザイン思考」だといいます。

『Clean Craftsmanship』ではアジャイル開発手法の一つであるXPの5つの要素を規律として紹介しています。XPのプラクティスを表した「サークルオブライフ」の中央にある４つと左端にある１つが該当します。

５つの規律とは、「テスト駆動開発」「リファクタリング」「シンプルな設計」「ペアリング」「受け入れテスト」です。

これら規律を自分なりに、理解するためにイメージ図を作ったので載せておきます。間違いがあればご指摘ください。

良いアーキテクチャを作るための依存関係

５つの規律の位置関係

本当は、TDDやリファクタリングなど各規律について詳細にまとめたかったのですが、僕の理解がまだ追いついていないこともあり、この記事では『Clean Craftsmanship』を読んで、個人的に印象に残ったことをまとめようと思います。

個人的には衝撃でした。これまで、それなりにバグや問題に遭遇し、その度になんとか解決してきました。（解決できなかったものもありますが）

多くの課題をこなしていくことで、課題解決力の向上を実感し、自分は成長を感じていました。デバッグ力は課題解決力に影響する。ゆえに、デバッグ力はプログラマーとしての能力の指標になる。そう思っていました。

しかし、この本で「デバッガーが得意になることを目指すべきではない」と真っ向から否定されてしまいました。

たしかに…納得感ありまくりの理由でした。

本書で挙げられていたTDDのメリットのいくつかが印象に残ったので紹介します。

新しいプログラム言語やフレームワークを学ぶ時、最初に読むドキュメントはなんでしょうか？ざっくりとその言語やフレームワークの概要を掴んだ後、早い段階でサンプルコードを探しにいくと思います。使い方を簡単に教えてくれるサンプルコードはとてもありがたい存在です。

そして、「テストコードは最も低レベルなドキュメント」です。「テストコードはシステム全体のサンプルコード」です。

なるほど。これは非常に理解しやすいTDDのメリットだと思いました。

後からテストコードを書く時の問題点が以下に記述されています。

次に、先にテストを書く時のメリットが以下に記述されています。

テストコードを書く順番が、後だろうが先だろうが、最終的にはテストしやすいコードを設計することになることがわかります。

であれば、最初から、テストコードを意識したコード設計をしていった方が都合が良いというのは納得です。

そして、テストしやすい設計とは、自然と「結合と依存が少ない設計」になるはずで、それはつまり良い設計に繋がるということだと理解しました。

コードを変更するのは怖いことです。変更する内容が複雑であればあるほど、破損のリスクが高まります。

これを読んだ時、某漫画のコラ画像のネタを思い浮かべてしまいました。

「そう…誰も…コードをクリーンにしていないのである！！！」

これも印象的でした。これまでの経験で思い当たることがあったからです。

微妙なコードだなぁと思いながらコードを書き、後でリファクタリングする時間を貰おうと

その時は考えるのですが、大抵、そのリファクタリング時間は訪れませんでした。

そもそも、思った時にリファクタリングが実行できないならば、いつになっても（時間ができたとしても？）

リファクタリングは実現できないことが多いなと思います。（結局上達するしかないのだろうなぁ）

なるほど、ここでポリモーフィズムが出てくるのかと思いました。僕は以前C++のプロダクトに携わっていたのですが、そこでのコードや設計には、よくI○○Component（頭のIはおそらくInterfaceの略？）のようなクラスがあり、それを継承する○○Componentという形がよくとられていて、疑問に思っていました。なぜ、このような構造にしているのだろうと。こうすると何が嬉しいのだろうかと。

この本を読み、その疑問が解けた気がします。こうすることで、レベルごとに隔離・分離ができて、もつれていない、シンプルな設計が実現できていたんだろうなと気がつきました。そしてそれはテストのしやすさにもつながっていたと。

僕はこれまでに、短い時間ではありますが、プログラムを書いてきて、ぼんやりと、良いコードを書くことや良い設計を考えることの重要性を感じていました。しかし、それが具体的にどういったものなのか、どのように実現できるものなのかは分かりませんでした。『Clean Craftsmanship』を読んで、テストを意識したコードや良い設計をする重要性、良いコードや良い設計を考える上で重要な知識を知ることができました。

この記事では紹介できませんでしたが、本書には付属コンテンツとして、TDDを体験できる動画が付いていたり変換の優先順位説という興味深い説の紹介があったりと、他にも面白い内容がありました。

ただ、3章や4章の内容は、僕にとっては理解が追いつかない部分も多かったです。今後、経験を積んで理解を深めていきたいと思います。

今回できなかったTDDの練習はやってみたいなと思います。今後読みたい本としては、『Clean Craftsmanship』を読んで面白かったので、他の「クリーン」系の本Clean Architecture や Clean Code も読んでみたいです。あとは、 leanとdevopsの科学 も必読書のような気がしますし、あ、Web技術やクラウド技術の勉強もしなければ…まぁ気になった本をどんどん背伸びして読んでみようと思います。 （技術書を買ってくれる弊社に感謝！）読み物としては、論文なんかも読めるようになりたいのでいつか挑戦してみたいところです。

ただ、本ばっかり読んで、実務では役ただずではいけないので、実際にコードを書いたり読んだり色々なフレームワークの使い方も調べたり試したりしていこうと思います。