📖

「達人プログラマー」を読んだ

2022/01/07に公開

新年初の記事として、当社CTOから冬休みの宿題として出されていた「達人プログラマー」をざっと読んだので、その中身や感想について書いていきたいと思います。

追記：いいねが予想以上についてtrendingに載ってしまったので、宣伝しておきます！
私が所属している株式会社iCAREではエンジニアを募集しています。若手エンジニア向けにCTOがエンジニアとしてレベルアップするための講義を開いてくれたり、チームで実力を高め合っています！
Devチームのページ: https://dev.icare.jpn.com/dev/
募集について: https://herp.careers/v1/icare/requisition-groups/a834f71a-27b8-43e6-b533-6fa4f17f48a8

「達人プログラマー」とは

達人プログラマー ―熟達に向けたあなたの旅― 第2版 David Thomas https://www.amazon.co.jp/dp/B08T9BXSVD/
Amazonの概要欄より引用

より良いプログラマになるための実践的アプローチ
本書は、David Thomas and Andrew Hunt, The Pragmatic Programmer 20th Anniversary Edition (Addison Wesley, 2019）の日本語版です。
本書は、より効率的、そしてより生産的なプログラマーになりたいと願うソフトウェア開発者に向けて、アジャイ>ルソフトウェア開発手法の先駆者として知られる二人により執筆されました。経験を積み、生産性を高め、ソフトウェア開発の全体をより良く理解するための、実践的なアプローチが解説されています。
先見性と普遍性に富んだ本書は、入門者には手引きとなり、ベテランでも読み直すたびに得るものがある、座右の一冊です。

総評・雑感

達人プログラマーになる方法として、コーディングに対する心構えについてももちろんなのですが、それだけにとどまらず、広い意味でソフトウェアのエンジニアリングに関わる心構えと、それを凝縮したTips達が書かれています。ソフトウェアの設計の仕方、日頃用いる道具や習慣について、チームとしての仕事の仕方、ソフトウェアを安全かつ効率的に、そして何よりも「良い」ソフトウェアを作るために何をすべきか、「達人プログラマー」がどのような姿勢で日々の仕事に向かい合っているのか、というのが書かれています。
大局的なものの見方から、細かいソフトウェアのコーディングのテクニックまで、本当に幅広い内容が書かれている本です。個人的には一度に全ての内容を消化するのは難しく、手元に置いておいて折りに触れて読み返したいタイプの本だと感じました。
この本では大事な内容が１００個のTipsにまとめられています。個人的に心に残ったというか興味を惹かれたのは、ソフトウェアの設計やコーディングの実践的なプラクティスというよりは、プログラマーとしての素養や心構えに関する内容でした。
１００のTips全てに言及することはできないので、その中から３つ程度抜粋して感想を述べたいと思います。

興味を惹かれた３つのTips

Tip9 あなたの知識ポートフォリオに対して定期的な投資を行うこと

プロフェッショナルなプログラマーとして、長期的に成長していく、つまり「達人プログラマー」を目指すにあたって基本的な心構えだと感じました。本によると、自分の経歴を磨き輝かしいものにするため、金融ポートフォリオとの管理と同様に知識ポートフォリオを管理する必要があります。継続的に、かつリスクを分散しながら、自分の知識ポートフォリオを育てていく必要があるのです。その学習の過程で、思考の幅が広がる、と本には書かれています。本には「ゴール」として、知識ポートフォリオへの投資のための実践的な行動の提案がなされています。

毎年少なくとも言語を１つ学習する。
月に一冊のペースで技術書を読む。
技術書以外の書籍を読む。
講習を受講する。
近場のユーザーグループに参加する。
異なった環境に慣れ親しんでみる。
最先端にとどまり続ける。

毎年一つ新しい言語を学ぶというのはよく聞く話ですが、個人的にこれはとても興味深いというかやってみたいことです。なぜなら、私は結構言語仕様とかそういうのに興味があるので、複数の言語を学ぶことによって、相対的に言語の仕様やその背後にある思想を位置付けて学ぶことができるだろうなと思うからです。ぜひやってみたいですね。
去年私は仕事でRubyを使い始めたのでそれが去年の言語だとして、今年はなんでしょうか。Rubyもまだ知らない事がたくさんあるのでそれを学び続けるのはもちろんですが、最近Rustの本も衝動買いしてしまったので、Rustを学ぶのも良さそうです。静的型付で、厳密な言語が個人的に好きだというのもあります。
あとは読書に関して、最近kindle端末も買ったので、読書もどんどん捗らせていきたいですね。今年は外部の勉強会（Ruby関連をまずは想定しています）に顔を出してコミュニティ活動もしてみたいという思いがあるので、そういう活動を経て知識の幅を広げられるといいなと思っています。

Tip27 エディターに熟達すること

第３章「基本的なツール」では、職人が匠の技を追求する際に質の良い道具一式を揃えることに準えて、自分のプログラマーとしての能力を増幅させるために、自分の「道具箱」を作り、それら道具に熟達すること、道具を磨き上げより良いものにしていくことの重要さを説いています。
その中でも一番コーディングの中でよく使うエディターに熟達することの重要性については深く考えさせられました。私自身が、本の中で「多くの新人プログラマー」の行動として挙げられている

特定の統合開発環境（IDE）といったパワーツールを一つ採用しそこに安住してしまう

というのをやってしまっている感じがあるので。自分の開発の効率を上げるために、例えば本ではマウスを使わずにエディターをいじれるかどうか、ということを例に挙げていますが、そのようにエディターの入力の効率化、開発全体のフローの効率化を行っていきたいなと感じさせられました。

本に書かれている心構えの中でも重要な心構えとしては本で書かれている以下の内容でしょうか。

まず自らが編集している姿を観察してください。何らかの繰り返し作業を行なっていると気づくたびに、「もおっと良い方法があるはずだ」と考える癖をつけるのです。そして、それを見つけてください。

場合によってはショートカットであったり、時には新たなスクリプト、新たな拡張機能の開発かもしれません。それはそれで、自分のプログラマーとしての幅を大きく広げるようなもので、いいチャンスだなと思います。

Tip34 仮定を置かずに、証明すること

デバッグという行為に、個人的にとても苦手意識があります。本にも書かれていますが、自分の生み出したバグに向き合うのは心理的負荷になり、つい逃げ出してしまいたくなります。しかしながらそれに逃げずに向き合っていかなければなりません。また、デバッグはとても頭のリソースを使う作業で、ソフトウェアや言語の総合的な理解が求められ、付け焼き刃の知識では太刀打ちできない事が多いです。ほっとくと時間も無限に溶けていきますし。（院生の頃一人で開発していたプログラムの１つのデバッグに一週間とか平気でかけていたこともあります。）

この本では、そんなしんどいデバッグという作業に向き合っていくための心構えがいくつかのTipsにまとめられています。
バグというのは往々にして開発者にとって「想定外」の事象によって引き起こされるものですが、この「仮定を置かずに、証明すること」というTipは、自分が「信じていること」をそれだけにして終わらせずに証明しようということを説いています。

ちゃんとしたコンテキストの中で、ちゃんとしたデータを用いて、ちゃんとして境界条件で証明するのです。

また、この本ではデバッグ時のチェックリストというのが書かれていて、自分の手元に置いておきたいリストであるため改めて引用します。

報告を受けた問題は、元となるバグの直接的な結果でしょうか、それとも単なる症状なのでしょうか？
そのバグは本当に使用しているフレームワークに存在しているのでしょうか？それともOSに存在しているのでしょうか？それともあなたのコードに潜んでいるのでしょうか？
この問題を同僚に説明するとしたら、どのように説明すれば良いでしょうか？
疑わしいコードがユニットテストをパスしていたのであれば、テストは十分だったのでしょうか？「この」データを使ってユニットテストを実行していたなら、どうなっていたのでしょうか？
このバグを発生させた条件が、システム内のどこか他の部分に残っていないでしょうか？他のバグがどこかに眠っており、目覚めの時を待っていないでしょうか？

直接的な結果なのか、症状なのかというのはバグを見つけた時の最初に考えることとしてとても重要ですよね。そしてそこを判断する勘所というのがとても難しいと思います。ソフトウェアの構造やその仕様についてよく理解していないと、判断のしようがないという気分になってしまいます。
また、もう一つ重要だと思ったのは、問題を同僚に説明するとしたら、、というチェックポイントです。この本の他の箇所でも、「他人に説明すること」の重要性は説かれていて、むしろその本質を抜き出したものとしてゴムのアヒルに説明を試みる、というテクニックが紹介されているぐらいです。
私も似たようなことをやった事があります。他人に説明しようと試みることで、自分の中の思考とその前提が言語化されて、案外次の一手が見つかったりするものなのです。物事を他人に説明しようと試みることで、自分の頭が整理され、物事に対する理解が深まります。

その他のお気に入りのTips

他に印象に残ったTipsについて箇条書きで紹介します。

Tip24 規律に従ってスケジュールを繰り返し、精度を向上させていくこと
Tip36 あなたは完璧なソフトウェアを作る事ができない
Tip49 プログラミングはコードについての話であるが、プログラムはデータについての話である
Tip62 偶発的プログラミングを行わないこと
Tip81 枠に囚われずに考えるのではなく、枠を見つけ出すこと
Tip100 これはあなたの人生だ。皆と共有し、祝福し、生み出していくこと。そして思いっきり楽しむこと！

最後に

この「達人プログラマー」は本当に広く深くいろんなことが書いてあって、自分のプログラマーとしての経験を積むと同時に、さまざまなフェーズで読み返したい本だと感じました。個人として開発の技術を深めたいとき、チームをマネジメントするようになったとき、新たな機能を開発するようになったとき、新たなサービスや機能を設計したいとき、などなど。
今後も読み返しながら「達人プログラマー」を目指したいと思います！