私を形作ったソフトウェアエッセイ集
(refactoringenglish.com)- 20年間で何千本ものソフトウェア系ブログ記事を読んできたが、考え方を根本から変えたエッセイはごく少数であり、Joel Spolskyの「Joel Test」からJulia EvansのピュアなJavaScript擁護まで、10本の重要なエッセイを紹介
- Joel Spolskyの「Joel Test」は、雇用主が開発者を尊重しているかを評価する12の質問を提示し、ソース管理、日次ビルド、バグの優先修正などを通じて、開発者の時間と集中を優先しているかを確認する
- Alexis Kingの「Parse, don't validate」は、データ検証時に新しい型へ変換する手法を紹介し、型システムがアプリケーションの安全性と信頼性向上に寄与できることを示す
- Fred Brooksの「No Silver Bullet」は、ソフトウェア作業を本質的複雑性と偶発的複雑性に分け、ツールやハードウェアの進歩だけでは10倍の生産性向上は不可能だと主張したが、AIはこの理論に変数を投げ込んだ
- Julia EvansのピュアJavaScriptエッセイは、フレームワークなしでもES2018 JavaScriptだけで十分だという気づきを与え、それ以降2020年からはどのプロジェクトにもJavaScriptフレームワークやビルドステップを組み込んでいない
Joel Spolskyの「Joel Test」 (2000)
- Joel Spolskyは史上最高のソフトウェアブロガーであり、彼のエッセイは筆者のソフトウェアへの向き合い方に大きな影響を与えた
- 「Joel Test」は、雇用主がソフトウェアチームにどれだけ適切に投資しているかを評価する12の質問セット
-
12の質問一覧
- ソース管理を使っているか
- 1ステップでビルドできるか
- 毎日ビルドしているか
- バグデータベースを持っているか
- 新しいコードを書く前にバグを修正しているか
- 最新のスケジュールを持っているか
- 仕様書を持っているか
- プログラマーに静かな作業環境があるか
- お金で買える最高のツールを使っているか
- テスターがいるか
- 新しい候補者は面接中にコードを書くか
- 廊下でのユーザビリティテストを行っているか
-
中核メッセージ
- 一部の質問は時代遅れになっているが、重要なのは質問そのものではなく、質問のメタなポイントである
- Joelが実際に問うているのは、開発者を尊重しているか？ ということ
- すべての質問は、雇用主が安いオフィススペースや短期の締め切りよりも、開発者の時間と集中を優先しているかを測るもの
- ドットコムブームの絶頂期に公開され、熟練した開発者が貴重な資源だったにもかかわらず、それを誰もが理解していたわけではない時代だった
- Joelのブログは常にプログラマーを希少で繊細な天才として描き、雇用主が追い求め、大切にすべき存在として提示していた
- 筆者はキャリアを通じてJoel Testで高得点を取れる雇用主を探してきており、その指針を与えてくれたJoelに感謝している
Alexis Kingの「Parse, don't validate」 (2019)
- Haskellの型システム活用に関するエッセイだが、型システムやHaskellに関心がなくてもソフトウェアに対する考え方を根本から変える
- Go、C++、Rustなど、静的型付けをサポートするあらゆる言語でAlexisの手法は使える
-
中核概念
- データを検証するたびに、新しい型へ変換すべきである
- 例: ユーザー名を英数字20文字以内に制限するルールがある場合、素朴な解決策は
validateUsername(username string) error関数になる
-
問題点
- コードが本質的に安全ではない
- 受け取ったすべてのユーザー名を検証しなければならないため、誤って未検証のままユーザー名を処理するコードパスを作ってしまいやすい
- 悪意あるユーザーがそのミスを見つければ、ユーザー名フィールドに悪意あるコードを埋め込んだり、何十億文字も詰め込んでサーバー資源を枯渇させたりできる
-
Alexisの解決策
parseUsername(raw string) (Username, error)関数を使う- コードベースの残りの部分では、「username」という
stringの代わりにカスタム型Usernameを使う Usernameを生成できる唯一の関数はparseUsernameであり、Usernameインスタンスを返す前に検証ルールを適用するUsernameインスタンスを持っているなら、それは有効なユーザー名を含んでいるはずである- 信頼できない入力は常に
stringなので、Usernameを期待する関数にstringを渡すことはできない
-
影響
- このエッセイを読む前は、型システムは言語オタクを気晴らしさせる面白い仕掛けくらいに思っていた
- 「Parse, don't validate」は、コンパイラの機能がアプリケーションの安全性と信頼性を高めるうえでどれほど価値があるかに目を開かせてくれた
Fred Brooksの「No Silver Bullet」 (1986)
- 大学でFred Brooksの The Mythical Man-Month を読んだ
- IBMのOS/360プロジェクトを率いた経験に基づくソフトウェアエンジニアリング・エッセイ集
-
本質的複雑性と偶発的複雑性
- 本質的複雑性: ツールやハードウェアに関係なく、必ず行わなければならない作業
- 例: 営業担当者のボーナス計算ソフトウェアで、ボーナスの計算式を定義し、あらゆるエッジケースをカバーすること
- $5B のスーパーコンピュータでも $1 のマイクロコントローラでも同じ作業
- 偶発的複雑性: それ以外のすべて
- メモリリーク対応、コードのコンパイル待ち、サードパーティライブラリの使い方の把握
- ツールやハードウェア資源が良いほど、偶発的複雑性に費やす時間は減る
- 本質的複雑性: ツールやハードウェアに関係なく、必ず行わなければならない作業
-
Brooksの結論
- ツールやハードウェアの進歩が開発者の生産性を10倍向上させることは不可能
- すべての偶発的作業をゼロ時間にできたとしても、それが総労力の10分の9以上を占めていない限り、その規模の改善は起きない
-
適用例
- キャリアを通じて、人々はソフトウェアからプログラマーを排除しようとしてきた
- ノーコードプラットフォームは、非プログラマーに熟練Web開発者と同等の力を約束して話題を集める
- Brooksのエッセイは、最新のバズワード系プラットフォームが開発者を置き換えることはできないと常に安心させてくれた
- そうしたプラットフォームは偶発的複雑性に焦点を当てており、本質的複雑性には焦点を当てていない
- プラットフォームが機能仕様から魔法のように動くコードを作れたとしても、なお仕様を書く誰かは必要である
-
AIの影響
- 現代のAIはBrooksの理論にレンチを投げ込んだ
- AIは実際に本質的複雑性を減らす
- 不完全または矛盾した仕様をAIに渡すと、AIは類似の仕様から借用して空白を埋める
- AIが既知のプログラミング作業を取り除いたとしても、Brooksのエッセイは、最終的にはどの抽象化レベルであれ本質的複雑性を管理する人が依然として必要だという希望を与えてくれる
Joel Spolskyの「Choices」 (2000)
- 好きなJoel Spolskyのエッセイを1本だけ選ぶのは難しいので、2本選んだ
- 「Choices」は、ユーザーインターフェースの構築と、ユーザーに権限を与えることの微妙なコストについての話
-
中核メッセージ
- 選択肢を提供するたびに、ユーザーに判断を求めている ということ
- それは、ユーザーが何かについて考え、決めなければならないことを意味する
- 必ずしも悪いことではないが、一般には人々が下さなければならない判断の数を最小限にするよう努めるべきである
-
Windows 98の例
- Joelは、Windows 98でヘルプ文書を検索すると表示されるとんでもないダイアログを共有している
- そのダイアログがJoelを激怒させた理由:
- ユーザーが助けを得ようとしているときに中断する
- データベース最適化について十分な情報のない判断を下すよう求める
- Windowsが判断を避け、ユーザーに押しつけている
-
適用範囲
- Joelのエッセイはグラフィカルユーザーインターフェースに焦点を当てているが、筆者はコマンドラインや、自分の書いた関数を呼び出す他の開発者も含め、コードに触れうるあらゆる場所でこれを意識している
- ユーザーの代わりに有用な判断を下しつつ、同時に彼らが関心を持つ部分についてはコントロールを提供できるか
- Joelのエッセイは、自分で下せる判断をユーザーに押しつけることを無数に防いでくれた
Raymond Chenの "Application compatibility layers are there for the customer, not for the program" (2010)
- Raymond ChenはMicrosoft Windowsチームで最も長く勤務している開発者の一人
- ブログには、Windowsプログラミングの歴史に関する有益で面白い話が何千本もある
-
顧客からの依頼事例
- Windows Vistaの互換モードに関する顧客からの依頼:
- Windows XPおよびWindows Server 2003向けに設計されたプログラムがWindows Vistaで問題を抱えている
- Windows XP互換モードに設定すると、Vistaで正常に動作する
- Vistaで実行する際に自動的にXP互換モードで動作するよう、インストーラーにどんな変更が必要かと質問
- Windows Vistaの互換モードに関する顧客からの依頼:
-
Raymondのたとえ話
- 「私はふだんペットショップの前の歩道にゴミを捨てていて、毎朝店が開くと誰かがそれを掃いてゴミ箱に捨ててくれます。でもペットショップは日曜日は開いていないので、日曜はゴミがそのまま残ります。日曜日にもペットショップを開けさせるにはどうすればいいでしょう？」
-
教訓
- たとえ話があまりに面白くて、Raymondが間違っていることに今になって気づいた
- 単一リリースの後はWindowsがアプリを壊さないと期待した開発者の罪をあざ笑っている
- 細部には同意しないが、Raymondの文章はとても面白く鋭いため、欠点を超えて楽しめる
- 優れたユーザー行動への影響に関する教訓:
- ユーザーに自分を助ける行動を取らせたいなら、ユーザー視点での最小抵抗の経路を慎重に考える必要がある
- 歩道にゴミを捨てることで問題が完全に解決すると見せれば、人はそのままそれを続ける
Erik Kueflerの "Don’t Put Logic in Tests" (2014)
- 筆者は昔から単体テストが好きで、テストコードに大きな誇りを持っていた
- このエッセイが不意に現れ、キャリアを通じてひどいテストを書いてきたことを暴き出し、衝撃を受けた
-
問題のあるテストの例
@Test public void shouldNavigateToPhotosPage() { String baseUrl = "http://plus.google.com/";; Navigator nav = new Navigator(baseUrl); nav.goToPhotosPage(); assertEquals(baseUrl + "/u/0/photos", nav.getCurrentUrl()); } -
見つかった問題点
- 初めてこのエッセイを読んだとき、「自分の単体テストの書き方とまったく同じだ！」と思った
http://plus.google.com/という文字列を2か所に重複させる理由は何か？ プロダクションコードのように単一の真実の源を作るべきだと考えていた- 筆者はテストで重複を取り除くために、ヘルパー関数や変数、ループを追加することを常にやっていた
- 問題は、このやり方が微妙なバグを隠してしまうことだ: 実際には
http://plus.google.com//u/0/photosをassertしている（スラッシュが2つ）
-
気づき
- Erikのエッセイは、テストコードをプロダクションコードのように扱うべきではないことを示している
- 両者は目標も制約条件も完全に異なる
- 良いテストコードは何よりもまず明確でなければならない
- テストコードにはそれ自体をテストするコードがないので、正確性を検証する唯一の方法は目視確認だ
- テストは、どの動作をassertしているのかが読者にとって目がくらむほど明白でなければならない
- この目標のためなら、複雑さを減らすために重複を許容してよい
Julia Evansの “A little bit of plain Javascript can do a lot” (2020)
- ソフトウェアエンジニアとして、ウェブの世界に入るのが気恥ずかしいほど遅かった
- キャリア最初の10年間は、デスクトップアプリとバックエンドサーバー向けのコードしか書いていなかった
- 2017年まではHTMLやJavaScriptを気にしていなかった
-
フレームワークに対する誤解
- フロントエンド開発の学習を本格的に始めたとき、JavaScriptは10日で作られたひどい言語で、ブラウザごとに挙動が大きく違うという印象を持っていた
- ウェブアプリを書くには、JavaScriptのあらゆる厄介さや欠点から守ってくれるモダンで洗練された何かが必要だと思っていた
- Angular、React、Vueのような人気ウェブフレームワークを試した
- Vueは十分に学んだが、それでも依存関係の問題やフレームワークの落とし穴に膨大な時間を費やした
- こうしたフロントエンドフレームワークがJavaScriptを直そうとしてあれこれ手を入れたあとでも、ウェブプログラミングは相変わらずひどかった
-
Juliaのエッセイが与えてくれた気づき
- JavaScriptは修正が必要だと信じ込みすぎて、まともにチャンスを与えていなかったと気づいた
- TinyPilotのプロトタイプに取り組んでいて、ウェブインターフェースはVueで実装するつもりだった
- Juliaのエッセイに触発されて、素のJavaScriptでどこまでできるか試すようになった
- フレームワーク、ラッパーライブラリ、ビルドステップ、Node.jsなしで、ただ普通のJavaScript（ES2018）だけを使った
- フレームワークやビルダーに切り替えなければならない問題にぶつかるだろうとずっと予想していたが、結局一度も起きなかった
- WebComponentsまわりの落とし穴はいくつかあったが、VueやAngularで味わった苦痛に比べれば何でもなかった
-
フレームワークのない自由
- フレームワークから解放されるのが気に入っている
- ランタイムエラーが起きたとき、スタックトレースは圧縮・変形・tree-shakingされたコードの悪夢ではない
- 自分が書いたそのままのコードをデバッグできる
- JavaScriptに対する偏見は間違っていた
- 現代のJavaScriptはかなり良くなっており、ラッパーライブラリの多くのアイデアを取り込んだ結果、もはやラッパーは必要ない
- ブラウザ各社は、プラットフォームやデバイスをまたいで一貫した挙動を保証するために本気で取り組むようになった
- 2020年以降、新しいプロジェクトにJavaScriptフレームワークやビルドステップを組み込んだことはなく、まったく後悔していない
- 素のJavaScriptで、フレームワークの利点の90%を、頭痛の5%で得られる
Dan McKinleyの “Choose Boring Technology” (2015)
- このリストに入っているのが奇妙なエッセイである理由は、実際には読んだことがないからだ
- 人々がこのエッセイを引用していて、アイデアを理解したらあまりに直感的だったので、読む必要を感じなかった
-
中核となるアイデア
- 新しいプロジェクトを始めるとき、話題性のある最先端技術を使いたくなる誘惑がある
- Googleがエクサバイト級までスケールする新しいデータベースを発表し、Postgresより40%速く、コストは20%だとする
- そんな魅力的な新しい選択肢が目の前にあるのにPostgresを使うのは愚かに思える
- だが実際には、新しい技術にはバグや弱点があるものの、まだ明らかになっていないだけだ
- それにぶつかると、どうしようもなくなる
- Postgresにも問題はあるが、30年の実地経験を経て、遭遇しうるほぼあらゆる問題に対する実証済みの解決策を持っている
-
イノベーショントークンの概念
- Danは、新しい技術を使うべき場面もあると認めているが、それは戦略的に、しかも限られた数にとどめるべきだとしている
- あらゆるビジネスには、消費できる**3枚の「イノベーショントークン」**が与えられる
- 派手な新データベースが欲しいなら、そのうち1枚を使わなければならない
- DanのエッセイはJuliaのエッセイとも自然に噛み合う
- フロントエンドフレームワークであれだけ時間を無駄にする前に、このどちらかでも読んでいればよかった
Terence Edenの “I’ve locked myself out of my digital life” (2022)
- Terence Edenは愉快で折衷的な技術ブロガー
- 毎週いくつもの新しい記事を書いているが、最も大きな影響を与えたのは「デジタル生活から自分自身を締め出してしまった」
-
災害シナリオ
- 落雷がTerenceの家を直撃し、所有物をすべて破壊したらどうなるかをシミュレーション
- すべてのパスワードをパスワードマネージャーに保管
- すべてのデバイスが破壊されると、パスワードマネージャーにアクセスできない
- ハードウェアパスキーで代替できない理由は、それらも家にあったから
-
気づき
- 筆者は、重複したドライブにすべてを保存し、2つのベンダーを使って3大陸にオフサイトバックアップを置いているので、データについてはかなり安全だと感じていた
- Terenceの記事は、すべてのデバイスを同時に失わせる多くの現実的な脅威について考えさせた。火災、洪水、電気サージ、犯罪捜査などだ
- すべてのデータは頭の中にあるパスワードで暗号化されているので、記憶喪失、無能力化、死亡もその一覧に加わる
-
オンラインサービスの問題
- オンラインサービスは、ユーザーの災害復旧を支援するという点で脆弱だ
- 電話を失うことなどありえないと仮定しているサービスをいくつも使っている。メールアカウントや、所有するあらゆるデジタルデバイスについては言うまでもない
-
影響
- Terenceのエッセイを読んで以来、どのサービスとデバイスが重要か、そしてTerenceが説明したシナリオでどう復旧できるかを、より意識して考えるようになった
- 次のノートPCを買ったときには図書館で設定し、自宅にあるデバイスなしでパスワードマネージャーや重要なアカウントへのアクセスを復旧できるかテストした
- 依然としてデジタル災害への備えをもっと改善できるが、Terenceの記事は、デバイスとデータの安全性について考えるたびに頭の中で反響する
- もしすべてが突然破壊されたら、どうなるだろう？
ボーナス: Brad Fitzpatrickの「parsing user input」（2009）
- 技術的にはエッセイではないが、ソフトウェアのインタビューからの引用を繰り返し考えてしまう
- 2009年にJoel Spolskyが絶賛レビューしていたことをきっかけに、Coders at Work を読んだ
- 成功したプログラマーたちへのインタビューを集めた本
-
Brad Fitzpatrickの名言
- LiveJournalとMemcachedの創設者であるBrad Fitzpatrickが、インタビュー対象の一人として登場する
- 当時28歳で、本の中で最も若いプログラマーであり、最も口が悪くて面白い人物だった
- ソフトウェアエンジニアリング倫理についての質問に対して、入力検証について熱く語った発言:
- 「みんながクレジットカードのフォームで空白やハイフンを入力できるように、一貫してしてほしい。コンピュータはそういうものを取り除くのが得意なんです。 数字をどうフォーマットするかまで指図しないでほしい。」
-
応用
- Webフォームに電話番号を貼り付けようとするたびに、この引用を思い出す
- かっこや空白が許されていないことに文句を言ったり、もっとひどい場合には、かっこのせいで電話番号を切り詰めたうえで、かっこは許されないと文句を言ったりする
- ソフトウェアで入力フィールドを作り、想定外の文字について考えるたびに、Brad Fitzpatrickが**「コンピュータはそういうものを取り除くのが得意なんです」**と言うのが聞こえてくる
3件のコメント
今があるのは歴史があるからです。
Hacker News の意見
"I've locked myself out of my digital life" という文章を読んで、自分が抱えていながらうまく説明できなかった不安を見事に言い表していると感じた
アナログの世界なら、自分が何者かを人間に対して説得して本人確認をしてもらい、アカウントにアクセスできるかもしれないが、デジタル世界の無慈悲なアルゴリズムの前では、認証情報がなければどれだけ懇願しても無駄だ
パスワードマネージャーの会社でさえ、私のパスワードにアクセスする権限を持っていないからだ
説得できる相手すら存在せず、ただコードだけが法になる
あらゆるプロセスから対面の過程をなくそうと主張する前に、この問題を誰もが理解すべきだと思う
記事ではまれな状況のように聞こえるかもしれないが、自然災害や盗難の状況でも十分に起こりうることだ
関連記事: https://shkspr.mobi/blog/2022/06/ive-locked-myself-out-of-my-digital-life/
そしてこの問題はAIだけの問題ではなく、ルールベースのソフトウェアでも同じだ
欧州連合（EU）では、どのような決定に対しても必ず人間に異議申し立てできる権利が法律で保障されている
Grug Brained Developer はいつも頭に残っている文章だが、リストには入っていなかった
実のところ、すでに同意していた内容だったので、考え方を変えたというより単に記憶に残っただけかもしれない
参考: https://grugbrain.dev/
この中では「複雑性の悪魔をついに修正済みのクリスタルに閉じ込めるのが最高の気分だ」という部分が本当に気に入った
私は英語を第二言語として使うバイリンガルなので、grug brain スタイルの文章はかなり読みにくく、理解しづらい
'grug' という単語が何を意味するのかもわからない
それでもそのブログは楽しく読んでいる
Fred Brooks の "No Silver Bullet" の結論には同意しない
最近、AIがBrooksの理論を覆すほど本質的複雑性を減らしたという主張には賛成できない
AIは不完全または矛盾した仕様でも、類似事例を参考にして自動的に補完できるかもしれないが、本質的複雑性は依然としてAIでも十分には解消されず、今後も不可能だと思う
関連する詳細な私の分析はこちら: https://smartmic.bearblog.dev/no-ai-silver-bullet/
読んでくれて、私の文章を共有してくれてありがとう
あなたの解説で触れられていたように、LLMが本質的複雑性を完全になくせないという点には同意する
ただし、LLMは本質的複雑性をある程度減らせるとは思う
実例として、Claude 4.1 Opus にコンピューター生成画像のためのドメイン特化言語の定義を依頼した
私が要件だけを伝え、具体的な部分を曖昧なままにしていても、LLMは仕様を書いてくれた
このような場合、LLMが本質的複雑性を減らしたと確信できる
自分で高品質に新しく定義することもできるが、LLMの出した結果で十分なら、品質向上のために追加の努力を注ぐ理由は少なくなる
もともと私は自分でコーディングするほうが得意で楽しいので、LLMの必要性をあまり感じていなかったが、使ってみると、自分の時間やエネルギーを使わずに済む部分でLLMが本質的複雑性をかなり引き受けてくれる役割を果たしている
例: https://kagi.com/assistant/1b8324a2-ae54-4a1b-9c69-51d76fc5c7d1
AIが減らしてくれる複雑性は、結局のところコードを書く人の認知的負担にすぎない
Brooksが言った「偶有的複雑性（nonessential complexity）」はコード自体にはほとんど残っている
結果として、その負担はコードを読む人に転嫁される
まるで外骨格スーツを着て重い物を棚に載せておき、同僚にそれをきれいに塗装しろと言うようなものだ
"Parse, don't validate" の論文は、私にとって古典的名作だ
そして "Don't put logic in tests" という文言には同意しにくいと感じた
例では文字列の代わりに URI 型を使うべきだという話から出てくる問題だが、私はテストコードもデプロイの成功・失敗に影響する以上、テストコードもまた本番コードとして扱うべきだと思う
ともあれ、こうした議論は自分で検討し、自分に適用できるか考えてみる価値が十分にある
私も "Parse, don't validate" があまり知られていないのは不思議だと思う
私の周りは Go、Python、C++ をやる人が大半なので、関数型言語の界隈でしか有名ではないようだ
"Don't put logic in tests" の例に批判的な見方は妥当だと思う
例はもう少し良いケースに置き換えられるかもしれないが、重要なポイントは、単純な文字列連結でさえテストに複雑性を加え、バグを見逃しやすくしてしまうことだ
個人的には、テストにロジックを（入れすぎ）ないという哲学に魅力を感じる
テストコードのバグのせいで偽陽性（false positive）が発生した経験が何度もあり、こうした部分に不信感がある
「テストのためのテスト」を書く必要を感じるべきではないと思う
実際にはこういうケースはまれだが、最近ではLLMが書いたひどいテストコードが広まりつつあり、この哲学とは無関係に問題はさらに大きくなっている
Nancy Leveson による Therac-25 事故の調査およびレビュー資料を勧めたい
Charles Fishman の They Write the Right Stuff も強く勧める
https://www.eng.auburn.edu/~kchang/comp6710/readings/They%20Write%20the%20Right%20Stuff.pdf
私にとってこの分野でいちばん好きな文章は、Neil W. Rickert の "The Parable of the Two Programmers" だ
プログラマーの人生と挑戦を簡潔に要約した物語だ
https://c00kiemon5ter.github.io/code/philosophy/2011/10/30/Tale-of-two-Programmers.html
Neil とは長年 comp.ai.philosophy Usenet ニュースグループでよく交流していたので、よく知っている
文体や内容が本当に彼らしい
この文章は本当に素晴らしい
私にとってはこの記事が転機だった
https://stevemcconnell.com/articles/software-quality-at-top-speed/
McConnell はここではそれほど有名ではない
この記事は初めて読んだが、私はキャリア初期に Code Complete を読んで大きな感銘を受けた
本棚にずっと置いてあり、何度か読み返すたびに「これは本当に素晴らしい、またちゃんと読み直さなければ」と思っていた
しばらくMcConnellの話を聞かなかったので、Kent Beck、Martin Fowler、Ward Cunningham など同時代の著者たちが2000年代以降に人気が落ちても書き続けていた一方で、McConnellだけ静かだったのが気になっていた
調べてみると、ソフトウェアを離れてファイナンシャルアドバイザーに転じていたことが、地味に衝撃だった
https://raindogllc.com/steve-mcconnell-investment-advisor/
正統派のソフトウェアエッセイとは言いにくいかもしれないが、Gilad Bracha の "Ban on Imports" というブログ記事によって、モジュールシステムに対する私の見方は完全に変わった
import/export はグローバル状態とほとんど同じであり、そのためグローバル状態が抱えるあらゆる問題をそのまま持ち込むのだと強調している
それ以来、依存性注入という考え方をはるかに高く評価するようになった
https://gbracha.blogspot.com/2009/06/ban-on-imports.html
厳密にはソフトウェアエッセイに分類しづらいかもしれないが、Patrick McKenzie の "Don't Call Yourself A Programmer, And Other Career Advice" は真の宝庫だ
https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/
私はプログラミング言語に強い関心がある人間として、"slumming with basic programmers" という文章がとても印象に残っている
https://prog21.dadgum.com/21.html
ユーザー入力のパースには本当に共感します。
代替の電話番号入力機能を開発するかなり多くのコーダーは、いったいどんな環境で仕事をしているから、文字列に
replace()を2回呼び出すことをそこまで恐れるのでしょうか？