■ 1. "The Joel Test: 12 Steps to Better Code" by Joel Spolsky (2000)
- 著者の評価: Joel Spolskyは史上最高のソフトウェアブロガー
- 12の質問:
- ソース管理を使っているか
- ワンステップでビルドできるか
- 毎日ビルドしているか
- バグデータベースがあるか
- 新しいコードを書く前にバグを修正しているか
- 最新のスケジュールがあるか
- 仕様書があるか
- プログラマーには静かな作業環境があるか
- お金で買える最高のツールを使っているか
- テスターがいるか
- 新しい候補者は面接中にコードを書くか
- 廊下でのユーザビリティテストを行っているか
- メタポイント: 質問そのものではなく「雇用主は開発者を尊重しているか」を問うている
- 評価基準: 雇用主が開発者の時間と集中力を、安い賃貸料や短期的な納期よりも優先しているかを評価
- 時代背景: ドットコムブーム最盛期に発表され、スキルのある開発者が貴重なリソースであることをまだ誰もが認識していなかった
- 影響: キャリアを通じてJoel Testでスコアの高い雇用主を探し、その地図を与えてくれたJoelに感謝している
■ 2. "Parse, don't validate" by Alexis King (2019)
- 主題: Haskellの型システムを活用する技法だが、静的型をサポートする言語(Go、C++、Rust)で応用可能
- 核心的アイデア: データを検証するときは常に新しい型に変換すべき
- ナイーブな解決策の問題:
- コードがデフォルトで安全でない
- すべてのユーザー名を検証することを覚えておく必要がある
- 誤って検証せずに処理するコードパスを作りやすい
Alexisの解決策:
- カスタム型Usernameを使用
- parseUsername関数のみがUsernameを作成でき、返す前に検証ルールを適用
- Username インスタンスがあれば、それは有効なユーザー名を含んでいる必要がある
- 信頼できない入力は常にstringであり、Username を期待する関数にstringを渡すことはできない
影響: 型システムがアプリケーションのセキュリティと信頼性を向上させる上でいかに価値があるかを理解した
■ 3. "No Silver Bullet" by Fred Brooks (1986)
- 出典: 『人月の神話』に収録されたエッセイ
- 二つの複雑性:
- 本質的複雑性(Essential complexity): ツールやハードウェアに関係なく絶対にしなければならない作業(例:営業担当者のボーナス計算式の定義とエッジケースの処理)
- 偶発的複雑性(Accidental complexity): それ以外のすべて(メモリリーク対応、コンパイル待ち、サードパーティライブラリの使い方の理解)
- 結論: ツールやハードウェアの進歩が開発者の生産性を10倍向上させることは不可能
- 偶発的活動をゼロ時間に縮小しても、それが全作業の9/10以上でない限り、桁違いの改善は得られない
- ソフトウェア構築の難しい部分: 仕様、設計、この概念的構造のテストであり、それを表現し表現の忠実性をテストする労働ではない
- ノーコードプラットフォームへの安心感: プラットフォームは偶発的複雑性に焦点を当てており本質的複雑性には対応できないため、開発者を置き換えることはできない
- 現代AIの挑戦: AIは実際に本質的複雑性を減らすため、Brooksの理論に疑問を投げかけている。AIは不完全または矛盾した仕様を受け取り、類似の仕様から隙間を埋めることができる
■ 4. "Choices" by Joel Spolsky (2000)
- 主題: ユーザーインターフェースの作成とユーザーに力を与える際の微妙なコスト
- 核心的原則: オプションを提供するたびに、ユーザーに決定を求めている。一般的に、人々が下さなければならない決定の数を最小限に抑えるべき
- Windows 98の例: ヘルプドキュメントを検索しようとすると、データベース最適化に関する情報のない決定を求める馬鹿げたダイアログが表示される
- 問題点: ユーザーがヘルプを得ようとしているときに中断し、決定を回避してユーザーに押し付けている
- 応用範囲: グラフィカルユーザーインターフェースだけでなく、コマンドライン、他の開発者が書いた関数の呼び出しなど、どこでも考慮すべき
- 問いかけ: ユーザーが気にすることに対する力を与えながら、ユーザーに代わって有用な決定を下すことができるか
■ 5. "Application compatibility layers are there for the customer, not for the program" by Raymond Chen (2010)
- 著者: Microsoft Windowsチームで最も長く勤めている開発者の一人
- 顧客からの要求: Windows XP用に設計されたプログラムがVistaで問題が発生するが、XP互換モードに設定すると正常に動作する。インストーラーを変更してVistaで自動的にXP互換モードで実行されるようにするにはどうすればいいか
- Raymondの比喩: 「普段はペットショップの前の歩道にゴミを捨てている。毎朝、開店時に誰かがゴミを掃除してくれる。しかし日曜日はペットショップが開いていないので、ゴミはそのまま。日曜日もペットショップを開けてもらうにはどうすればいいか？」
- 著者の評価: 比喩は面白いが、Raymondは実際には間違っている。1回のリリース後にアプリを壊さないことを期待する開発者を嘲笑っている
- 教訓: ユーザーの行動に影響を与えることについての優れたレッスン。ユーザーを助けるために何かをしてもらいたい場合、ユーザーの視点から最も抵抗の少ない道を慎重に考える必要がある
■ 6. "Don't Put Logic in Tests" by Erik Kuefler (2014)
- 著者の衝撃: 単体テストを愛していたのに、このエッセイでキャリア全体を通じてひどいテストを書いていたことが明らかになった
- 従来のアプローチの問題: テストコードを本番コードのように扱い、冗長性を排除するためにヘルパー関数、変数、ループを追加していた
- 新しい認識: テストコードと本番コードは全く異なる目標と制約を持つ
- 良いテストコードの特徴: 何よりも明確であるべき。テストコードには独自のテストコードがないため、正確性を確認する唯一の方法は目視検査。読者にどのような動作をアサートしているかを一目瞭然にすべき
- 許容されるトレードオフ: この目標のために、複雑さを減らすために冗長性を受け入れることができる
■ 7. "A little bit of plain Javascript can do a lot" by Julia Evans (2020)
- 著者の背景: キャリアの最初の10年間はデスクトップアプリとバックエンドサーバーのコードのみを書き、2017年までHTMLやJavaScriptに取り組まなかった
- 当初の印象: JavaScriptは10日間でハックされた言語で、ブラウザごとに動作が大きく異なる。モダンで洗練されたフレームワークが必要
- 試したフレームワーク: Angular、React、Vue。Vueを学んだが、依存関係の問題やフレームワークの落とし穴に膨大な時間を費やした
- Juliaのエッセイの影響: JavaScriptを修正する必要があると確信していたが、実際に試したことがなかった
- プレーンJavaScriptの実験: TinyPilotのプロトタイプでVueを使う予定だったが、プレーンJavaScriptでどこまで行けるかを試した(フレームワークなし、ラッパーライブラリなし、ビルドステップなし、Node.jsなし)
- 結果: フレームワークに切り替える必要がある問題に遭遇することを期待していたが、決して起こらなかった
- フレームワークからの自由: ランタイムエラーが発生したとき、スタックトレースはminify・変換されたものではなく、書いたコードそのものをデバッグできる
- バイアスの誤り: JavaScriptに対するバイアスは間違っていた。モダンJavaScriptは素晴らしく、ラッパーライブラリから多くのアイデアを吸収したため、もはやラッパーは不要
- 2020年以降: JavaScriptフレームワークやビルドステップを新しいプロジェクトに統合しておらず、振り返ったことはない。プレーンJavaScriptでフレームワークの利点の90%を頭痛の5%で得られる
■ 8. "Choose Boring Technology" by Dan McKinley (2015)
- 特異性: 実際には読んだことがない。人々がこのエッセイを引用し、アイデアを理解したら直感的に感じたため、読む必要がなかった
- Danの議論: 新しいプロジェクトを始めるとき、話題性のある最先端技術を使いたくなる誘惑がある。Googleが発表した新しいデータベースはexabytesまでスケールし、Postgresより40%速く、コストは20%
- 実際の問題: 新しい技術にはバグと弱点があるが、まだ明らかではない。遭遇したときに行き詰まる。Postgresには30年の実績があり、遭遇する可能性のあるあらゆる問題に対して実証済みのソリューションがある
- 戦略的使用: 新しい技術を時々使うべきだが、戦略的かつ限定的に。すべてのビジネスは3つの「イノベーショントークン」を得る。派手な新しいデータベースが欲しければ、トークンの1つを使う必要がある
- Juliaのエッセイとの相乗効果: フロントエンドフレームワークで時間を無駄にする前にどちらかを読んでいればよかった
■ 9. "I've locked myself out of my digital life" by Terence Eden (2022)
- 著者: 楽しくて折衷的なテクノロジーブロガー
- シナリオ: 雷が家を直撃し、すべての所有物が破壊されたらどうなるか。パスワードマネージャーにすべてのパスワードを保存しているが、すべてのデバイスが破壊されたらアクセスできない。ハードウェアパスキーも家の中にあった
- 従来の安心感: 冗長ドライブにすべてを保存し、3大陸2ベンダーでオフサイトバックアップがあるため安全だと感じていた
- 新しい認識: すべてのデバイスを同時に破壊する可能性のある多くの信頼できる脅威:火災、洪水、電気サージ、刑事捜査。すべてのデータは頭の中にあるパスワードで暗号化されているため、記憶喪失、無能力化、死亡も追加される
- オンラインサービスの問題: ユーザーが災害から回復するのを助けるのが下手。多くのサービスは、電話、メールアカウント、所有するすべてのデジタルデバイスを失うことは不可能だと仮定している
- 影響: どのサービスとデバイスが重要か、Terenceが説明したシナリオからどのように回復できるかを考えるようになった。次にラップトップを購入したとき、家のデバイスなしでパスワードマネージャーと重要なアカウントへのアクセスを回復できるかをテストするために図書館でセットアップした
■ 10. Bonus: Brad Fitzpatrick on parsing user input (2009)
- 出典: Joel Spolskyの絶賛レビューの結果読んだ『Coders at Work』(優秀なプログラマーへのインタビュー集)
- Brad Fitzpatrick: LiveJournal、Memcachedの作成者。当時28歳で本の中で最年少、最も汚い言葉を使う最も面白いプログラマー
- ソフトウェアエンジニアリングの倫理についての質問に対する熱烈な暴言: 「クレジットカードフォームで誰もがスペースやハイフンを入れられるようにして欲しい。コンピューターはそんなクソを削除するのが得意なんだ。数字のフォーマット方法を俺に指示するな」
- 思い出すタイミング: ウェブフォームに電話番号を貼り付けようとしたとき、括弧やスペースが許可されていないと文句を言われる。または、括弧のために電話番号が切り捨てられ、括弧が許可されていないと文句を言われる
- Brad Fitzpatrickの声: ソフトウェアで入力フィールドを作成し、予期しない文字について考えるとき、「コンピューターはそんなクソを削除するのが得意なんだ」というBrad Fitzpatrickの声が聞こえる