良いコードの道しるべ 変化に強いソフトウェアを作る原則と実践 - FL #97に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

第97回目では『良いコードの道しるべ　変化に強いソフトウェアを作る原則と実践』を取り上げます。 本書では、簡単に変更できる保守性が高いコードを「良いコード」と定義し、そのようなコードを書くための原則や手法を解説しています。

「なぜ良いコードを書く必要があるのか」という根本的な問いからスタートし、基本要素を順を追って解説。コードの保守性を高めるための最低限の知識を網羅している本書の著者である森 篤史 氏に講演をしていただきます。 基礎を学びたい方、改めて復習したい方、ぜひご参加ください。

会の様子

良いコードとは？

本書では保守性が高いコードを良いコードだと考えているという話がありました。

また、良いコードは時間をかけて書けば完成するわけではなく、必ずスキルが必要になってくるという話がありました。

書籍のおすすめポイント

以下のポイントがおすすめだという話がありました。

• 命名、コメント、関数やクラスの分割...といったすぐに実践できる内容が書かれている
• コードを変更する際に気をつけることが、ステップ・バイ・ステップで記載されている
• 自動化テストやDesign Doc、アーキテクチャみたいなところまで踏み込んで書いている
• かわいいイラストが盛り沢山である

対象読者

初心者をイメージしてはいるものの、中堅エンジニアであったりが基礎をふりかえるために使ったり、チームの共通意識形成に使えるんじゃないか？という話がありました。

ハンマーと釘問題

正しい解決策を知らないと、なんでも自分が知っている知識ややり方で解決しようとしてしまうという話が幾つかの具体例を例に説明されてました。

早期リターンは異常系を早い段階で排除するということには向いているものの、ケースの網羅性が重要な場合やケースが同等レベルな場合は逆に読みにくくなるという話がありました。

他にも、依存性逆転の原則は、より安定したものに依存することができるようになるというメリットを活かしてより安定した他実装に切り替えたりすることができるものの、ドメインオブジェクトなどにこの原則を使ってしまうと逆に良くないということです。

知識の他に必要なこと

解決すべき問題や関連する業界、分野の知識というドメイン知識やアーキテクチャといった自分のプロダクトに向き合うことが重要だという話が出ていました。

Q&A

講演の後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

使い捨てられるようにしておく必要もあると思うがどう考えているか？

機能を疎結合にしておくとかはテクニックとしてあると思っているので、使い捨てられるコードは良いコードだと思う。
ただ、使い捨てられると思いきやずっと使われるみたいなのもよく見る。

コード品質系の書籍は類書も多いが一番のきっかけは？

出版社に声をかけてもらったというのが一番だが、自分のために自分が欲しい本を書いた。

生成AIのコーディング能力が伸びていて変更容易性そのものが人を前程しなくなっていると思うがどう考えるか？

なんとも言えないが、一度に大量の情報を処理するというのは難しくなっているという理解はしている。

良いコードの評価基準を意識して参画するためにまず優先してほしいものは？

これだけ抑えとけば大丈夫、というのはあんまりないので回答が難しい。

意思決定のトレードオフにどのようにチームとして向き合うべきか？

トレードオフとかではなくケース・バイ・ケースのことも多くあるので、メリットデメリットというのを整理してくのは大切だと思う。

アーキテクチャはすぐにその効果が測れないがスキルとしてどう良い設計を検討していくのか？

幅広く経験を積んでいくことと変わり得る前提で設計をしていく。

AIが生成するコードのクオリティは変更容易性という観点ではどう考えるか？

場合による。コンテキスト足りていないというのはよくある。

プロダクト理解をコードに活かすという話があったが、ドメイン知識が浅い段階で設計に参加する際に注意すべきポイントは？

よりドメインに詳しい人に聞いていく。後は、後で直せるようにしておくことが大切。

特にどんな技術領域のエンジニアに読んでほしいか？

UIっぽい話を書いている。

コストと品質の価値のバランスに悩みがある

教育に時間をかけるしかない。ただ、プロダクトによるとは思う。

会全体を通した感想

書籍の名前的にかなり気になってはいたのですが、内容的には割と基本的な部分が多めなのかな？と発表を聞いている限りは思いました。

ただ、良いコードを書くためのプラクティスがただ紹介されているのではなく、そのプラクティスが副作用をもたらす場合の話も書かれているということで、そのあたりは示唆深いしぜひ読んでみたいなと思いました。