『The Clean Coder』の感想・要約・補足


最近『The Clean Coder』（中訳：無瑕的程式碼 番外篇－專業程式設計師的生存之道）を読み終えました。ちょうどネットで最もよく見る質問の 1 つに答えられる内容だったので、この文章を書きます。

駆け出しエンジニアとシニアエンジニアの違いは何か？

多くの人は、技術面の違いだと考えがちです。たとえば駆け出しは知っている技術が少なく、フレームワークに頼りがちで、使えるツールも少ない。一方でシニアはより多くの技術を理解し、技術的な違いやトレードオフを説明でき、状況に応じて最適なアーキテクチャを選べる。さらに地雷をたくさん踏んできたので、問題を先回りして避けられる、などです。

私も最初はそう思っていました。もちろんそれも違いの 1 つですが、最も重要なのはそこではありません。最も重要なのは「人との向き合い方」です。『The Clean Coder』は、プロフェッショナルで教養のあるエンジニアとは何かを徹底的に扱い、どうコミュニケーションし、どう「プログラミングという仕事」をうまくやるかを語っています。実際、この本の概念はエンジニアだけでなく、あらゆる職業に当てはまります。ソフトウェア開発を例にしているだけです。

「Yes」と「No」

私たちは上司、PM、同僚、顧客などからタスクを任されます。「Yes」と「No」を正しく言えるようになる必要があります。プロは過度に約束すべきではありません。できないことには「No」と言い、相手に合理的な期待値を提示し、自分の能力範囲で「Yes」を言うべきです。

できるならできる。できないならできない。「やってみます」と言うな。

本には Yes と No の使い分けを示す例がいくつかあり、状況を体感するには実際に読むのが一番です。私は「良い／悪い」を正しく伝えるには 2 つの能力が必要だと思います。1 つは物事を高度に把握し、複雑度と期限を分析できること。もう 1 つは、その論述を相手に納得してもらう力です。そこには必然的に大量のコミュニケーションが必要になります。

リーンなソフトウェア開発

一般に言われる通り、プロのプログラマはより良く、より効率的なやり方を持つべきです。ありきたりな話に聞こえるかもしれませんが、一度自分を見直す価値はあります。

気分

プログラマは創造力が必要な仕事です。芸術家と同じで、「ひらめき」と「集中力」が必要になります。儀式がないと書けない人、深夜にコードを書くのが好きな人、音楽を聴きながら書く人、自分のリズムを保ちたい人など様々です。要するに、気分を整えて、いちばん心地よい状態にし、そこから創造力を引き出します。

助け合い

同じチームである以上、助け合いは責務の一部です。惜しみなく助ければ、自分も何かを得られることがあります。逆に、プライドが高くて助けを求めないのも良くありません。時には他人の助けが必要です。たとえば面白いデバッグ手法として、があります。

デバッグ・修正・テストの過程で、作業者が小さな黄色いアヒルに対して各行のコードの役割を根気よく説明し、それによってひらめきを得たり矛盾を見つけたりする方法。


つまり同僚がアヒル役をやってくれます。また、Code Review で同僚のコードをチェックすることも、お互いに切磋琢磨する良い機会です。

テストの重要性

本ではテストの重要性が何度も強調されています。もちろん私たちも理解していますよね？
本に例があるので、ここでは私自身の経験を共有します。

Cloudmosa でインターンをしていた頃、ある日「なぜ Puffin は Web ページ上のリンクを右クリックしてブックマークに追加すると、リンクのタイトルを取れないのか？」という問題に気づきました。

このタイトルは、<a> タグで囲まれたテキスト、または title 属性の値です。とにかく、ブックマーク追加ダイアログが出てもタイトル欄が空になるので、私はこのバグを直す必要がありました。かなり調べて、スタックを上から追っていくと、原因は Mango（Puffin のブラウザエンジン実体。参考：）から渡されるデータが足りないことでした。解決は難しくなく、Mango と Puffin の間の Protocol に送信データを追加すればよかったのです。

私は嬉しくなりました。Puffin が正常にデータを受け取れるようになり、ブックマーク追加ダイアログにタイトルが表示されるようになったからです。ところが 2 日後、CTO の Sam から「Tiger、そのパッチはサービスを落とす」と言われました。理由は、Puffin と Mango には非常に多くのバージョンが存在するため、protocol を変更するときは後方互換性を考慮しなければならない、というものです。Sam は親切に直してくれましたが、私は冷や汗をかきました。

この出来事は 2 つのことを教えてくれました。1 つ目は、テストは本当に重要だということ。十分なテストがあればこういうミスはすぐ見つかります（ただ、私は開発ブランチで作業していたので、すべての commit で完全なテストを回していたわけではありません）。2 つ目は、後方互換性を考えるのは common sense であるべきなのに、私は未熟で見落としてしまったということです。

