24年度新卒のJinYangです。
プログラマとして成長し、価値のある貢献を続けるためにみなさんはどんなことを学び、何を実践しているのでしょうか。
ヒントを得るために、最近読んでいる本『プログラマが知るべき97のこと』
をご紹介させていただきます。
『プログラマが知るべき97のこと』には、73人のプログラマによる97本のエッセイに加え、日本人プログラマ8人による書き下ろし10本、合計107本のエッセイが収録されています。これらのエッセイは、コーディング、テスト、プロ意識、チームワークなど、多岐にわたるテーマを扱っており、経験豊かなプログラマたちの知恵が詰まっています。
特に私が心に留めておくべき、実践的で普遍的な5つの原則を、本書の教えに基づいてご紹介します。
1. 学び続ける姿勢（クリント・シャンク）
現代において、自分の市場競争力を維持するためには、「学び続ける姿勢」が不可欠です。学習を止めてしまうと、早晩、時代に取り残されてしまうでしょう。
自ら学びを続けるための具体的な行動としては、以下が挙げられます。
- 自分よりレベルの高い人と仕事をする：周囲に自分より賢明で経験豊富な人がいない場合、転職を考えるべきかもしれません。
- 深く知識を掘り下げる：自分の利用しているフレームワークやライブラリの機能と構造を十分に理解し、オープンソースのものなら、デバッガを使ってコードを逐一確認し、裏側で何が起きているのかを順に見ていくことが推奨されています。これは、最高に頭の良い人たちが書き、レビューもされたコードを直接目にする絶好のチャンスです。
- 新しい技術に触れる：新しい言語や技術、ツールについて毎年学ぶことで、未知のものに触れ、新たな発想の元になります。
2. 他人よりまず自分を疑う（アラン・ケリー）
問題が発生した際、プログラマはしばしば自分のコードを疑うことを避け、「きっとコンパイラのせいだろう」などと考えがちです。しかし、実際にはコンパイラやOS、アプリケーションサーバなど、システムソフトウェアのバグで問題が発生することは、極めて稀です（ほぼ無いと言っていいでしょう）。
プログラマは、コンパイラの誤りを証明しようとするよりも、自分のコードのバグを見つけることに時間とエネルギーを注ぐべきです。自分のコードを徹底的に疑い、デバッグに関して一般的な作業（問題箇所を切り分け、呼び出し先をスタブに置き換え、テストを書いてみるなど）に注力しましょう。
3. コードを読む（カリアンヌ・バルク）
プログラマはコードを書くことを好み、読むことを嫌がる傾向がありますが、他人の書いたコードを読むことは、実は自分の成長につながります。
読む際には、単に内容を理解するだけでなく、そのコードが読みやすいか読みにくいか、なぜそう感じるのかを分析しましょう。他人のコードの読みやすさや論理性、一貫性を分析することで、自分がコードを書く時の教訓とすることができます。また、優れたコードからは、デザインパターンや簡潔なメソッドの書き方など、多くのことを学び取ることが可能です。
4. ボーイスカウト・ルール（ロバート・C・マーティン）
ボーイスカウトには「来た時よりも美しく」という大切なルールがあります。たとえば、自分が来た時にキャンプ場が汚れていても、汚したのが自分ではなかったとしても、きれいにしてからその場を去ることで、次にキャンプに来る人が気持ち良く過ごせるようにするのです。このルールは元々、ロバート・スティーブンソン・スミス・ベーデン＝パウエルの「自分が最初に見た時よりも、世界を良い場所にすべく努力しよう」という言葉に由来しています。
これに倣い、コーディングにおいては「リポジトリにコードをコミットする際には、必ず、手を加える前よりも美しくする」という簡単なルールを守りましょう。 この簡単なルールを皆が守るだけで、少なくともシステムの品質が低下することは防げます。逆に、時間の経過とともにシステムの品質は徐々に向上していくはずです。この取り組みは、開発チーム全員が自分の担当する小さな部分だけでなく、システム全体の質に目を向けることにもつながります。 コードに変更を反映させる前にできる具体的な改善としては、以下のようなことが挙げられます：
- 変数名をより適切なものに変える。
- 大きな関数を2つの小さくよりシンプルな関数に分割する。
- 循環参照を解消する。
- インターフェースを追加することで、ポリシーと実装を切り離す。
このルールは、誰もが守るべき当然の礼儀であり、コードに「汚い」部分を残したままにすることは、ゴミをまき散らすのと同じくらい、社会的に受け入れがたいことです。このルールを守ることは、チームのメンバーが互いに助け合い、互いのコードをきれいにすることにもつながり、自分だけではなく、皆のためになります。
5. 不具合にテストを書いて立ち向かう（和田 卓人）
不具合（バグ）の報告を受けたとき、焦って修正に取り掛かると、一つの修正が複数の新たな不具合を生んでしまう事態になりがちです。本書の監修者である和田卓人氏は、テスト駆動開発（TDD）の先達から学んだ「不具合の修正時には必ず先に不具合を再現する自動テストを書いてから修正する」という「掟」を実践することを推奨しています。
この手法は一見遠回りに見えますが、合理的で効率的な手法です。
- 不具合を再現する自動テストを書き、テストが落ちることを確認する。
- そのテストが通るように不具合を修正する。
この手順を踏むことで、「不具合が本当に自分の考えた原因で発生しているか」が明らかになり、また「最小単位を探す」という行為は、対象コードやドメインに対する理解を深める良い機会となります。不具合修正時のテストを残しておくことで、今後の不具合の再発防止にも役立ち、テストコードの網羅性と既存コードへの自信を高めることができます。
いかがだったでしょうか？ これらの5点は私が特に大事にしないといけないなあと感じている教えです。すべてを実践できているわけではありませんが、とにかく心がけて毎日の業務にあたりたいものです。みなさんも大事にしている教えがあれば共有してください！
