【感想】Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考

こんにちは、もっちーです。

今回は「Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考」を読んだ感想を書いていきます。

それでは見ていきましょう！

あなたにとって明確なことでも、他の人にとっては明確でない

これはプログラミングに限らず当てはまることですね。

「これなら相手に伝わるはず」と考えて書いたコードは、本当に相手にとって理解しやすい内容なのか、しっかりと考える必要があります。

このように人それぞれ技術力などが変わってくるので、あらゆる人に対して分かりやすいコードであることが大切だと思います。

この章で書かれていた内容で

他のエンジニアは不注意であなたのコードを壊す

Good Code, Bad Code より引用

という文章がありました。

エンジニアの仕事をしていると、他人が書いたコードに修正を入れる機会は多いと思います。

たとえば、ユーザー情報を取得するメソッドのgetUserに変更を入れるときに、メソッド内でさまざまな処理が入ってるかもしれません。

などなど…

コードを書いた人以外はgetUserという名前を見たら、「ユーザーを取得するだけ処理が入っているメソッド」と判断することが多いのではないでしょうか？

この状態でそのままコードを修正してしまうと、他に実行している処理に影響を与える可能性が多いと思います。

最後にまとめると、自分以外の人がコードを読むことを前提に考えて、複雑でなくシンプルな処理にすることが大切になってきます。

クラスは自分自身に関心を持つべき

ほどんどのシステムで取り入れられているオブジェクト指向ですが、適切な粒度でないクラスを作ってしまうと管理が大変になります…。

クラスと言えば「プログラマー脳」にも書かれていた

すべての記憶は抽象的なクラスのインスタンスであると考えられる

プログラマー脳より引用

という文章を思い出しました。

クラスは抽象的であることが求められているので、クラス自身が持つべき機能だけを実装することが大切です。

クラスの外側にある仕様は気にしないようにして、自分がやるべき仕事だけに集中するイメージです。

与えられた内容（プロパティやメソッドなど）が自分のやるべきことなのか明確にして、不要な場合はわざわざ介入しないようにする。

このようなルールを決めておくことで、後から変更しやすくなったり他人が読みやすいコードになっていきます。

この考え方は、アドラー心理学の「課題の分離」にも似ていると思いました。

↓詳しくはこちらの本で解説されています。

TDD（テスト駆動型開発）について

今の会社ではテスト自体が使われてないので、自分のスキルアップ目的でテストコードを書いてみようと考えています。

やるとしても収益を気にしない個人開発なので、規模が小さめのプロダクトを作ることになります。

そこでTDD（テスト駆動型開発）を取り入れてみようと思います。

普通のコードを書く前にテストコードを用意して、そのテストが通った後に最小限の本番用コードを書いていくやり方です。

このあとに CI/CD実践ガイドを読むつもりなので、テストをGitHub Actionsで自動化することも試してみようと思います。