読書会の目的と内容
こんにちは。今回は、プログラミング書籍Tidy First!この読書会での議論を深く掘り下げていきたいと思います。
皆さんの活発な意見交換の記録をもとに、特に重要だと思われるポイントや、議論で形作られた共通の理解みたいなものを抽出していきます。
この本が提唱するタイリング、コードの整理・整頓ですね。これを日々の開発にどう生かすか。
読書会では、その辺り単なる個人の感想じゃなくて、かなり具体的な実践方法とか、その意味合いについて深い議論がされていましたね。
今回は特に、その用語の解釈とか、具体的なコーディング手法に関する議論の確信を探っていきましょうか。
はい、そうしましょう。
では早速ですが、そのリファクトリングという言葉、これが議論の中心にあったようですね。
ええ、ありましたね。本来の意味、つまり振る舞いを変えずに内部構造を改善することからちょっと離れて。
なんか大規模で、時にはちょっと避けたいような、そういう変更を指す言葉になっちゃったんじゃないかと。
そうそう、そういうもんで意識が共有されていました。
そこで著者ケントベックがタイリング、日本語だと整頓という言葉を提案したわけですね。
整頓ですか?
ええ、機能変更の前に行うもっと小さい、心理的なハードルも低い準備としての整理みたいな感じです。
なるほど。
読書界の方では、このタイリングを近藤真理恵さんの片付け術、あれに例える視点もあって面白かったですよ。
ええ、近藤真理さんの。
コードの糸を明確にするための小さくて意図的な整理、整頓みたいな、そういう捉え方ですね。
あと、可愛くてふわふわした小さなリファクトリングなんて証言も。
可愛くてふわふわ。
その手軽さをよく表してるってまあそういう話でした。
なるほど。
タイリングは人微的な整理、これでリファクトリングとの違いもすっきりしますね。
そうですね。
次に3章のシンメトリーを揃える。
これも結構議論があったとか、見た目の対照性じゃないっていう話ですよね。
まさに。
ここでの重要な洞察は、シンメトリーっていうのはコードの一貫性なんだということでしたね。
一貫性ですか。
ええ。
同じ目的のコードは同じスタイルで書くべきだと。
違う書き方が混在すると、読む人の認知的な負荷が上がっちゃうからという理由ですね。
ああ、なるほど。
プリンシップノブ・プログラミングっていう本に出てくる対照性とも関連があるんじゃないかみたいな指摘もありました。
ふむふむ。一方で有機的っていう言葉、これはどうでしたか。
有機的。これはですね、ワインバーグのモデルとの関連とか色々考察はあったんですけど、解釈は結構多様で、明確な結論みたいなものは出なかった感じです。
整理の重要性と改善活動
でもそれ自体が議論としては興味深い点でしたね。
なるほど。概念的な話から少し具体的なコードレベルのテクニックに移りましょうか。
はい。
読書会では日々のコーディングに役立つ手法も色々議論されてましたよね。一生のガード説とか。
ああ、ガード説。関数の最初の方で異常形とか前提条件をチェックして、ダメならすぐ返すっていう。
ええ、あれですね。
これももうネストを深くしないで済むし、メインのロジックが追いやすくなるっていう明確なメリックがあるよねということで、参加者の間でも広く有効性は認識されていましたね。
コードをシンプルに保つという点では2章のデッドコード、使われなくなったコードの扱いも議論になりましたね。
やっぱり消すことへの抵抗感ってあるじゃないですか。
ありますね。
でもそれと対比される形でバージョン管理システムの存在が語られていました。
ああ、Gitとかですね。
そうです。不要になったらもう恐れずに削除しよう。もし必要になったらバージョン管理から戻せばいいんだからっていう、そういうの割り切りが大事だと。
心理的な抵抗よりもコードベースのきれいさを優先すると。
ええ、そういう考え方ですね。健全なコードベースのためにはと。
削除だけじゃなく、より良い構造を作るための議論も4章の宣言的なインターフェースはどうでした。
これはまず理想的な使い方、インターフェースを定義してそれに合わせて中身を実装していくっていうアプローチ。これが有効だよねと。
先に理想を描くみたいな。
そうですそうです。特に既存のちょっと使いにくいインターフェースをラップする形で新しくきれいなインターフェースを提供するみたいな。
パラデルチェンジとも関連づけて語られてましたけど、これはレガシーコードを改善する上ですごく実践的だよねって共感を呼んでました。
なるほど。変数の扱い、7章とか8章についても重要な議論があったと聞きました。
そうですね。特に強調されていたのは、まず変数の宣言と初期化、これをできるだけ近づけましょうということ。
はい。
それから複雑な計算式とかはその意図がわかるような名前をつけた変数、いわゆる説明変数ですね。それに抽出しましょうと。
あー過読性が上がりますもんね。
格段に上がります。あとコミットを分ける話も重要でしたね。タイリング、つまり整理のコミットと振る舞いの変更のコミット、これをちゃんと分けましょうと。
変更履歴が追いやすくなる。
その通りです。後で追跡しやすくなる上でこれは不可欠だよねって再確認されていました。
5章の読む順番とか6章の行集度については最初ちょっと解釈に揺れがあったという話も聞きましたが。
少し混乱もあったみたいですね。でも議論を通じて最終的に明確になったのは、読む順番っていうのは行動を読む人が理解しやすいように記述の順番を整えましょうということ。
で、合集度っていうのは、慣例性の高い行動を、たとえファイルとかリポジトリをまたいだとしても、論理的とか物理的に近くに集めましょうということの重要性ですね。
なるほど。結局は保守性とか過読性を高めるためのプラクティスなんだと。
そういう認識が深まったようです。
今回の読書会の議論全体を見渡してみると、タイディ・ファーストが言ってる整頓っていうのは決して大規模な改修作業じゃなくて。
違いますね。
日々の開発サイクルに組み込んでいくべき小さくて継続的な改善活動なんだなっていう、そういう共通理解が議論を通じてしっかり作られた感じがしますね。
まさにその通りだと思います。大きな機能追加とか本格的なリファクタリングのその前に、まずコードを読みやすく整理する。
この小さなステップを習慣にすること自体が、変更しやすい健全なコードベースを保つための鍵なんだと。そういう思想が根底にあるようです。
読書会の議論はその価値を皆で再確認するいい機会になったわけですね。
ええ、そう言えると思います。
では最後に、これを聞いているあなた自身への問いかけです。日々のコーディングでまず整理するというこの小さな一歩。
はい。
これを意識的に取り入れることで、あなたのコードとの向き合い方、あるいはチームでの開発の進め方にどんな変化が生まれる可能性があるでしょうか。
うーん、それは大事な問いですね。
ぜひ少し立ち止まって考えてみてください。
