ITエンジニア本大賞2022の技術書部門大賞に選ばれた書籍「達人プログラマー」。
エンジニアなら読むべきこの名著「達人プログラマー」を読んでみたので、感想をこの記事では紹介していきたいと思います。
達人プログラマーとは
表題の通り「達人プログラマー」とはどういった心構えで日頃プロダクトと向き合うべきか、どういった考えを持ってコーディングするべきかということが幅広く記述されています。
それぞれ各セクションごとに完結しているので、どのセクションから読んでも良いし、セクションごとで区切って読み進めることができるので非常に読みやすい構成となっていました。
この記事では特に印象に残っており、日頃エンジニアリングを行う上でも大事な心構え、学びになったセクションを紹介したいと思います。
達人の哲学
ソフトウェアのエントロピー
エントロピーとは物理学の用語で、無秩序な度合いを表す指標です。そして熱力学の法則によるとエントロピーは時間ともに増加していき、無秩序さは次第に大きくなっていくことが証明されています。
ソフトウェアにおいても同じことが言え、技術的負債と表現されることもしばしばあります。
ソフトウェアのエントロピーを増加させないためには、「割れた窓」を放置しておかないことです。
ここでいう「割れた窓」とは悪い設計や誤った意思決定、質の悪いコードを指します。
「割れた窓」は見つけ次第、修正すべきです。放置すればエントロピーは増加していき、気づけば誰も修復できないような状態になってしまうことでしょう。
達人のアプローチ
DRY原則 – 二重化の過ち
DRY原則とは「Don’t Repeat Yourself」の略で、同じことを繰り返すなという原則です。
同じ知識を2箇所以上に記述することでコードの保守性を著しく損ないます。なぜなら、片方を変更すれば、もう片方も変更しなければなりません。これはそのことを知っている人しか修正できない知識になってしまいます。
ここまではプログラマ経験がある人ならよく聞く内容かと思います。
しかし、この書籍ではDRY原則はコード以外にも適用されるべきだと記載されています。
コードの二重化だけでなく、知識や意図についても二重化を避けるべきです。ドキュメントについて同じことが言え、またコードの中に記載されるコメントについてもコードを読めばわかるような知識を記載することはDRY原則に反していると言えます。
直交性
直交性とは、別の言葉で表すと「独立性」や「結合度の低さ」と近い意味を表します。
２つ以上のものごとで、片方を変更しても他方に影響を与えない場合は、それらを直交しているということができます。
直交していない場合、コンポーネント間での依存度は高くなり、修正する場合には局所的な修正では済まない事態になってしまうでしょう。
生産性の向上、変更リスクの低減のためにも直交したシステムを目指すべきです。
柳に雪折れ無し
インヘリタンス（相続）税
継承は結合です。しかも、すべての祖先に結合します。
コード共有のために継承を使う場合、親クラスのいらないプロパティやメソッドをも受け継ぐことになります。
型の構築のために継承を使う場合、継承の数が増えるたびに複雑さが増し、アプリケーションは脆いものとなり、変更容易性がなくなります。
コードの共有、型の構築のために継承したいのであれば、優れた代替が存在します。それらのいずれかを使用すれば大抵の場合は継承を使わなくて済むようになります。
インターフェイス
インターフェースとは、１つ以上の振る舞いの集合を定義できる実装を持たない抽象型を指します。
インターフェースを使うことで継承を使わずとも型の構築を行い、実装するメソッドの強制、ポリモーフィズムを実現することができるのです。
委譲
委譲とは、一部の振る舞いを別のオブジェクトに代替させることを指します。
必要な処理を委譲先のクラスで行い、それを利用するクラスで必要な情報だけ外部に公開すればいいのです。
そうすることで継承を使わずともコードの共有を行うことが可能になります。
has-a(包含関係)はis-a(継承関係)に勝る。継承より委譲です。
コーディング段階
リファクタリング
コードは一旦完成しても、それ以降不変のものになるのではなく、進化し続けなければなりません。
日々コードの書き直し、再作業、アーキテクチャの見直しすることをリファクタリングと言います。
いつリファクタリングを行うべきなのか
日々良い考えが浮かんだ時、何か学んだ時がリファクタリングを行うべき時です。
- DRY原則に反しているものを発見したとき
- 直行性を高められるとき
- パフォーマンスを向上させることができるとき
現実世界の複雑さ
リファクタリングにまとまった大きな時間を割くことは難しい。
リファクタリングを避ける言い訳として、納期がよく用いられるが、リファクタリングをやめれば将来的に問題が発生した際により時間がかかる。
ソフトウェアのエントロピーでも伝えたように、放置すればその複雑性は開発が進むにつれて増大していきます。
早めにリファクタリングをすること、こまめにリファクタリングすることが大事なのです。
どのようにリファクタリングするか
機能追加を同時に行ってはいけません。
またリファクタリングを始める前にテストを用意します。できる限り頻繁にテストに行い、壊れた場合は検知できるようにしておきます。
なるべく小さい単位にまとめて、単位ごとにテストを行い、リファクタリングを行っていきます。
まとめ
紹介したのはほんの一部でしたが、プログラミングを行う上で大切なことばかりです。
この他にもプログラミングを行う上で大事な考え、心構えが書かれているので気になった方はぜひ手に取って読んでみていただければと思います。
