MicrosoftやGoogleでキャリアの大半を過ごしたソフトウェアエンジニアが選ぶ「秀逸なソフトウェアエッセイ10選」

ソフトウェアエンジニアとしてのキャリアの大半をMicrosoftとGoogleで過ごし、2018年からは自らのビジネスを立ち上げたマイケル・リンチ氏は、これまでに数千本ものソフトウェア関連のブログやエッセイを読んできたとのこと。そんなリンチ氏が、「自分を形作ったソフトウェアエッセイ10選」を発表しました。

The Software Essays that Shaped Me · Refactoring English
https://refactoringenglish.com/blog/software-essays-that-shaped-me/

◆1：“The Joel Test: 12 Steps to Better Code” by Joel Spolsky(ジョエル・スポルスキー著『ジョエルテスト：より良いコードを書くための12のステップ』)

ジョエル・スポルスキー氏は史上最高のソフトウェアブロガーの1人だそうで、リンチ氏のソフトウェアへのアプローチに多大な影響を与えたとのこと。そんなスポルスキー氏が提案する「ジョエルテスト」とは、雇用主が自社のソフトウェアチームにどれだけ投資しているのかを自問するための12個の質問をまとめたもの。質問の内容は以下の通りです。

1：ソース管理を使用しているか？
2：ワンステップでビルドを作成できるか？
3：毎日ビルドを作成しているか？
4：バグデータベースはあるか？
5：新しいコードを書く前にバグ修正をしているのか？
6：最新のスケジュールはあるか？
7：仕様書はあるか？
8：プログラマーの労働環境は静かさが保たれているか？
9：お金で買える最高のツールを使っているか？
10：テスターはいるか？
11：新しい採用候補者は面接中にコードを書いているか？
12：廊下のユーザビリティテストを行っているか？

これらの質問の中には時代遅れなものもありますが、重要なのは全体に共通する「開発者を尊重しているのかどうか」「開発者の時間と集中力を優先しているかどうか」といったポイントです。スポルスキー氏が2000年にこのブログを書いた当時、誰もが熟練した開発者が貴重なリソースであることに気付いていたわけではありません。リンチ氏は、「私はキャリアを通じて、ジョエルテストで高得点を獲得した雇用主を探し求めてきました。そして、そのような雇用主を見つけるための地図を与えてくれたジョエル氏に感謝しています」と述べています。

なお、スポルスキー氏のコラムは「Joel on Software」という書籍にもなっています。

◆2：“Parse, don’t validate” by Alexis King(アレクシス・キング著『解析せよ、検証するな』)

このエッセイではHaskell型のシステムを活用してデータを検証する際、必ず新しいタイプに変換する必要があるということを説明しています。たとえばアプリのユーザー名を登録するシステムで、悪意のあるユーザーがユーザー名フィールドに悪意のあるコードを埋め込んだり、数十億文字もの文字列を埋め込んでサーバーリソースを枯渇させたりする事例が考えられます。関数を使ってデータを変換することで、こうした悪意のある行為から保護することが可能だとのこと。リンチ氏は、「このエッセイを読んで、コンパイラの機能がアプリケーションのセキュリティと信頼性の向上にどれほど役立つかに気づきました」とコメントしました。

(PDFファイル)◆3：“No Silver Bullet - Essence and Accident in Software Engineering” by Fred Brooks(フレッド・ブルックス著『銀の弾丸はない ― ソフトウェア工学の本質と偶然』)

このエッセイでは、ソフトウェア開発における作業を「本質的な複雑さ」と「偶発的な複雑さ」の2つのカテゴリーに分類しています。「本質的な複雑さ」とは、ツールやハードウェアの種類に関係なく、対に実行しなければならない作業のことです。たとえば「営業担当者のボーナスを計算するソフトウェア」を作成する場合、ボーナスの計算式を定義し、あらゆる極端なケースを網羅する必要があります。これはツールやハードウェアに関係なく必要な作業です。

一方で「偶発的な複雑さ」は、メモリリークへの対処やコードのコンパイル待ち、サードパーティ製ライブラリの使い方の検討など、その他すべての作業を指します。ツールとハードウェアリソースが充実すればするほど、偶発的な複雑さに費やす時間は減ります。