本ではテスト駆動開発（Test Driven Development, TDD）が強調されています。私も TDD は良い開発手法だと思います。仕様とロジックを先に固められるし、後からテストが書けずに苦しむ状況に陥りにくいからです。本ではかなり強気にこう言っています。

TDD の利点は 1 つのことを示している。TDD を使わないのは、あなたがまだ十分にプロではないことの証明かもしれない — The Clean Coder

ただし状況に応じて最適解は変わります。何か 1 つの法則が絶対、というわけではありません。

テストは継続的インテグレーション／継続的デリバリー（CI/CD）の流れに組み込まれることが多く、より広い意味では運用（DevOps）の一部です。単体テスト、統合テスト、受け入れテスト、品質テストなど、様々な種類があるので、興味のある方は自分で調べてみてください。

練習

経験を積むほど、簡単なものを書く機会は減りがちです。たとえば Quick Sort をどう書くか。面接のために LeetCode を解き、就職したら忘れる—大学の試験対策と同じです。

こういう「軽い練習」は、手触りやひらめきを保つのに役立ちます。正直、この文章を書いている今、15 分でバグのない Quick Sort を書けと言われたら、かなり苦戦すると思います。概念は覚えていても、手が鈍っているからです。

As the saying goes: “Practice makes you better"

また、小さなプロジェクトをたくさん書くのも良いと思います。CS の学生は Compiler、OS、Computer Architecture を履修していても、完全なシステムを自分で作ったことがない人が多いです。原理だけ分かっていて手を動かしていないなら、実質「できない」に近いこともあります。現実は厳しく、実務のほうが難しいからです。

「自分はもう十分速く書ける」と思う人が多いが、それは「もっと速くなりたい」と思っていないだけだ。

Jim Huang（jserv）が講演でその場で Live Coding しているのを見たことがあるでしょうか。私は Live Coding は本当に難しいと思います。プログラミングは創作であり、ひらめきや醸成が必要です。しかし他人が速く、しかも良く書けるなら、私たちも練習すればできるはずです。

時間・見積もり・計画

誰でも時間は有限です。効率が悪いなら、時間配分や仕事のやり方を見直す必要があります。ポモドーロ・テクニックは良い方法かもしれません。一定時間集中して作業し、少し休む、を繰り返します。人間の精神と体には限界があるので、過度な残業や睡眠不足は良い戦略ではありません。

会議はコストが高い行為です。会社は全員を雇うために多額の費用を払っています。会議の価値が開発時間を奪うコストより小さいなら、完全に無駄です。Agile や Scrum など参考になる方法もありますし、自分が義務として出るべき会議、または価値のある会議だけに出るべきです。

見積もりは約束です。誰かに「Yes」と言ったなら、期限内に成果を出す責任が生まれます。もちろんバッファを取ることもできます。たとえば 2σ くらい余裕を見れば、99% うまくいく確率を確保できます。

設計と計画

Junior / Senior / Lead を区別する方法の 1 つは、開発の計画と見積もりの能力でもあります。

  • Junior は開発時にどこから計画すれば良いか分からず、思いついた順に進めがち。
  • Senior は良い計画を持ち、タスクをステップに分解し、設計書を作ることもでき、重要度の判断ができる。
  • Lead は Senior の特性を含みつつ、プロジェクトを秩序立てて回し、換位思考ができ、チーム全体を会社にとって有利な立場に置ける。

つまり、エンジニアの違いは「技術をどれだけ知っているか」だけではありません。

チーム協作

フリーランスでない限り、必ずチームで働くことになります。チームには協調開発、責任分担、プロジェクト管理が含まれます。大規模な協調開発に触れる機会がないなら、OSS に貢献してみるのがおすすめです。たとえば Mozilla の ブラウザエンジンは良い練習場で、貢献者は 1,000 人近くいます。大型プロジェクトの開発フローを丸ごと見ることができます。チームの凝集力は結局、コミュニケーション、コミュニケーション、そしてコミュニケーションです。コミュニケーションは芸術であり、どんなプロでも持つべきスキルです。

指導（メンタリング）

最後に、あらゆるシニアエンジニアは、より経験の浅いエンジニアを支え、指導すべきです。プログラマは工芸の徒弟のようなもので、学び続けて成長します。良いメンターは成長を加速し、多くの遠回りを減らし、心の中に目標となる像を作ってくれます。私たちも誰かに助けられてきたのだから、後輩を熱心に助けるべきです。

まとめ

本記事では『The Clean Coder』の要点を整理し、私自身の経験から多くの解釈を加えました。私はいくつかの会社に在籍し、多くのエンジニアを見て、様々な文化を経験してきました。業界経験は長くありませんが、それでもこの本には強く共感しました。私の見解が誰かの役に立てば嬉しいです。

では私は Junior エンジニアでしょうか？本記事の観点から言えば、はい。私はまだ駆け出しで、成長の道はまだまだ長いです。