「プログラマが知るべき97のこと」をGWから少しずつ読み直していた。実は昔一回一通り読んだのだが、それから公私でいろいろな経験を積んだためか、今回読み直してみたらまさに何度もハンマーで殴られる感覚を味わうことになった。

GWに「プログラマが知るべき97のこと」を読んでるみんな、どうか流し読みはせずに全部熟読してくれ。
2年ぶりにこの本を読み直して、なんで2年前にもっと真剣に読まなかったんだと50回くらい後悔している私との約束だ。
— どもも (@Udomomo) 2019年5月2日

↑読み直し始めた直後の時点でこんな感じ。その後もたくさん殴られた。

97個(+日本人エンジニアによる10個)もトピックがあり、人によって刺さる箇所はそれぞれ違うと思うが、自分に特に刺さったところをまとめてみる。

07 共有は慎重に

DRYの原則はとても重要だが、だからといって共通の部分は必ずまとめればいいとも限らない。大事なのは、まとめようとしている行が出てくる処理のコンテキストである。意味も文脈も全く異なるロジックの一部を共通化してしまうと、修正時の影響範囲がムダに広がるだけで終わってしまう。
本を読んでコーディングのコツをわかった気になると、こういうミスをしがち。

19 誰にとっての「利便性」か

コードを書くときに、簡潔さと読みやすさのバランスをどう取るか悩んでしまうことがある。そんなときに意識すべき考え方が「そのコードを使う側の立場に立つ」ということだ。自分にとって利便性が高いかではなく、そのコードについて全く知らず初めて使おうとする人が、使い方をすぐ理解し、誤った呼び出し方をしないようにするにはどうすればいいか、常に頭に置いて書くべき。
これは自分にとって良い判断基準になりそう。この項目を読んでから、このコーディングで良いのか？と見返すときの観点が変わった。

21 技術的例外とビジネス的例外を明確に区別する

今まで例外処理のベストプラクティスがよくわからず、なんとなく済ませてしまったこともあるのだが、この項目を読んで腹落ちした。
技術的例外は、例えばDBとの接続が切れたり、メソッドに渡した引数が正しくなかったりなど、そのままではアプリケーションの実行を続けられないような種類の例外である。このような場合、自分で例外を定義したり安易にcatchしたりせず、アプリケーションのトップレベルにある例外処理メカニズムに任せるべき。これに対し、ユーザが正しくない値を入力した場合など、ユーザの側に責任がある例外は、自分で例外をcatchして再び正常な動作に戻す方が良い。この例外処理は、できればクライアント側のコードで済ませておき、サーバには影響を与えない方が良い。

46 すべきことは常に明確に

最初から大目標に向かって走り出すのではなく、まずはそのために必要な小目標に分解してから作業を始める。 そして、途中で内容がずれていたり違う方向が良いと思ったら、それまで書いたコードを一旦破棄して考え直す。
この話はタスク積もりの話にも通じると思う。これができなかったために、目標を期日までに達成できなかったことも何度かあったため、今は特に気をつけている。

udomomo.hatenablog.com

61 ビルドをおろそかにしない

仕事ではあまりインフラの業務は扱っておらず、また個人プロジェクトでもコードを書くことに目が行きがちで本番ビルドは適当にやってしまうことが多かった。しかし、最近自分の会社では開発・リリースサイクルを早めるために、ビルドプロセスの自動化・簡潔化が重要な課題になりつつあり、チーム全員がビルドについての知識を求められるようになっている。ビルドプロセスまで含めて自分たちで作る責任があるということを意識したい。

75 面倒でも自動化できることは自動化する

この本の中で、一番読んでほしい項目を1つ挙げろと言われたら、ここを推したい。
自動化が大事ということはみんなわかっていると思うけど、自動化するための仕組み作りには多少の時間と労力がつきものなので、「それだったら手作業で繰り返しやった方が速くない？」と思ってしまう人もいるだろう。また、そもそも単純作業を当たり前のものと思ってしまい、自動化するという発想が浮かばないこともあるかもしれない。
けれど、大事なのは「これってもっと楽なやり方ないのかな？」と思えるかどうか であり、それこそが「怠惰」の能力である。