最近、いろいろな本を雑多に読んではいたけど、感想とかアウトプットできていなかったので、まとめてブログにしてみる。今回は複雑性に関わる本を2冊読んでの感想をまとめた。

A Philosophy of Software Design

過去に読んだときは複雑性の話やdeep moduleの話に目が行っていたけど、今回はあらためてtactical programmingとstrategic programmingの話を読み直してみた。

tactical programming（戦術的プログラミング）というのは、目先のタスクを最短で終わらせるプログラミングスタイルで、とにかく動けばいいというマインドセットを指している。名前の響きよりもネガティブな言葉だ。締め切りなどに追われて既存の挙動を壊さずに最小限の変更でタスクを終わらせるような仕事は、自分も若いうちはよくやりがちだった気がするし、今でも気を抜いたときにやっているのかもしれない。

この本では、システムの複雑性というものは何か特定のものによってもたらされるのではなく、小さな変更の積み重ねによってもたらされている、と書いてある。10年以上この仕事をしていて本当にその通りだなと感じる。リファクタリングしたいけど時間がとれないから、if文を追加しTODOコメントやFIXMEコメントでお茶を濁すようなことは自分もやっていたので胸が痛い。

一方で、strategic programming（戦略的プログラミング）というのは、コードが動くだけでは不十分で、中長期的な目線に立ってコードの構造を設計することと書いてある。具体的な内容は本書にずっと書かれている内容ではあるので、ここでは特に触れない。

この話を読んでから、日々の開発に対する姿勢が少し変わった。コードを書くときやコードレビューをするときに、ただ仕様を満たす動くだけのコードになっていないか、不必要な複雑性をもたらしていないかよく考えるようになった。特にコードレビューにおいては、どんなに細かいことであっても躊躇せずに指摘するようになった。システムの複雑性はチリツモなので、細かいからと言って見過ごさないようになった。

Tidy First?

とはいえ、目の前のコードはとても複雑で、strategic programmingをやっていきたいけど現実は厳しいなと感じていたときに手に取ったのがTidy First?だった。

Tidyというのは日本語でいうと、お片付け？整理整頓？といったところになるだろうか。本書では、1時間以内で終わるような小さなリファクタリングをTidyと呼んでいる。具体的には、以下のようなテクニックがたくさん紹介されている。

• Early Returnでif文のネストを消す
• 使われていないコードを消す
• 長いメソッドを意味のある単位で空行を入れて区切る
• 読みやすいように処理順を変更する（もちろん振る舞いを壊さない範囲で）

こういったHowはこれまでも学んできたところではあるし、そこまで目新しいものはなかった。重要なのは、これらのTidyをいつどうやるか？で、こういったトピックについての話を過去に見たことがなかった気がする。

Tidyをおこなうタイミングとしては、本来やりたい変更の前にやるか、後にやるか、後回しにするか、いっさいやらないか、の4パターンある。また、Tidyを本来やりたい変更とは別のPull Requestに分割するのか、複数のTidyがあった場合にそれらをまとめてPull Requestにしたほうがいいのか、といった話もある。具体的にどのような条件でどの戦略を採るかについては本書を読んでほしいが、自分のために内容をフローチャートに整理していつでも参照できるようにしている。

もちろんこのようなTidyだけでは、不必要な複雑性を解消するには十分とは言えないし、時間をとってリファクタリングを実施しないといけないこともあると思うのだけど、積もりに積もった複雑性を少しでもお掃除したいという気持ちには十分に応えられる内容だと思った。