- 長く使い続けられるプログラムを選び、信頼できるインフラを構築する方法について語ってきたが、それでも自分はまだそれをうまくできていないと認めている
- この2年間使ってきたプログラムの中核をこの1か月で書き直し、それを通じてこれまでの人生におけるプログラミングの変化を振り返る
2015年
- 抽象化を疑い、テストとバージョン管理を重視していた
- 抽象化の乱用とテスト／バージョン管理の不足が問題の原因だと考えていた
- テストとレイヤーを基本的な制約とするプラットフォーム Mu1 を設計した
2017年
- Mu1 を現在の Mu へと作り直し始めた
- 当初は新しいテストとレイヤーのアイデアをすべて使っていたが、徐々に使わなくなった
- Mu には多くのテストがあるが従来型のものであり、レイヤーインフラは移植しなかった
2022年
- Freewheeling Apps の作業を開始
- 最初はテストなしで始めたが、テキストエディタの中核部分については徹底したテストを書いた
- 残りの部分はテストしにくかったが、うまく動作した
2024年
- 1か月前にすべてのテストを削除した
- 他の Freewheeling Apps とのマージコンフリクトを心配していたやり方で、テキストエディタを抜本的に作り直した
- バージョン管理について悩まなくなった
- テストとバージョンを手放したことで、はるかに良いプログラムを作れるようになった
持続可能なプログラミングについての現在の統合的な見解
- 多くの人のために持続可能な形で構築するのは難しすぎるので、そもそも試みないこと
- ほとんどのソフトウェアは、短期的に多くの人へ奉仕しようとするインセンティブにむしばまれている。ロゴが少なく、構築しやすく、依存関係が少なく、自動更新をしないソフトウェアに焦点を当てること
- コンテキストの小さな変化が、プログラムがそのコンテキストにどれだけ適合するかを根本的に変えうる
- 新しいプログラムは、どんな形であれ未知の世界へ向かうことになる。どの方向にせよ、自分が何をしているのか正確には分からないことが多い
- 型、抽象化、テスト、バージョン、状態機械、不変性、形式的解析などは、不慣れな地形で使える道具である
- こうした道具のいくつかは、どうしても過剰に使ってしまう。理想的な使用量は私たちが思っているよりはるかに少ない。使いすぎは技術的負債である
- 文脈への理解が安定したら、プログラムのかなりの部分を捨てて最初からやり直す価値がある
- 書き直す前に、プログラムに求めるすべてのことと、プログラムが扱うべきすべてのシナリオを一度に頭の中へ入れなければならない
- すべてを一度に構築すること
- テストとバージョン管理は、この進化の最後の段階に到達するうえで妨げになる
- テストは懸念を忘れさせ、バージョン管理は過去に執着させる
GN⁺の見解
- プログラムが複雑になりすぎると、8段階目であらゆることを記憶しておくのは不可能になるかもしれない。これはほとんどのソフトウェア、特に2人以上で書かれたソフトウェアに当てはまる
- すべてのソフトウェアが必ずしも9段階目に到達する必要はない。多くの Freewheeling Apps は、初期設計の選択にかかわらず、数人が使うだけでもバグのない状態に安定化できるほど、十分に単純でゆっくり進化する
- 9段階目に到達するうえで、データ中心設計は明らかに有用である。これは盲目的に適用できる道具ではなく、immediate data structure choices を超えて、プログラムがデータへどうアクセスするかという全体像を見るための考え方である
- これらの段階は完全に正しいとは限らない。経験の少ない道具を過小評価している可能性もある
- こうした段階の先にどんな段階があるのか気になる
1件のコメント
Hacker Newsの意見
テストがなければ問題が見えず、問題が消えたように見える
テストとバージョンを捨てたら、より良いプログラムが得られた
最初は著者が間違っていると思ったが、良い洞察がある
バージョン管理と自動テストは現実の問題を解決する
大きなプログラムを書いたりリファクタリングしたりするときは、書いて捨ててまた書くことが重要だ
この記事は混乱している
小さな変更がプログラムの適合性を大きく変えることがある
一人でソフトウェアを作るのと、チームで作るのはまったく違う
2022年にFreewheeling Appsの作業を始めた
小さな変更がプログラムの適合性を大きく変えるという点には同意しない
著者が好きで、Muプロジェクトも好きだ
ソフトウェアエンジニアリングの複雑さに圧倒される