コード整理のタイミング
こんにちは、ザ・ディープダイブへようこそ。
今回はですね、ソフトウェア開発の注目作、Tidy First?
この本について、話し合われたある読書会の議論のメモと文字起こしがありまして、
これを元に、あなたと一緒に深く掘り下げていきたいと思います。
はい。
ミッションとしては、コードを整理するタイリングですね。
これをいつやるのがいいのかっていうのと、
あと、そもそもソフトウェア設計って何なんだろうっていう、この2つの大きな問い。
これに対する議論から、実践的で、時にはちょっと哲学的なエッセンスを引き出せたらなと。
ええ、そうですね。日々のコーディングに直結する、いつ整理するかっていうプラクティカルな問いと、
それから、もう少し引いた視点でのなぜ整理するのか、その設計の本質みたいなところですね。
今回のソースになった議論メモを読むと、その両面から非常に興味深い視点が出てきそうですよね。
ですね。
早速見ていきましょうか。
はい。まず議論の中心になっていたのが、第21章の先に整理、後に整理、改めて整理、整理しない。
コードを変更する前にやるのか、後なのか、あるいは一旦置いておくのか。
やっぱりこれ答えは状況によるってことみたいですね、議論を読むと。
まあ、そう結論つけられますよね。
で、その中にでもソースの議論で結構注目されてたのが、改めて整理する、レイターってやつですね。
これ、お楽しみリストに入れるっていう考え方。
お楽しみリスト。
ええ。ネーミングが面白いですよね。
すぐにはやらないで、リスト化しといて後でやると。
結構成功してる企業でも、いや時間ないんだよって思いがちだみたいな指摘もあって。
ああ、なるほど。
だからこのリストって、忙しい中でも、まあなんとか後で整理しようっていう、ある種の心理的な工夫なのかなと。
ソースの議論の中では、個々の複積みコメントなんかが、実質このお楽しみリストみたいになってるよね、みたいな話も出てましたね。
ああ、なるほど。タスク管理というか、そういう側面もあるんですね。
で、対照的に後に整理する、アフターは変更の直後。
で、先に整理、ファーストは変更の前。
ただ、特にこの先に整理っていうのは、経験豊富な開発者が好む傾向があるとは言っても、議論メモを読むと、
いや、それで本当に変更が楽になるか、結構予測難しいよねとか、場合によっちゃコンフリクトの原因になったりもするし、みたいな声もありましたよね。
ありましたね。これ結構実践だと悩ましいポイントじゃないですか。
いや、まさにその予測の難しさっていうのが一つ確信ですよね。
変更にかかるコストと整理にかかるコスト、どっちをいつ支払うか、みたいな。
トレードオフ。
ええ、そういうトレードオフ。ソースの議論でも、その行動に対する理解度とか、将来の変更の見通し、チームの状況とか、
いろんな要因が絡むからすごく複雑な判断なんだっていう点がかなり強調されてましたね。
単純なルールじゃなかなか決めきれないと。
いやー、深いですね。じゃあ、次にその判断の根拠にも関わってくる話だと思うんですけど、
整理する理由と著者の視点
第3部の理論の話。なぜ整理するのかという、こっちの問いですね。
ソースの議論だと、理論を知ることは、役の作用基準を知るのに似てて、実践を良くする助けになるみたいな話がありました。
ええ、ありましたね。ここで出てくるソフトウェア設計の定義がまた資産に富んでるんですよね。
要素を役立つように関係づけること。
シンプルですね。
ものすごくシンプル。でもこの要素関係づける、役立つようにっていうそれぞれに結構重みがあるなと。
特にその役立つように、ユースフリーの部分。議論メモではここが結構掘り下げられてましたね。
例えば、ある関数が別の関数の複雑さを引き受ける。これはまあ相互利益だと。
でもそれによって関数が一つ増えるっていう代償、コストとかトレードオフもあるよねと。
じゃあ、この役立つっていうのは一体誰にとって役立つことなんだろうっていう問いかけが。
そうなんです。そこが面白いところで、ソースでの解釈としてはこれはプログラマー同士にとって役立つだろうと。
ああ、なるほど。人間同士の。
ええ、ソフトウェア設計っていうのは結局コードを書く人間同士のコミュニケーションであり、協力の営みなんだっていう視点ですね。
さらに、第3部では経済性、つまりお金っていう言葉が結構頻繁に出てくるっていう指摘もこれまた興味深かったです。
経済性ですか?
ええ、整理とか設計っていうのを単なる技術的な良し悪しじゃなくて、コストと投資、あるいは将来価値っていう経済的な観点から捉えようとしてるんじゃないかと。
リアルオプション理論、将来の不確実性の中で選択肢を持つこと、柔軟性を持つことの価値を評価する金融の考え方ですけど、それに言及があったのも多分そういう文脈なんですよね。
なるほどなぁ。今回の議論を紐解いてくると見えてくるのは、やっぱり日々のコーディングでのいつ整理するかっていうすごく現実的な判断の短しさと、その背後にあるじゃあなぜそうするのかっていうソフトウェア設計のより深い問い、この2つですね。
コードを整理するって単にキレイ好きの問題じゃなくて、将来の変更コストをどう抑えるかとか、チームでどう理解しやすくするかっていう一種の投資判断でもあるんだなぁと。
そうですね。
これはあなたの日々の選択にも結構かかわってくる話なんじゃないかなと思いますね。
最後にですね、ソースの議論の中でも特に印象的だった著者、ケントベックの言葉に触れておきたいなと。
はい。
いつかソフトウェア設計を自然界のプロセスとして扱うような、本当に哲学的な本を書くかもしれないって言ってるんですね。
へぇー。自然界のプロセスですか。
そうなんです。もしソフトウェア設計っていうのが単なる工学的な規律っていう側面だけじゃなくて、まるで生態系みたいな自己組織化したり進化していくプロセスとして捉えられたとしたら、
ほう。
ソースの議論にもあった、コード自身が自分がどう構造化されたいか知ってる感じがするっていう感覚にもつながるかもしれませんけど、この視点ってあなたのコードとの向き合い方に何か変化をもたらすかもしれないですよね。
確かに。ちょっと考えてみたくなりますね。
ええ。今回はここまでとしましょうか。
