見出し画像

『Tidy First?』 来たときよりも美しく

Kent Beck氏による『Tidy First?』を読んだので、所感を書き残しておく。
意訳してる部分が多分にあります。

動機
先日、おこなわれたRSGT2024(Regional Scrum Gathering Tokyo 2024)の発表資料・引用元を読んでいるうちに、「Software Design: Tidy First?」に辿りつき気になったので読むにいたった。

本書籍は約100ページで、書籍にも記載されている通り、朝読み始めて昼過ぎからさっそく活かせるようなボリューム感である。(私は英語に苦戦して数日要したが…)

本書籍は、3つのパートから構成され、"Tidying" = "片付け" の切り口で語られている。ざっくり、パート1は How / パート2は When / パート3は Why といった具合だ。
パート1は、具体的な振る舞いの変更方法を理解するようになっている。が、ある程度経験のあるエンジニアであれば、すでに実践している内容ではありそうなので、パート2から読み始めてもいいかもしれない。

また、本書籍は3つの書籍から構成されるシリーズの第一弾であり、"個人"としての領域での取り組みについて書かれている。
第二弾・第三弾では、よりチームや組織としての取り組みについて書かれるようだ。私はどちらかというと、こちらに興味がある。

まず、タイトルから気になるのは、なぜ疑問符(クエスチョンマーク)があるのか(Tidy First "?" なのか)。
「最初に片付けをするかどうか?」という問いに対して、書籍では "片付けができるからといって、やらなければいけないわけではない" と主張している。
べき論ではなく、できる/できないの話と、やる/やらないの話は区別して、状況に応じて判断していくのがいいのだろうなと思った。

ネタバレっぽくなってしまうが「最初に片付けをするかどうか?(いつやるのか?)」に対する答えは "状況による" としている。
個人的には、これを読むまでは「今でしょ()」と思っていたが、戦略的に後でやる場合もあるようだ。
いずれにせよ、そのタイミングで片付けをやることによって、どれくらいの効果(技術的な負債の解消や、ビジネス的な売上など含む)が得られるかだと思った。

後でやるにしても、"Fun List" と呼ばれる、お片付けリストを用意して、片付けは苦しいものではなく、無理のない範囲で続けられるようにする工夫もあった。

また、サブタイトルにある "A Personal Exercise in Empirical Software Design" の "Empirical" = "経験主義の" たる所以は、どのあたりなのか?
"理論や論理より、観察や経験に基づいて検証した方がよりよいだろう" とのこと。
私もこれに同感で、銀の弾丸はないのだから、それぞれのソフトウェアで小さく進めて観察し適用していくのがよいのだろうなと。

そして、"ソフトウェア設計は人間関係の訓練である" と、要所要所で言われている。
その理由については、もしかすると、同シリーズの次の書籍(チーム・組織編?)で、もう少し語られるかもしれない。

記事のタイトルに付け加えた、"来たときよりも美しく" (ボーイスカウト・ルールとも言う)は、本書籍には一言も登場しないが、それを彷彿とさせるものがあった。
(『プログラマが知るべき97のこと』にも紹介されています)

次のシリーズが楽しみだ。

この記事が気に入ったらサポートをしてみませんか?