既に話題の Tidy First? を読みました。とても 整った 本なので読みやすい。もしかしたら原書で読んでみても良いのかもしれない。
Tidy First? ―個人で実践する経験主義的ソフトウェア設計 | Kent Beck, 吉羽 龍太郎, 永瀬 美穂, 細澤 あゆみ |本 | 通販 | Amazon
ということでそのメモです。
メモ
読みながら書き留めたメモを記録として転記。
以下を記しているとのこと:
- 処理を変更する前に、乱雑なコードをいつ整頓すべきか
- 乱雑なコードを安全かつ効果的に整頓する方法
- 乱雑なコードの整頓のやめどき
- 整頓がうまくいく仕組み
第一章が 2 ページで終わったと思ったら第二章も以下。
消そう。以上。実行されないコードは消すだけだ。
などというコンパクトさ。これが Tidy。
「整頓大賞シンプル部門」を受賞するのはこれだ。大きなコードのチャンクを読んでいると、「ああ、ここはこれをしていて、あそこであれをしているのか」とわかる。そのあいだに空行を入れよう。この整頓は非常にシンプルなのがよい。これは Tidy First? の哲学の一部だ。
まずはコードを 1 箇所に集めて、それから改めて、簡単に理解できる部品を抽出する。
探すべき兆候は以下だと言っている。
- 長くて、繰り返しの引数リスト。
- 繰り返しのコード。特に繰り返しの条件式。
- ヘルパー ルーチンのよくない名前付け。
- 共有の可変データ構造。
しかし整頓のあとでは、コメントはコードに書いてあることをただ言い直しているだけになってしまった。だから、消そう。アスタ・ラ・ビスタ、アディオス、あばよ。
整頓を適用できるようになっただけでは、整頓をマスターしたことにはならない。本書のタイトルは、疑問符を強調した「Tidy First?」である。整頓ができるからといって整頓すべきとは限らないことを伝えたかったのだ。
疑問符の理由が空かされている。ネタバレかもしれない。考えどころは以下だという。
- いつ整頓を始めるか？
- いつ整頓をやめるか？
- どのように整頓、コードの構造の変更と、振る舞いの変更を組み合わせるのか？
また堂々巡りのひどい例は以下だという。
- 整頓を振る舞いの変更と一緒に入れる。
- レビュアーはプルリクが長すぎると文句を言う。
- 整頓を独立したプルリクに分けて、振る舞いを変更する前にプルリクを出す、もしくは振る舞い変更のあとに回す。
- レビュアーは整頓のプルリクが無意味だと文句を言う。
- 1 に戻る
- いつ設計判断を始めるか？
- いつ設計判断をやめて、システムの振る舞い変更に取りかかるか？
- 次の判断はどのように行うか？
これらの質問に合理的かつ論理的に答えることはできない。なぜなら、合理的で論理的な回答を見つけるために必要な情報が、質問をした時点で存在しないからだ。
開発を経験した者に「あるある」な状況が説明される。
- ソフトウェア設計とは何か？
- ソフトウェア設計がソフトウェア開発と運用のコストにどのように影響するか、またソフトウェア開発と運用のコストがどのようにソフトウェア設計に影響するか？
- ソフトウェアの構造への投資と、投資しないことのトレードオフは何か？
- ソフトウェアの構造を変更するか、また変更の方法を決定するために、どのような経済性の原則、人間性の原則が使えるか？
私たちは「ソフトウェア設計は人間関係のエクササイズだ」と言うことから、この旅をはじめた。
私がシステムの構造について語るとき、それは次のようなことを指している。
- 要素の階層
- 要素間の関係性
- その関係性から生まれる利益
これで、システムの構造と振る舞いをより明確に区別できるようになるという。
続編: Tidy Together
著者 ケント・ベック による続編アウトライン。次作も興味深い
Tidy Together? Outline - by Kent Beck
Each book has 3 parts:
Technique. Things you can actually do as you design. I put these first so people who want to start learning by doing can begin after reading a few pages. That’s not the same as mastering the material, but it can be a path there.
Management. We always have topics other than software design competing for our time & attention. Telling people what to do to design isn’t useful unless they prioritize design appropriately.
Theory. There are deep roots for why Empirical Software Design is effective. Understanding why on top of what & when gives practitioners the maximum number of options for creating value.
<ざっくり翻訳> それぞれの本は3部構成になっている：
テクニック。デザインしながら実際にできること。数ページ読んだだけで、実際にやってみたくなるような内容になっている。それは、材料をマスターすることとは違うが、そこに至る道筋にはなり得る。
マネジメント。私たちは常に、ソフトウェア設計以外の話題で時間と注意を奪い合っています。設計に何をすべきかを指示しても、設計に適切な優先順位をつけない限り、役には立たない。
理論。経験的ソフトウェア設計が効果的である理由には深い根があります。いつ、何をするのかに加え、なぜそうするのかを理解することで、実践者は価値を生み出すための最大限の選択肢を得ることができます。
参考
既にある読書感想文をいくつか。
Tidy First? を読んで学んだこと
その汚いコード、いつどこで整頓するの？"Tidy First?"を読んで解決した話 #初心者 - Qiita
『Tidy First？』を読んだ｜Kanon
Tidy First? #SoftwareDesign - Qiita
『Tidy First?』を読んで、コードの整頓について考える - Magnolia Tech
こんまりさんの「片付け」もそういえば Tidying というのだな、と考えていて思った。片付けはときめく。
Tidying Up with Marie Kondo | Official Trailer [HD] | Netflix
さくっと読めるので感想を言い合うのが楽しい本だと思う。
以上です～