Tidy Firstの導入
さて、今回はTidy Firstという本、これに関する読書会のメモと文字起こしがありまして、ここからソフトウェアの整理・整頓について、ちょっと深く見ていきたいと思います。
面白そうなテーマですね。コードをどうきれいに保つか、その具体的なテクニックの話から、もっと哲学的な整理そのものの考え方まで、結構幅白く話されているみたいですね。
そうなんです。参加されたのはプログラマーの方々のようなんですが、この議論から、良いコードとか、もっと言えば良い開発プロセスにつながるような何かヒントを見つけられたらなぁと。
あなたがもしコードを書く方なら、直接役立つ話があるでしょうし、そうでなくても、複雑なものを整理する上で考え方の参考になるんじゃないかなと思います。
はい。じゃあまず具体的な整理の手法から見ていきましょうか。メモによると、まずは説明定数、これ第9章ですね。
説明定数、はい。
コードの中に意味がよくわからない数字、いわゆるマジックナンバーとか、あと繰り返し出てくるような固定値がありますよね。
ありますね。後でこの数字なんだっけってなるやつ。
そう、それをちゃんと意味がわかる名前をつけた定数に置き換えましょうと。これって、ただわかりやすくするだけじゃなくて、コードのなんていうか語彙を豊かにする行為なんですよね。
語彙ですか。なるほど。
チームの皆が共通の言葉でその設計の意図を語れるようになる、その第一歩とも言えるかもしれません。
へー、単なる置き換え作業じゃないんですね。深いな。じゃあ次は明示的なパラメータ第10章ですね。
これをですね、関数が必要とするデータは隠さずにちゃんと引数として明確に渡しましょうということです。
あー、ありましたね。環境変数をコードのなんかずっと奥の方でこっそり参照してるみたいな。
そうですそうです。あれ、後で追うのが大変じゃないですか。
大変ですね。どこでセットされたんだって。
ですよね。だから、隠さずに依存関係をはっきりさせる。で、この隠さないっていう考え方は次の第11章、ステートメントを小分けにするにもちょっと通じるものがあるかなと。
ほー、どういうことですか。
これはシンプルなんですけど、コードの塊と塊の間に空境を入れる。
空境ですか。
それだけでロジックの区切り、つまり処理の意図のまとまりがパッと見でわかりやすくなる。これも意図を見せる工夫なんですね。
なるほど。空境一つにもちゃんと意味があると。面白いですね。
一方で、ヘルパーを抽出する第12章。これはコードブロックを別の関数にくくり出すって話ですよね。
その通りです。特定の目的を持ったコードの塊を別の関数、ヘルパー関数として切り出して、その目的に合った名前を付ける。
これはIDEの自動リファクタリング機能なんかを使うと結構やりやすい場面もありますね。
確かに。ツールが支援する部分ですね。
ただ、その逆の発想もあるんですよ。それが第13章の人塊。
人塊ですか。まとめるってこと?
細かく関数を分けすぎちゃって、かえって処理の逃れがわかりにくくなったコードってたまにあるじゃないですか。
ありますね。あちこち飛ばないと先体像が見えないみたいな。
そういう場合、一度そのヘルパー関数を呼び出し元にインライン化して、大きな塊に戻してから改めて整理し直すっていうアプローチです。
なんか関数を呼び出すときに似たようなすごく長い引数のリストが何度も繰り返される、なんていうのがもしかしたらその兆候かもしれないですね。
整理整頓の意義
なるほど。分けるだけが良いってもんじゃないと。
それでこの第13章の最後にすごく大事な問いかけが出てくるんですよね。
先に整理すべきか、それとも今わかっている変更をするだけで良いだろうかって。
そうなんです。これが結構確信かなと。議論の中でもこれは単純な二択問題じゃないよねっていう話になってました。
二択じゃない。
つまり機能追加みたいな振る舞いの変更と今回話してきたような整理整頓、つまり構造の変更、これを完全に分けて考えるんじゃなくて、開発のプロセスの中で常に継続的に並行してやっていくべきなんだと、そういう考え方ですね。
これ、XP、エクストリームプログラミングの考え方に近いんじゃないかという指摘もありましたね。
常に設計し続けるっていう。整理って一回やったら終わりの大掃除じゃないんですよ。
なるほど。それは面白いですね。まず整理してから機能追加とか、まず機能追加して後で整理じゃなくて、常に両方を意識しながら進むみたいな。
ええ、そういうニュアンスですね。これって日々の開発業務の中だと結構忘れがちというか、どっちかに偏りがちかもしれませんね。
うーん、確かに。それで実践的な面でいうと、コメントの書き方についても議論があったみたいですね。
はい。コメントには何をしているかを書くのではなくて、なぜそうなっているのかを書くべきだと。
なぜですか?
ええ。コードを読んだだけではわからないような背景とか意図とか、例えばメモでは生物学の知識が必要な部分とか、特定のアルゴリズムの選択理由とか、そういうドメイン知識に関する例が挙げられてましたね。
なるほど。コードだけじゃ読み取れない文脈を補給役割なんですね。逆にコードを見ればわかるような冗長なコメントはむしろノイズだから消しましょうとも。
まさにその通りです。あとプルリクエストの扱い方もなかなか興味深い議論がありましたよ。
プルリクエスト、コードレビューの依頼ですね。
はい。その整理整頓、つまり構造の変更と機能追加、つまり振る舞いの変更はできれば別のプルリクエストに分けましょうという提案がされていました。
それはレビューする側からすると変更の意図が一つに絞られてわかりやすいですね。
そうなんですよ。変更点が混ざっているとレビューが大変ですからね。ただ一方でプルリクエストがあまりに細かくなりすぎるとそれはそれで管理が大変になるんじゃないかという懸念もまあ議論はされていましたね。
なるほど。トレードオフがあるとレビューのしやすさは取るかPRの数を抑えるか。
ただまあ小さなPRはレビュー自体も早く終わるっていうメリットも指摘されてはいましたね。
悩ましいところですね。こうやって全体を見てくるとコードの整理整頓って単にきれいにするっていう作業じゃなくてもっと継続的なソフトウェア設計そのものなんですね。
そうですね。議論の中では製造業の5S、整理整頓清掃清潔しつけこれに通じる考え方だっていう意見もあったようです。
ああ5S、なるほど。
将来の変更をやりやすくしたり他の人、宮井の自分も含めてですけどコードを読む人の理解を助けたりするための活動ですよね。
ある意味開発者自身のこう持続可能性を高めるためのセルフケアみたいなものと言えるのかもしれません。
セルフケアですか。面白い表現ですね。
あなたにとって日々の作業の中で先に整理することとまず変更することのバランスってどう捉えていますか。
今回の話をちょっとヒントにしてご自身の開発スタイルを少しだけ見つめ直してみるのも面白いかもしれませんね。
