Tom Long『Good Code, Bad Code』

プログラミングの本を読む上での問題。それは、自分が潜在的に理解している本しか読んで理解できないこと。

プログラミング本を読んで自分の限界・境界を広げることは不可能である。唯一、読むことで限界・境界を広げられる本はチュートリアル本。いわゆる初心者本だ。

同書の序章では、この本が開発一年目から三年向けのソフトウェアエンジニア向けであると述べている。入社一年目、新米エンジニアが同書を読んで内容を理解できるか？サンプルコードはたくさん記載されていて、実にわかりやすい。しかし、ビギナーには少しニッチ過ぎる気がしている。

書かれていることはとても役には立つ。だが、新米エンジニアからすると面白い領域のプログラミングについて書かれているわけではない。一番泥臭い領域の本だ。その泥臭い仕事をやり遂げられたかどうかが good code と bad code の違いであるのだが。

私的には、四章 Errors を一番楽しんだ。プログラミングは、一定の正解を示す方向性は存在するが、絶対的な正解は存在しない。全ての実装はトレードオフの上に成り立つ。

同章では、いくかのエラーハンドリグの方法を俯瞰的に取り上げている。どういった時にどういうハンドリングをすべきか、また、チームとしてどのハンドリング方法を採用すべきか。意思決定をする際、実に参考にしやすい。

第三部の Unit Testing も興味深かった。

いま携わっている仕事は、本格的に単体テストを実装している、自身初のプロジェクトである。JavaScript(TypeScript)案件のため、テストライブラリにはJestを使用している。単体テスト自体を書くことはそれほど難しくない。Jestの公式ドキュメントを読めば簡単に実装できる。だが、いまやっているやり方—つまり、ほぼ我流—がベストプラクティスな感じは一切ない。

一番の課題はモック。はっきり言って、モックをした時点でテストを書く意味はほぼなくなる。そして、テストを書けば書くほどモックは増えていく。同じようなモックを何度もする。テストの効用が次第に薄れていく。

この問題は、Dependency Injectionを使って関数を実装、現在、テストでモックしている部分をFakeに変えれば解決できる。(修正コストはだいぶ掛かるが…)

新米エンジニア向けの本であるかもしれないが、チーフエンジニア、後輩を育成する先輩エンジニアにぜひ読んで欲しい一冊である。