【設計】複雑な処理をメソッドに切り出すことが正しいとは限らない
fukabori.fm 100. A Philosophy of Software Design (1/3) w/ twada を聞きました。このエピソードでは、設計についてのとても有名な本、A Philosophy of Software Designの内容について、対談形式で深掘りしています。日本語翻訳本がない本で、読む勇気がでなかったので、内容を知るいい機会だな〜と思って聞き始めました。その中でとても印象に残った話がありました〜。
メソッドが増えると複雑さが増える
読みやすいコードにしよう系の本を読むと、大抵記載がある、複雑な処理なコメントを書くくらいなら、メソッドに切り出して、いいメソッド名をつけて抽象化しましょうという話がよく紹介されています。
しかし、著者はむやみにメソッドに切り出すとインタフェースが増えるわけだから、逆にメソッドにジャンプして読まなくてはならないコードが増えるという考え方をしているそうです。コードを読んでいて、メソッドの中身を結局見ないといけない場合が結構あって、定義にジャンプして〜また戻ってということがよくありますね、、。それを考えると、一概にメソッドに切り出して抽象化すればいいってわけじゃないなあ〜と結構納得しました！
違う主張があることでエンジニアにとっての選択肢が広がる
ここからは本の内容ではなく、ポッドキャストでお話されていた内容になります。
割と主流な主張に対して、反対の主張をすることも価値があることだということをお話しされていました。
みんなが同じ主張をするより、いろんな主張があることで、エンジニアにとって選択肢が広がるということです！！！
主流な考えだし〜と安直に正しいと思っていることってあると思います。
主流な考えと相対する考えを知ることで、それぞれの考え方に関してのメリット・デメリットを考えるきっかけになって、自分の選択肢を増やすことができるのです！！
極端に１つの思想を信仰するよりか、場面場面で考えを持って設計していく余地が生まれる方が、よりよいなと思います(多分)。レビューの際も勇気をもって自分の考えを発信した上で、話し合っていきたいなと思います！
でも一貫性が大事！
ただし、、複数人での開発の場合、異なる実装方針でそれぞれが進んでいくと大変なことになるので注意です。
複数人での作業の場合は、ところどころ妥協していくことは必要ですね！！
Discussion