ハクソク

世界を動かす技術を、日本語で。

私を形成したソフトウェアに関するエッセイ

237日前原文(refactoringenglish.com)

概要

  • 著者が20年以上にわたり影響を受けた ソフトウェアブログ の名エッセイ集
  • 各エッセイが 思考法や実践 をどう変えたかを解説
  • Joel Spolsky や Fred Brooks など著名人の名文が中心
  • 型システムやUI設計、テストコードの考え方など多岐にわたるテーマ
  • 各エッセイの 要点と学び を日本語で簡潔にまとめて紹介

20年で思考を変えたソフトウェアブログ・エッセイ集

  • 著者が 最初のプログラミング職 に就く前から読み続けてきた、印象的なソフトウェアブログのリスト
  • 数千本読んだ中で、 記憶に残り、考え方を変えた 少数のエッセイを厳選
  • それぞれのエッセイが、 実際の仕事やキャリア選択 にどう影響を与えたかを解説

「The Joel Test: 12 Steps to Better Code」by Joel Spolsky (2000)

  • Joel Spolsky はソフトウェアブログ界の巨匠
  • 「Joel Test」は 開発チームの成熟度 を測る12の質問リスト
    • ソース管理の有無、1ステップビルド、デイリービルド、バグDB、バグ修正優先、最新スケジュール、仕様書、静かな作業環境、最良のツール、テスター、面接時のコーディング、廊下ユーザビリティテスト
  • 質問自体よりも、「 雇用主は開発者を尊重しているか」というメッセージが重要
  • 著者はキャリアを通じて Joel Testのスコアが高い会社 を選択
  • 開発者重視文化 の指標として今も役立つ指針

「Parse, don’t validate」by Alexis King (2019)

  • Haskellの型システムを活用した バリデーション手法 の提案
  • ポイントは「 バリデーション時に新しい型へ変換」すること
    • 例：UsernameのバリデーションはparseUsername(raw string) (Username, error)で行い、以降は Username型 のみ扱う
    • これにより「 未検証データの混入防止」が可能
  • Go, C++, Rust等の 静的型付き言語 でも応用可能
  • 型システムが セキュリティ・信頼性向上 に大きく寄与することを実感

「No Silver Bullet - Essence and Accident in Software Engineering」by Fred Brooks (1986)

  • ソフトウェア開発には「 本質的複雑性」と「 偶発的複雑性」が存在
    • 本質的複雑性：仕様や設計など 絶対に必要な作業
    • 偶発的複雑性：ツールやハード依存の 余計な手間
  • ツール改善だけでは 生産性10倍向上は不可能 と主張
  • ノーコードやAIの登場にも 本質的複雑性の重要性 は不変
  • AI時代でも「 仕様策定や設計の難しさ」は人間が担う必要性

「Choices」by Joel Spolsky (2000)

  • ユーザーインターフェース設計 における「選択肢」のコストを解説
  • 選択肢を増やすほど「 ユーザーの負担・思考コスト」が増加
  • 例：Windows 98のヘルプ検索ダイアログは 不要な決断を強いる悪例
  • 「 本当に必要な選択肢だけを残す」という発想はCLIやAPI設計にも応用可能

「Application compatibility layers are there for the customer, not for the program」by Raymond Chen (2010)

  • Windowsの 互換モード に関する顧客対応エピソード
  • ユーザー行動を変えたい場合、「 最も簡単な解決策」が選ばれることを前提に設計
  • ユーモア溢れる比喩で「 現状維持バイアス」の強さを説明
  • ユーザーに 望ましい行動を促す設計 の重要性

「Don’t Put Logic in Tests」by Erik Kuefler (2014)

  • テストコードに ロジックやヘルパー関数を入れることの危険性 を指摘
  • テストは「 一目で意図が分かる明快さ」が最優先
  • 冗長でも 可読性・検証性重視 のテスト記述が望ましい
  • プロダクションコードと テストコードの設計思想の違い を明確化

「A little bit of plain Javascript can do a lot」by Julia Evans (2020)

  • JavaScriptの シンプルな活用 の有用性に目覚めた体験
  • 複雑なフレームワークに頼らず、 素のJSで十分なことが多い と実感
  • 初心者にも優しいアプローチ として推奨

まとめ

  • 20年のキャリアで出会った 名エッセイ は、技術だけでなく 考え方や価値観 にも大きな影響
  • 型システム、UI設計、テスト、ユーザー行動 など幅広い学び
  • ソフトウェア開発における 本質的な洞察 を得るための必読リスト

Hackerたちの意見

「Parse, don't validate」って論文は、個人的にはクラシックだと思う。『テストにロジックを入れない』って意見には反対なんだけど、例に挙げられているのはURIタイプが必要なところで文字列を使う問題だよね。私が反対する理由は、テストコードは本番コードだと思ってるから。自動ビルド中にテストスイートが失敗すると、望んでいるデプロイが止まっちゃうからね。それでも、どちらも深く掘り下げて、自分に合った適用方法を見つける価値はあるよ。

└

