Clean Craftsmanshipを読む
🏓

Clean Craftsmanshipを読む

タグ
Clean Craftsmanship
公開日
October 11, 2022

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はビジネスのコアになった」と記述されていました。

image

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

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

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

image

XPと5つの規律

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

image

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

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

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

image

５つの規律の位置関係

image

印象に残ったこと

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

目次

  1. デバッガーの消失
  2. TDDのメリット
  3. リファクタリングはスケジュールや計画に 決して 表れない
  4. 良い設計はもつれていない

1. デバッガーの消失

あなたはデバッガーの操作は得意だろうか？ ショートカットを覚えているだろうか？ ブレイクポイントやウォッチポイントを設定し、デバッグセッションに深く潜り込めているだろうか？
これらは望ましいスキルではない！第2章 p46

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

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

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

デバッグに時間をかけてはならない。あなたもそう思ってほしい。動作するコードを書くことに時間をかけるべきだ。動作しないコードの修正に時間をかけるべきではない。

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

2. TDDのメリット

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

その1。ほぼ完璧な超低レベルのドキュメントを作れる

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

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

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

その2。結合の少ない設計ができる

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

コードを書いたあとにテストを書くのは一般的だ。あとからテストを書こうとすると、必然的に書きにくいテストも出てくる。テストしやすい設計になっていないからだ。動けばいいコードになっているからだ。テストを書くには、設計から変える必要がある。だが、それは難しい。p48

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

テストを先に書くと、テストしにくいコードが書けなくなるのだ。テストを先に書くという行為によって、テストしやすいコードを設計することになる。テストしにくいコードの要因は何だろうか？ 結合と依存だ。テストしやすいコードには結合と依存がない。テストしやすいコードは分離されている！p49

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

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

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

その3。変更する勇気を与えてくれる

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

恐怖はコードに腐敗をもたらす。誰もクリーンにしない。誰も改善しない。変更を余儀なくされたら、システムにとって最善の方法ではなく、プログラマーにとって最も安全な方法によって変更される。設計は劣化する。コードは腐敗する。チームの生産性はゼロになるまで低下する。p50

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

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

3. リファクタリングはスケジュールや計画に 決して表れない

ここでは、リファクタリングの誤解を解消しておきたい。リファクタリングはスケジュールや計画に決して表れない。トイレに行ったら手を洗う。リファクタリングはそれと同じだ。p52–53

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

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

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

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

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

4. 良い設計はもつれていない

システムの最高の設計とは、機能要件を全て満たし、変更に対して柔軟性があるシンプルな設計である。シンプルとは「もつれていない、絡み合っていない」という意味である。最も高価で重大な「もつれ」とは、高レベルの方針が低レベルの詳細と結合しているものである。p210
シンプルな設計とは、高レベルの方針が低レベルの詳細を知らない設計である。低レベルの詳細の変更が高レベルの方針に影響を与えないように、高レベルの方針を低レベルの詳細から隔離・分離しておく。こうした隔離・分離を実現する手段が抽象化である。抽象化の具体的な方法がポリモーフィズムだ。p210

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

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

まとめ

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

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

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

次にすること

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

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