コード整理と経済的視点
こんにちは。今回も皆さんと一緒に資料をじっくり見ていきましょうか。
えーと、今回はですね、ソフトウェア設計のTidy First?という本、これの読書会のメモと文字起こしが元になっています。
第27、28、29章ですね。
はい。
テーマとしては、コード整理の経済的な話、あとは変更の可逆性、それから結合というコストに関わる概念、この辺りを掘り下げていきたいと思います。
えー、面白そうなテーマですね。
では早速ですが、第27章のオプションvsキャッシュフロー。
あー、これですね。
これは、先に整理して将来に備えるか、オプション価値というか。
うんうん。
それとも、今は機能開発を優先して整理は後でやるか、キャッシュフロー重視ですね。この対立です。
はい。
資料の議論だと、経済合理性だけで考えると、先に整理ってなかなか正当化しにくくかもしれないと。
あー、そうなりがちですよね。
ただ、数分とか数時間レベルのセルフケア的な整理、これは結構価値があるんじゃないかという話が出てましたね。
えー、そこすごく興味深いですよね。その判断の領域という部分。
はい。
特に小さい整理だと、厳密な計算というよりは、経験とか、今やっといた方が絶対いいなみたいな直感。
あー、わかります。
そういうのが大きいんじゃないかと。資料でも、整理をお金を使う、機能追加をお金を稼ぐ、みたいに対比してましたけど。
えー、してましたね。
この見方は、日々のコーディングでの判断を考える上で、あー、なるほどなと思いましたよ。
将来の選択肢を残す、みたいな話にもつながりますけど、次の第28章。不可逆的な構造変更。
はいはい。
これは、変更が元に戻せるかどうか。可逆性ですね。
えー。
特に元に戻せない変更。例えば、資料にあった誤った税金の通知を送っちゃうとか。
前に関わる不可逆な変更は、特に慎重にレビューとかダブルチェックが必要よねっていう。
まさに。で、これもう少し大きな視点で見ると、設計そのものにも関わってくるんですよね。
と言いますと?
例えば、サービスの切り出しみたいな、まあ大きな構造変更。一見、もう後戻りできないように感じますけど。
ええ。資料の議論では、フィーチャーフラグ、機能をオンオフできるスイッチみたいなものを使えば、これも試す段階では可逆的にできると。
なるほど。実験ができるわけですね。
そうなんです。大きなコミットなしに試せる価値は大きいですよね。逆に、インタジャー型をロング型に変えるみたいな変更。
はい。
これ自体は単純でも、影響範囲がものすごく広いと、事実上もう元に戻すのは無理みたいになっちゃう。
ああ、確かに。
だから、変更はちゃんと管理できる範囲で、いざとなったら止められるような小さいステップで進めるのは大事だよねっていう話も出てましたね。
ここがまた、うーん、非常に考えさせられるポイントですが、第29章の結合です。
変更の可逆性と結合コスト
結合きましたね。
ある部分を変えたら、別の部分も変えなきゃいけない。これがソフトウェア開発のコストを上げる大きな要因だと。
ええ、もうその通りですね。
特に問題になるのが、1つ変えたらN箇所に影響が出る1対Nとか、変更がドミノ倒しみたいになるカスケード。
はいはい、その波及効果ですね。
こういうのが議論されていました。
これは重要な問いを提起していると思うんですよね。
と言いますと?
どこにコードがつながっているかっていう表面的な話だけじゃなくて、どういう種類の変更に対してつながっているのか、結合しているのか、そこが肝心だと。
ああ、なるほど。
例えば、コードのフォーマットを変えるだけなら、影響は少ないかもしれないけど、でも関数名を変えたら、それを読んでいる箇所は全部直さないといけないとか。
確かに変更の種類によって全然違いますね。
ええ、さらにその結合っていうのは目に見えないところにそんでいることもあるっていう話もありました。
目に見えない結合。
Facebookの例が出てましたけど、物理的に同じラックにある全然別のサービスが、片方の設定変更が原因で障害を起こしたとか。
へえ、それはソースコードを見ているだけじゃわからないですね。
そうなんですよ。だからソースだけじゃ分析できない結合もあるんだと。
なるほど、それがいわゆる複雑なシステムっていう話につながってくるんですかね。
まさにそこですね。資料の議論でも複雑なシステムっていうのは、変更が予期せぬ副作用を生むシステムだと。
はい。
で、その原因の多くはそういう隠れた結合にあるんだという話でした。
ふむふむ。
だから結合を意識して減らしていくっていうのは単にコストを下げるだけじゃなくて、予期せぬ問題を避けるためにもすごく大事なんですね。
いやー、深いですね。さて、ここまでいろいろと見てきましたが、これら全体から何が見えてくるか。
ええ。
短期的なキャッシュフローと将来の選択肢、つまりオプション価値のバランス感覚。
はい。
それから変更を元に戻せる価逆性っていう考え方の戦略的な重要性、それをどう設計に生かすか。
ええ。
そしてソフトウェアのコストや複雑さを大きく左右する結合、目に見えるものも隠れたものも含めて。
この辺が今回の資料から浮かり上がってきた確信部分かなっていう気がしますね。
そうですね。非常に重要なポイントが多かったと思います。
それで、最後にリスナーの皆さんにもちょっと考えてみてほしいなと思うことがあるんです。
おっ、何でしょう。
資料の議論の中でふっと触れられていたんですが、結合みたいなソフトウェアの基本的な用語ですら、時代とともにその意味外が薄れたり、ちょっと違う意味で使われたりすることがあるんじゃないかと。
ああ、なるほど。言葉のインフレというか、希薄化というか。
ええ、そんな感じです。これを踏まえて、普段皆さんがソフトウェアの基本原則について話したり適用したりする中で、もしかしたら知らず知らずのうちに本来のニュアンス、本来の意図みたいなものを見失っている部分ってないでしょうか。
そして、その原則が持つ本来の力をちゃんと生かすためには、日々の仕事の中でどんなことに注意を払う必要があるんでしょうか。
うーん、それは考えさせられますね。自分の使っている言葉の意味を再確認する良いきっかけになりそうです。
ええ、ぜひ一度立ち止まって考えてみていただけると。