これらの前提を踏まえて、ブルックス氏はツールやハードウェアがいかなる進歩を遂げようとも、開発者の生産性を10倍に向上させることは不可能であると結論付けました。現代のコード生成AIはこの主張に疑問を投げかけていますが、リンチ氏は「AIが私たちの知っているプログラミングを排除したとしても、ブルックス氏のエッセイを読めば、どんなレベルの抽象化であっても本質的な複雑さを管理する人間は依然として必要になるだろうという希望が湧いてきます」と述べています。

◆4：“Choices” by Joel Spolsky(ジョエル・スポルスキー著『選択』)

このエッセイはユーザーインターフェースの作成と、ユーザーに権限を与えることによる微妙なコストについて論じたものです。スポルスキー氏は「選択肢を提供するたびに、ユーザーに決断を求めていることになります。 つまり、ユーザーは何かについて考え、決断を下さなければなりません。これは必ずしも悪いことではありませんが、一般的には、ユーザーが下すべき決断の数を最小限に抑えるよう常に努めるべきです」と述べ、ユーザーインターフェースではユーザーにかける負担を最小限にするべきだと主張しました。

リンチ氏は、「ジョエル氏のエッセイはグラフィカルユーザーインターフェースに焦点を当てていますが、コマンドラインや他の開発者が私が書いた関数を呼び出す時など、人々が私のコードに触れる可能性のあるあらゆる場面で、私はこのことを考えています」「ジョエル氏のエッセイのおかげで、自分で判断できる決定をユーザーに押し付けてしまうという事態を回避できたことが数え切れないほどあります」と述べました。

◆5：“Application compatibility layers are there for the customer, not for the program” by Raymond Chen(レイモンド・チェン著『アプリケーション互換性レイヤーはプログラムのためではなく、顧客のために存在する』)

レイモンド・チェン氏はMicrosoft Windowsチームで最も長く在籍している開発者の1人であり、ブログにはWindowsにおけるプログラミングの歴史に関する有益な記事が多数あります。特にリンチ氏にとって思い出深いのが、Windows Vistaの互換モードに関するこの記事だとのこと。

あるユーザーがチェン氏に対し、「元々Windows XPとWindows Server 2003向けに設計されたプログラムがあり、これがWindows Vistaだと動作に問題が発生してしまう。しかし、プログラムをWindows XP互換モードに設定すると問題なく機能する。ユーザーがWindows Vistaで実行した際に自動的にWindows XP互換モードで動作させるには、インストーラーにどのような変更を加える必要があるのか？」と尋ねました。

チェン氏はこのユーザーの要望について、「普段はペットショップの前の歩道にゴミを捨てているのだが、毎朝開店すると誰かがゴミを掃き集めてゴミ箱に捨ててくれる。でも日曜日はペットショップが開いてないので、ゴミがそのまま放置される。どうすれば日曜日もペットショップを開いてもらえるだろうか？」と言っているようなものだと主張しています。リンチは、チェン氏の具体的な主張には同意できないもののこの比喩は面白く、ユーザーに行動を促す上でのヒントになるとしています。

◆6：“Don’t Put Logic in Tests” by Erik Kuefler(エリック・クーフラー著『テストにロジックを入れるな』)

クーフラー氏はエッセイで、プログラムの単体テスト(ユニットテスト)を行う際のテストコードに演算子を追加したりループや条件文を含めたりすると、微妙なバグが覆い隠されてしまうことがあると指摘。テストコードは製品コードと異なり、柔軟性よりもシンプルさが重要であるため、入出力のペアを計算するロジックを入れるのではなく、具体的に記述するべきだと主張しています。リンチ氏は自らのテストコードに自信を持っていましたが、クーフラー氏のエッセイを読んで、自分がキャリアを通してひどいエッセイを書いてきたことに気付いたとのこと。

リンチ氏は、「エリック氏のエッセイを読んで、テストコードを本番コードのように扱うべきではないことがわかりました。テストコードと本番コードは目的も制約もまったく異なるのです。優れたテストコードは、何よりも明確でなければなりません。テストコード自体には独自のテストコードがないため、正確性を検証する唯一の方法は検査することです。テストは読者にとって、それがどのような動作を表明しているかが一目瞭然でなければなりません。この目標を達成するために、複雑さを軽減して冗長性を受け入れることは可能です」と述べました。

◆7：“A little bit of plain Javascript can do a lot” by Julia Evans(ジュリア・エヴァンス著『少しのシンプルなJavaScriptで多くのことができる』)

