00:00
こんにちは、ザ・ディープライブです。
こんにちは。
整理の連鎖性
今回はですね、ソフトウェア開発でよく話題になるコード整理、これに関するTidy First?っていう本の読書会がありまして、
その時の議論のメモとか文字起こしをもとに、深く掘り下げていこうと思います。
面白そうですね。
特に、本の第17章連鎖、18章バッチサイズ、19章リズム、
この辺りについて、参加者の方がどんなことを話してたのか、そのエッセンスをあなたと共有したいなと。
なるほど。
誰が言ったかというよりは、そこでどんなアイディアが出たか、そこにフォーカスしていきますね。
いいですね。コード整理って、何で大事なのかとか、一度にどれくらいやるのがいいのかとか、
そうそう。
タイミングとか、結構悩みますからね。実践的なヒントがあると嬉しいです。
ですよね。では早速、中身を見ていきましょうか。
まず第17章の連鎖。ここで出てきた、整理はポテトチップスみたいなものだって例え、これ直感的で面白いなと思ったんですけど。
ありましたね。一つやると次々やりたくなっちゃうみたいな。
そうそう。
これはファンアウト現象とも言われてましたね。
ファンアウト?
つまり一つの整理をすると、それがきっかけで次の整理のポイントが鬼みたいに広がって見えてくるっていう。
なるほど。
例えば使われていないコード、レッドコードを消すと、他のコードを読む順番とか、グルーピングの改善点とかがここもここもって見えてくる。
確かにありそうですね。
議論の中では結局整理の目的ってコードの構造とかその意図を明確に伝えることだよねっていう点が再確認されてた感じですね。
なるほど。意図を明確にすると。
はい。
字サイズですよね。
そうですね。そこ重要ですよね。
大きな単位、つまりバッジで、えいやってやっちゃうと他の人の作業とぶつかったりとか。
コンフリクトですね。
あとは何か意図しない動きをしちゃったりとか、そういうリスクが高まるよと。
ええ、コストが増えますよね。
でもかといってじゃあものすごく細かくちまちまやればいいかっていうと。
そう、それもまた問題で、細かくしすぎると今度はレビューとかデプロイのいわゆる固定費みたいなものが毎回かかる。
ああ、なるほど。
だから全体のコストで見るとかえって高くなっちゃう可能性もあると。まさにトレードオフ。
うーん、難しいですね。
ここで議論の中ですごく本質的な指摘があったと思うんですけど、このバッジサイズの問題って単に技術的にどっちがいいかって話だけじゃなくて、実はチームの信頼コストの問題でもあるんじゃないかって。
信頼コスト?
ええ、つまりレビューにかかるコスト。お互いに行動を理解したり確認したりする手間とか時間ですね。
これをもしチーム内でうまく削減できれば、理想とされているその小さなバッジでの整理がより現実的に効果的にできるんじゃないかと。
へー、それは面白い視点ですね。技術論じゃなくてチームの関係性の話になるわけだ。
そうなんですよ。だから整理っていうのはあくまでそのこれからやろうとしている変更をやりやすくするための準備なんだっていう、そういう位置づけが強調されてましたね。
なるほどなー。いやそれはちょっと目から鱗でした。
リズムを持った整理
そして第19章がリズム。今度は時間軸の話ですね。
そうですね。
整理は個人のソフトウェア設計の範囲、つまりまあ数本から長くても1時間ぐらいの、そういう短い時間でやるべきだという提案でした。
ええ。あんまり長時間かけて大規模な整理をやろうとすると、本来の目的、つまり将来の変更を楽にすることからなんか意識がずれちゃうことがあると。
あーわかります。整理のための整理みたいになっちゃう。
そうそう。それよりももっと頻繁に小さな整理をコツコツと、まさにリズムを刻むような感じでやる方が、結果として開発全体の流れがスムーズになるんじゃないかと。
リズムを刻むですか。
ええ。このリズムの話で興味深かったのは、これ単なる時間管理のテクニックってだけじゃなくて、高度の変更って大体特定の箇所に集中しやすいっていう観察。
あーパレートの法則みたいな。
そうですそうです。80対20の法則みたいな。それと結びついてるんですね。だから必要なところに自然と整理も集中していくはずだっていう。
なるほど。だから無理に全体をきれいにしようとしなくても、リズムよくやっていれば自然と大事なところが整理されていくと。
そういう考え方ですね。
議論全体を振り返ってみると、やっぱり構造を整えるっていう作業と、機能の振る舞いを変えるっていう作業はちゃんと分けた方がいいよねっていう点と。
そこは基本ですね。
それから整理の主な目的は将来の変更コストを下げることにあるんだっていう点。この辺りは参加者の方々で結構共通認識があったように感じましたね。
そうですね。バッチっていう言葉の定義が人によって微妙に違ったりとか、原文と翻訳のニュアンスの話なんかも少しは出てましたけど、でも本質的なところの理解はかなり共有されていた感じがします。やっぱりさっき話に出たレビューコストをどうやって下げるか。
それが効果的な整理、つまり小さなバッチサイズでの継続的な改善を可能にする鍵なんだっていうところが議論の一番のハイライトだったかなと思いますね。
今回の資料を深く見てきてわかったこととしては、まずコード整理は次の整理を誘う連鎖的な側面がある。
ポテトチップスですね。
それから一度にやる量、バッチサイズはコストとの見極めが大事。
トレードオフがあると。
そしてリズムよく短い時間で進めるのが効果的だと。
そういうことですね。
特にそのリズムっていう考え方と変更が特定箇所に集中するっていうパレートの法則が結びついていたのは、日々の作業を見直す上で結構面白い視点だなと感じました。
そうですね。あなた自身の仕事とか、あるいは学習とかでこの小さな単位で改善を積み重ねるとか、作業のリズムを作るとか。
あとボトルネックになっているコスト、ここではレビューコストでしたけど、それを特定して解消していくという考え方、これどういうふうに活かせそうですかね。
本当にいろいろ応用できそうですよね。
大胆なアプローチ
最後にですね、資料の後半でちょっとだけ触れられてた少し挑発的な問いかけを。
何でしょう。
時には今やっている実装をええやって一度捨てちゃう。
捨てちゃう?
で、ゼロから作り直した方が、かえって良い構造になったり、深い学びにつながったりする場合があるんじゃないかっていうアイディアです。
へー、それは大胆ですね。強くてニューゲームみたいな。
そうそう、そんな表現もされてましたね。このある種破壊的なアプローチ、これどんな時に有効だと思いますか。
難しい問いですね。でも考えてみる価値はありそうです。
ぜひちょっと考えてみてください。
それでは今回の探究はここまでとしましょう。
はい、ありがとうございました。
次回もご期待ください。
