【書籍情報】
良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方
仙塲 大也
出版社: 技術評論社 (2022/4/30)
ISBN-13: 978-4297127831
【概要・コメント】
久しぶりにコーディング技術向上のための技術書を読んだ。
まず結論から述べると，この書籍はおすすめできる。
特に，複数人でコーディングをする人，コーディングにおける自分の記憶力，分析力に限界を感じている人は，必ず目を通すとよい。
Amazonレビューにも書かれているように，この著者の批評や表現にはやや癖がある。
しかし，コーディング初心者がなんとか次のステップに進むための足掛かりを作ろうとする心意気を強く感じる。
本書に書かれている内容を，この書籍以外から読み取れないかと言われれば，もちろんそうではない。
（本書の末尾で紹介されている）複数のいわゆる名著と呼ばれる書籍を読めば，より詳しく，正確な情報が得られるかもしれない。
しかし，それらの名著に手を伸ばす前に，そもそも，ソフトウェアの設計が必要であったり，モデリングやリファクタリングが必要だったり，コーディングのルール策定が必要だったりということを知らせる，つまりコーディング初心者に，よりよい世界が存在することを知らせるために本書は非常に役立つと思う。
一方で，本書の章構成は，すこし完全の余地があるように思う。
1, 2章で悪しきコードの構造について概説し，2章で設計の初歩をまとめているが，これが短すぎる。
ここの導入が不十分な中で，3章のクラス設計および4章の不変の活用で，いきなりパンチの強い（が効果の高い）設計技術を伝えているので，咀嚼しきれない読者の反感を買っているような気がする。
自分も，最初読んだときは，「うーん極端な意見を述べる著者だなぁ。」との印象だった。
先に読み進めると，著者がなぜそのような設計技術を先頭の方に書いたのか理解できるし，納得もできるのだが，最初に反感を持ってしまった著者が，素直な気持ちで，本書を読み進めるのは難しいかもしれない。
繰り返しになるが，本書は素晴らしい書籍である。
以下，本書で特に気になった部分について議論する。
- P.105 "switchの代わりにMapで切り替える"
本当に，このポリシーは大切である。選択肢を作ることと，選択肢に応じて切り替えることを同時に実現できるのが(Hash)Mapのよさである。正直，interface云々の部分よりも，このMapを使って切り替える大切さをもっと強調して欲しかった。 - P.148 "単一責任の原則"
「クラスが担う責任は，たったひとつに限定すべき」という設計原則であるが，結局簡単なものをたくさん上手に組み合わせて，難しいことを実現するのが分割統治という意味からも正しい。はやく難しいことを，難しく表現するという残念な世界から脱却したものだ。 - P.189 "nullを返さない，渡さない"
現実には，null（真に何でもないもの）なんてものは世の中には存在しないのに，その存在を許容できてしまうのがソフトウェアの怖さである。空であるならば，EMPTYと表現するという現実にそくした当たり前な表現を模索したい。 - P.196 "技術駆動パッケージング"
技術的な，もしくは実装の都合のみで，物事を決めていく怖さをいつも感じる。もちろん，技術的・論理的に整合性が取れていることはとても大切であり，それは必要条件である。一方で，それを読む（必ず何かしらの能力に限界がある）人のことを考えると，技術的・論理的な正しさの定義が変わってくるはずである。 - P.346 "たった一度の設計では，良き構造は見出せません。設計と実装のフィードバックサイクルを回し続ける＜以降省略＞"
まさにその通りである。何かを設計するとは，自分の思慮が足りないことを明らかにする作業ともいえる。そして自分が完璧ではないことを知ることは楽しい。なぜならば，まだまだ改善する余地があるということを示しているのだから。