リンチ氏はキャリア最初の10年間でデスクトップアプリとバックエンドサーバーのコードしか書いておらず、HTMLやJavaScriptに手を出したのは2017年からだったとのこと。 フロントエンド開発を本格的に学び始めた当初、リンチ氏はJavaScriptについて「ブラウザによって挙動が異なる雑多な言語」という印象を抱いており、その欠点を改善するべくさまざまなJavaScriptフレームワークに手を出していました。

しかしエヴァンス氏のエッセイを読んでJavaScriptの可能性を知り、試しにフレームワークやビルドステップ、Node.jsなどを使わずにJavaScriptのみでプログラミングを試してみたところ、意外にもフレームワークに手を出していた時よりもうまくいったそうです。

リンチ氏は、「JavaScriptに対する私の偏見は間違っていました。現代のJavaScriptはかなり優れています」「ブラウザはプラットフォームやデバイス間で一貫した動作を保証するために、しっかりと機能しています。2020年以降、新しいプロジェクトにJavaScriptフレームワークやビルドステップを統合したことはなく、一度も後悔したことがありません」と述べています。

◆8：“Choose Boring Technology” by Dan McKinley(ダン・マッキンリー著『退屈なテクノロジーを選ぶ』)

実はリンチ氏は、このエッセイを実際に読んだことはなく、引用されたのを目にしただけだそうです。しかし、エッセイの考えは非常に直感的に理解できたため、読む必要がなかったとしています。マッキンリー氏の主張は「新しいプロジェクトを始めると話題の最先端技術を使いたくなるが、新しいテクノロジーにはバグや弱点があり、それに遭遇すると行き詰まっていまう」というものです。一方、使い古されたテクノロジーは退屈ではあるものの、遭遇する可能性があるさまざまな問題に対するソリューションがすでに存在するため、開発時に行き詰まるリスクを減らすことができるというわけです。

◆9：“I’ve locked myself out of my digital life” by Terence Eden(テレンス・イーデン著『デジタルライフから締め出されてしまった』)

イーデン氏は多岐にわたるテクノロジーについて著わしてきたライターですが、リンチ氏が特に感銘を受けたのがこのエッセイだとのこと。この記事でイーデン氏は、「もし自宅に雷が落ちて持ち物がすべて破壊されたらどうなるのか」という思考実験を行い、あらゆるパスワードを保存するパスワードマネージャーにアクセスできなくなったら、何もできなくなってしまうという結論に至りました。

リンチ氏はすべてのデータを大陸をまたがった複数のバックアップ用ドライブに保存しており、データに関して常に安全であると感じていましたが、この記事を読んで「デバイスをすべて同時に消滅させかねないあらゆる脅威」について考えるようになったとのこと。リンチ氏は、「オンラインサービスは、ユーザーが災害から立ち直るのを手助けするのが苦手です。私は携帯電話はもちろん、メールアカウントや所有するあらゆるデジタルデバイスを失うことはあり得ないと想定しているサービスをいくつか利用しています。テレンス氏のエッセイを読んで以来、自分にとってどのサービスやデバイスが重要なのか、そしてテレンスが説明したような状況からどのように回復できるのか、より深く考えるようになりました」と述べています。

◆10：Brad Fitzpatrick on parsing user input(ブラッド・フィッツパトリック氏によるユーザー入力の解析)

これは厳密に言うとエッセイではなく、「Coders at Work プログラミングの技をめぐる探求」という書籍に登場するプログラマーへのインタビューのひとつです。本書のインタビュー対象者の1人として登場したフィッツパトリック氏は、「クレジットカードの申込書に、スペースやハイフンを入れても大丈夫なように、みんなにお願いしたい。コンピューターはそういうのをうまく削除してくれるから。数字のフォーマットをあれこれ指図するなんて、やめてほしい」と率直に述べています。

リンチ氏は、「ウェブフォームに電話番号を貼り付けようとして『カッコやスペースは使えません』と文句を言われるたびに、この言葉を思い出します。あるいはもっとひどいことに、カッコのせいで電話番号が切り捨てられ、その上で『カッコは使えません』と文句を言われるのです。私が自分のソフトウェアで入力フィールドを作成し、予期しない文字について考えるたびに、フィッツパトリック氏の『コンピューターはそういう不要なものを取り除くのが得意だ』という言葉が聞こえてきます」と述べました。