Tidy Firstの概要と参加者の反応
さて、今回も始めていきましょうか。ソースはですね、ソフトウェア開発者、ケント・ベックの著書、Tidy First。
この序盤について話し合われた読書会の記録ですね。ここでのミッションとしては、この初期の議論から特にコードをいつ整頓するべきかという問いに対して、参加者の方がどういうふうに考えているのか、その最初の反応を探っていきたいと思います。
ケント・ベックですね、エクストリームプログラミング、XPとかアジャイル開発では非常に影響力のある方ですよね。まさに彼の新しい本、Tidy Firstは、その確信というか、コードの整頓をいつやるべきかっていう、すごく実践的な問いに踏み込んでるんですね。
なので、序盤の議論だけでも、いくつか重要なテーマが見えてきている感じです。
まずちょっと面白かったのが、参加者の方が、この本、比較的薄いっていうことにホッとしていたっていう点ですね。
まあありますよね。前の本が大変だったのかもしれないですね。
すぐに、理論上は理論と実践に違いがない、しかし実際には違いがあるっていう言葉が結構注目されてましたね。これ、ソフトウェア開発の現場にいると結構刺さる言葉かなと。
そうですね。その理論と実践のギャップっていうのは、多くの開発者が日々直面しているジレンマかもしれないですね。
ケント・ベックが一貫して重視してきたバランス感覚みたいなものがここにも出ているのかなって気がします。
なるほど。
あと、さらにソフトウェア設計は人間関係のエクササイズだっていう表現も何か話題になっていたみたいですね。
人間関係のエクササイズですか。
ええ。
すぐにはちょっとピンとこないっていう反応もあったみたいですけど、XPの価値観、例えばコミュニケーションとかフィードバックを重視するっていう点と、まあ結びつけて考えられていたようです。技術だけじゃないぞ。
まさにまさに。ソフトウェア開発って結局は人が協力してやる活動ですからね。
あ、あと技術的な話で言うとガード説についても話題に上がっていました。
あーガード説。関数のできるだけ早い段階で前提条件チェックしてダメならすぐのけるっていうテクニックですね。
そうですそうです。
その意味の確認とか、あとリードブルコードみたいな本でも言及されてるよねみたいな、そういう情報共有があったみたいです。
それからケント・ベック自身のミッションとされるギークが世界で安全に感じることを助けるっていう言葉。これにはなんか共感が集まってたみたいで。
一方でその安全っていうのが単に技術的なバグがないとか、そういう安全性だけなのか、それとももっと広い意味合いなのか。
それはちょっと本を読み進める中でだんだんわかってくるんじゃないかみたいな、そういう期待感も語られてましたね。
なるほど。単なるコーディングの話じゃないかもしれないと。
そうですね。
あと本の背景みたいな話も出てましたね。三部作の予定だけど続編はまだ書かれている途中だとか。
あとケント・ベック以前の世代、例えば構造化設計で知られるラリー・コンスタンチンとかエドワード・ユードンとか、そういう人たちの仕事に言及することで設計思想の文脈ですね。
文脈ですか。
例えば結合度とか共習度とか、そういう概念がどう発展してきたかを理解するのに役立つんじゃないかっていう指摘もありました。
あー結合度、共習度。ソフトウェアのモジュールがいかに独立しているか、低結合。モジュール内の要素がいかに強く関連しているか、高共習を示すあれですね。古典的な指標。
そうですそうです。そういう歴史的な背景を知ることで、ベック氏の立ち位置っていうのがよりはっくり見えてくるかもしれませんね。
なるほどな。いよいよ革新の設計哲学の話ですね。いつ設計するのかっていう取り。
事前に完璧を目指す推測的設計と問題が起きてから対応する反応的設計。この両極端が示された上で、XPとかアジャイルが目指しているような経験に基づいて継続的に設計していくアプローチ、これに対する関心が高まってたと。
そうですね。推測的設計と反応的設計っていうのはあくまで議論のための分かりやすい両極端として提示されてるんでしょうね。
おそらくこの本が探求しようとしているのはその間にある常に設計し続けるとか、状況の変化に応じて賢く設計するみたいなそういう道筋なのかなと。
ふむふむ。
ここでワグニー原則の話も出てきますよね。
ワグニー。You aren't gonna need it. 今必要ない機能は作らないっていう原則ですね。
これが将来の変更を見越した構造への投資タイミングとどう関わってくるのかっていう疑問が投げかけられてました。
機能追加と構造改善のバランス。これ結構悩ましいですよね。
そうなんですよ。ワグニーって機能そのものには適応しやすいんですけど、将来の機能をスムーズに追加するための良い構造にじゃあいつ投資すべきかっていうのはまた別の判断が必要になってきますよね。
本書ではなんか機能イコールユーザーが欲しいもので設計イコール機能を支えるプログラムの構造みたいなそういう定義も示されてるみたいで。
この区別が結構議論の鍵になりそうだなと感じました。
読書会のまとめと考察
なるほど機能と設計の定義ですか。その上で著者がこの本に書かれていることを信じるなって言ってるっていうのはちょっと驚きでした。
これはどういう意図だと解釈されてたんですかね。
それはですね多分書かれていることをこう鵜呑みにするんじゃなくてあくまで出発点としてちゃんと自分の頭で考えて目の前の状況に合わせて適用したり発展させたりしてほしいっていうメッセージなんだろうなと。
ふむ。
なんかソフトウェア開発に銀の弾丸はないっていうあの考え方を反映しているのかもしれないですね。常に批判的に主体的に関われと。
深いですね。最後にちょっと変わった表現ですけどプログラミングはサディズムの香りがするっていう言葉の解釈もなんか興味深かったですね。
えーまあ複雑で困難な問題と格闘する苦しさの中にある種の達成感とか興奮を見出すみたいなそういう感覚を表現しているのかもしれないですね。
あーなるほど締め切り前のデバッグとかまさにそんな感じかもしれないですね。
かもしれないですね。
さて今回の読書会の序盤の議論を深掘りしてきましたけどタイリーファーストへの期待の大きさすごく伝わってきましたね。
えーそうですね。
理論と実践のバランス設計のタイミングっていう本質的な問いあと人間関係への注目そして批判的思考の重要性。
参加者の方がこの本を通じて共通言語が得られるかもって期待してたのもなんか印象的でした。
単なる技術書を超えて開発への向き合い方そのものを問い直すそんな一冊になりそうな。
まさにそう思います。議論からはコードを今整えることの利益と機能を今届けるっていう要求との間に常に存在する緊張関係みたいなものが浮き彫りになってきましたよね。
そこでこれを聞いているあなたにちょっと問いかけてみたいなと思うんですがもしあなたが整理されていないコードとか複雑なシステムに直面したときにこの生存と機能提供の間のトレードオフにご自身の仕事とか学びの中でどのように向き合っていきますか。
少し立ち止まって考えてみるのも面白いかもしれませんね。
