読んだ書籍
『良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方』
学べること
ソフトウェアの保守性、特にその中の変更容易性に注目して改善することで継続的に価値を生み出していくための技術を学ぶことができる。
- コードには良し悪しがある
- 悪いコードとはどんなコードか
- 悪いコードは何を引き起こすのか
- 悪いコードをどのように良くしていくのか
- 設計についての取り組みを促進するための方法
現場で学べる機会が少ない
プログラミングの入門書を学習し終わった時に、その後にどうやって設計スキルを向上させていけばいいのか。それは自力ではなかなかたどり着けないというか、多くの人がそういうふうに苦しんでいるんじゃないかなって思います。1
私の状況もそんな感じだった。
- 教えてくれる人がない
- 動く機能を作ることが評価される(コードの良し悪しを評価できない/しない)
- 動くコードを変更できない(仕様、テストの消失)
- コードの良し悪しに取り組む余裕がない
「開発がしんどい」という状況に対して「もっと良くできるはず」と信じて模索していかないと、たどり着けない状況が多いのではないかと思う。
なので、まさにこの書籍は”初級と中級の間にかける橋”になりそう。
コードの例が多い
具体的な悪コードの例から、それを良いコードにするという形で解説されている。
いざ悪いコードの例を示そうとしても、これだけたくさん出てくるものではないと思う。
それに、抽象的なコードだとわかりにくいし、具体的なコードだと突っ込みどころが多くなってしまいそうなので、これだけ多くの例を示すのは想像以上に難しそうだ。
良いコードの例は最良ではない
いくつか感想で次コードに触れているのを見かけた。
class HitPoint {
private static final int MIN = 0;
int amount;
boolean isZero() {
return amount == MIN;
}
}
定数MIN
とisZero
メソッドの名前が不一致なのは気になるところ。
基本的には「最小値がゼロ」という知識が外部に漏れてしまうのは良くないので、isZero
メソッドをisMin
に変えたい。
例えば、定数MIN
の値が変わってしまったらisZero
メソッドの名称も変えなければならない。
ただしゲームにおいては「ヒットポイントがゼロ」というのは慣れ親しんだ表現だと思われる。
これがゲームのヒットポイントにおいて基本的な概念なら、isZero
メソッドの方が「良い」といえるのかもしれない。
(もちろんこれに当てはまらないゲームがあれば話は変わる)
このように書籍の良いコードは必ずしも最良を示しているわけではない。
対象や環境、タイミングにもよるので、継続的に評価して改善し続けることが大事。
「良いコード/悪いコードを学ぶ」ではなく「良いコード/悪いコードで設計を学ぶ」ための書籍。
名前設計の重要性
「10章 名前設計」はそれ以前の章と異なり、ロジックの話ではなく、「何のために、何を作るかのか」という話になっている。
適切な名前がつけられない場合、対象を正しく認識できていないのかもしれない。あるいはプロジェクト内での認識が異なっているかもしれない。
対象を正しく認識できないということは、それに付随する責務やルールも不明瞭なので、単一責任の原則やDRY原則を始めとした9章までのテクニックを活用するのが難しい。
スピードの要求は高まり続ける
全ての現場で「良いコードに価値がある」とは言えないのかもしれない。
そこに価値を置くかは組織構造やビジネスモデルによるところも大きい。
しかしながら、業界全体としてはスピードの要求は高まっているようだ。
Google CloudのDORAチームは、ソフトウェアデリバリーと運用パフォーマンスは年々加速してる、と分析している。2
こうした動きを背景に「開発スピードを上げるための保守性の向上」はこれからも注目されていく思う。
ソフトウェアエンジニアとして設計スキルを高めていくことは、将来の選択肢を広げることにもなりそうだ。
最後に
もっと売れて読まれてほしい。
-
理想形を知ることで、理想でないものを認識できるようになる 『良いコード/悪いコードで学ぶ設計入門』の5つの特徴、習得可能な2つのスキル https://logmi.jp/tech/articles/326658 ↩
-
2021 年の Accelerate State of DevOps Report で、燃え尽き症候群とチームのパフォーマンスについて発表 https://cloud.google.com/blog/ja/products/devops-sre/announcing-dora-2021-accelerate-state-of-devops-report ↩