「Parse, don't validate」って論文は、個人的にはクラシックだと思う。そうそう、話すプログラマーの90%がこれを知らないってのが本当に不思議だよ。私の周りはGo/Python/C++の人が多いから、関数型プログラミングの界隈ではもっと知られてるのかも。 >『テストにロジックを入れない』って意見には反対で、例に挙げられているのはURIタイプが必要なところで文字列を使う問題だよね。私が反対する理由は、テストコードは本番コードだと思ってるから。自動ビルド中にテストスイートが失敗すると、望んでいるデプロイが止まっちゃうからね。うん、それは公平な批判だと思う。例の具体的な部分はもっと良くできたかもしれないけど、重要なメッセージは、文字列の連結のように一見シンプルなものでも、テスト内のバグを隠す複雑さを加えるってことだよね。

└

私にとって、テストに（あまり）ロジックを入れないっていうのは魅力的だと思う。テストロジックにバグがあって偽陽性になるテストは、何度も見てきたから、偽の自信信号になっちゃう。テストのためのテストを持つ必要はないはずだよ。とはいえ、そんなことはあまり起こらないけど、最近はLLMによって書かれた明らかにひどいテストが増えてるのを見かける。ランダムな数生成器に頭を完全に委ねている人たちに対して、哲学を責めるのは難しいよね。

これは私にとっての転機だったな： https://stevemcconnell.com/articles/software-quality-at-top-... マコーネルはここでは特に人気がないけどね。

└

共有してくれてありがとう！その論文は読んでなかったけど、キャリアの初めに『Code Complete』を読んで、すごく好きだった。ずっと本棚に置いてあるけど、何回かしか読み返してない。でも、毎回「これ本当にいいな！再読しよう！」って思うんだ。彼がどうなったのか気になってたんだけど、彼の時代に人気だった人たち（ケント・ベック、マーチン・ファウラー、ウォード・カニンガム）はみんな書き続けてるのに、マコーネルのは全然見なかったから。結局、彼はソフトウェアを辞めてファイナンシャルアドバイザーになったらしいけど、これには驚いたよ。[0] [0] https://raindogllc.com/steve-mcconnell-investment-advisor/

脱線だけど、これはエッセイ以上のもので、私のCSSに対する視点を根本的に変えた https://every-layout.dev を紹介しなきゃ。

「グラグ脳の開発者」はいつも頭に残るけど、リストには入ってなかった（公平に言うと、私がすでに同意していたからかもしれないけど、考え方を変えたわけではない）。 https://grugbrain.dev/

└

バイリンガルで英語が母国語でない私にとって、グラグ脳は特に読みづらくて理解しづらい。例えば「グラグ」って何を意味するのか全然わからない。でも、ブログ自体は楽しんでるよ。

└

すごくいいね！これが気に入ったよ：

「グルグ、複雑さの悪魔がクリスタルにしっかり閉じ込められた時、宿敵を捕まえるのが一番の気持ちだ！」

「デジタルライフから自分を締め出してしまった」という記事を読んだんだけど、俺が抱えてる心配事をうまく説明してくれてる。

「退屈なアナログの世界では、自分が言ってる通りの人間だって説得できる自信がある。だから、アカウントにアクセスできるはずだ。裁判所に行って会社にアクセスを戻してもらうよう強制する必要があるかもしれないけど、それは可能だ。」 「でも、無敵のアルゴリズムで守られていると、運が悪い。正しい認証情報がない限り、どんなに頼んでも無理だ。俺のパスワードマネージャーを提供している会社は、俺のパスワードにアクセスできない。説得する相手がいない。コードが法律なんだ。プロセスの対面版をなくすことを主張する前に、みんなこの問題を理解すべきだ。」 この記事の例は最初はあり得ないように思えるけど、自然災害や強盗でも同じ結果が起こり得るよ。

└

誰もこれを支持してるとは思わないし、AIだけの問題じゃないよね（ルールがたくさんあるソフトウェアも同じ問題を抱えてる）。EUは、どんな決定でも必ず人にエスカレーションする権利を法律に盛り込むところまで行ったんだよ。

  1. ナンシー・レヴェソンのTherac-25の調査とレビュー。 * Therac-25事故の調査 https://cse.msu.edu/~cse470/Public/Handouts/Therac/Therac_1.... * Therac-25: 30年後 https://ieeexplore.ieee.org/document/8102762
  2. チャールズ・フィッシュマンの「彼らは正しいものを書く」 https://www.eng.auburn.edu/~kchang/comp6710/readings/They%20...

この系統でお気に入りなのは、ニール・W・リッカートの「二人のプログラマーの寓話」。要点がうまくまとめられてる。 https://c00kiemon5ter.github.io/code/philosophy/2011/10/30/T...

└

ハハ…ニールとはcomp.ai.philosophyのUsenetニュースグループで何年もやり取りしてたから、彼のことはよく知ってる…まさに彼らしいね。

ソフトウェアエッセイとして考えられるかは分からないけど、パトリック・マッケンジーの「プログラマーと呼ばないで、その他のキャリアアドバイス」は金の山だと思う。 https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

フレッド・ブルックスの「銀の弾丸はない」については、この結論には反対だな。

「現代のAIはブルックスの理論にひねりを加えた。実際、必須の複雑さを減らすからだ。AIに不完全または矛盾した仕様を渡すと、AIは似たような仕様から隙間を埋めてくれる。必須の部分は依然として生成AIでは十分にカバーされていないし、たぶんこれからもそうだ。」 ここに俺の詳しい書き込みがあるよ： https://smartmic.bearblog.dev/no-ai-silver-bullet/

セマンティック圧縮[0]は俺に本当に影響を与えた。0: https://caseymuratori.com/blog_0015