最近アーキテクトなるお仕事になったようなので、コードやアーキテクチャ関連の本を読み漁っています。何冊か読んでいるんですが、まずは最近Kent Beckが出版した『Tidy First?』の話を書きたいと思います。
パート1: Tydings
「Tidy」というと、USでは一時期からコンマリが大流行りしているようで、「Kondo」がそもそも動詞化していたりするなど一大ブームとなっている（た）ようです。コンマリといえばそう、「お片付け」なんですが、なんとなくここから着想を得ているのかなと思います。Netflixでも「Tidying Up with Marie Kondo」という番組が作られていたくらいです。
Tidyingは「片付け」ないしは「整理整頓」あたりで訳せそうではあるんですが、日本語訳版（出るのかな？）で定訳がまだ出ていなさそうなので、一旦英語表記のまま話を進めます。
Tidyingは、リファクタリングの部分集合のようなもので、リファクタリング行為がときどきもたらす、長い期間機能開発を止めてしまうようなネガティブな側面を軽減する役割を持つ行為かと思われます。パート1の最初のページに、次のような文言が並んでいます。2文目の方では現代ではリファクタリングという言葉の指す意味合いさえ変わってしまったといい、「動作を変えないという文言さえ削除され…」と嘆いています。
Tidyings are a subset of refactorings. Tidyings are the cure, fuzzy little refactorings that nobody could possibly hate on.
"Refactoring" took fatal damage when folks started using it to refer to long pauses in feature development. They even eliminated the "that don't change behavior" clause, so "refactoring" could easily break the system.
Tidyingに該当する行為としてパート1では、ちょっとした変数名の調整や、対称性のない実装は対称性を保つこと、コメントの微調整や使っていないコードの削除などが挙げられていきます。このあたりは、Tidyingの具体例を示しているでしょう。
一見するとリファクタリングと同じように見えてしまうのですが、リファクタリングは確かにもう少し大規模で、それよりかは小規模な作業の「リファクタリング」なのが「Tidying」です。が、リファクタリングとは微妙に異なる概念ではあり、異なる概念に丁寧に名前を当て、その概念が具体的に何をする行為なのかを示すのがパート1の役割なのかなと思っています。ボーイスカウトの原則とも相性が良さそうです。
パート2: Managing
パート1で「Tidyings」でしたが、パート2では具体的にどう実行するかに焦点が当てられます。このパートでは、次の問いに答えられる形で話が進んでいきます。
- いつTidyingを開始し、いつTidyingを終えるか？
- Tidyingとシステムの振る舞いを変えるようなコードの構成の変更をどう組み合わせていくか？
まず後者からですが、Tidyingのコミットと機能変更を含むコミットとはそれぞれ分けてプルリクエストを作るようにしましょう、とのことでした。機能開発とTidyingsがまぜこぜになりそうな場合には、いい感じの単位で分けるようにするのを推奨しています。これは実際の開発現場でもそうで、リファクタリングと機能開発のプルリクエストは分けましょう、みたいな話をされることは多いでしょう。それと同じと思いました。
どのくらいの単位で取り組むべきかについては、どうやら時間を区切りとすることを考えているようです。最大でも1時間以内に終われないTidyingsはバッチサイズが大きいと言えるため、これは実質機能開発に相当してしまうかもしれません。本来の目的を見失っている可能性が高いと指摘します。
いつTidyingを開始するかですが、これは機能開発前である、という主張になっています。後回しにすればツケが回ってきますし、直後にやろうとすると今度はいつやれるときが来るかとか、Tidyingまで完遂しないとタスクを完了した感がなくなるなどの理由で、機能開発直前に行うことを推奨しています。これはなかなかなかった視点で、まず目の前のコードの状況を整理してから本題のタスクに取り組むというのは、料理をする前にまず必要な調理器具が取り出せる位置にあるか、なければ片付けて整理してから開始すると、料理中に焦らなくても済むみたいな話に近そうかな？（ちなみにですが、ちょっと違うか…）と思いました。
パート3: Theory
最後は理論編ですが、最初は経済的な分析、次にソフトウェアアーキテクチャの理論上の分析という構成になっています。
経済的な分析の方は、詳しい説明は端折りますが、たとえば将来価値より現在価値のほうが大きいので、Tidyingに当てはめた場合でも、最初にやったほうが費用対効果がいいよという話につながっていたりとか、オプションのプレミアムの話からやはり、今日の変更は明日に回したそれと比べるとその分だけプレミアムが乗っているんだ、というような話を展開しています。確かにファイナンスでは、現在何かをする価値と将来何かをする価値とを比較する作業をよく行います。Tidyingsもそういう側面で見るなら、今やり切るのが最も価値が大きく、後回しすると価値が減少するモノと言えるかもしれません。
もう一つのアーキテクチャリングの理論的な話としては、Tidyingsは疎結合かつ高凝集を目指しながら行いましょう、というものです。これは目新しいものではなく、トレードオフを意識しながらやりましょうね、という話が書いてあったかなと思った程度でした。
感想
Tidyingないしは「片付け」という単語自体はぜひチームにはやらせていきたいと思いました。リファクタリングというほど大掛かりではないものの、やっておくと後々その投資効果が出てくる類のものだと思います。また、この手の話の説得というか理論武装としてファイナンスの考え方を持ち込むのはよい使い方だと思いました。こうした説明をすると、投資が好きな人なら納得してくれそうなので、積極的に使っていきたいところです。オプションの話はちょっとファイナンスのバックグラウンドがないと理解が難しそうですが…