記事であまり触れられていない重要なポイントは、時間とともに開発スピードがどう変わるかってことだね。プロジェクトやチームの規模が大きくなると、時間が経つにつれてそのスピードは落ちていく。減少率を最小限に抑えるためには、長期的な速度のために短期的な開発を遅らせるようなことをしなきゃいけないかもしれない。例えば、テストやドキュメント、意思決定ログ、アジャイルのセレモニーなんかがそうだね。初期開発でのいくつかの見落としは、後々長い間ネガティブな影響を及ぼすことがある。例えば、最初からコードに観測可能性を組み込まなかったり、テストしやすさを明確な目標にしてコードを構造化しなかったりすることが挙げられる。

「未知の未知」を明らかにすることができる。プロトタイプは、予想できなかったことを明らかにすることが多い。これは僕の経験とは真逆だな。何かをいじっているときは、良い部分だけを体験していて、悪い部分は全く感じない…いわばハネムーン期みたいなもんだ。エッジケースをカバーしたり、無効な状態を防いだり、ユーザーに役立つエラーメッセージを表示したり、潜在的な副作用を排除しようとするまで、「未知の未知」に気づくことはない。

スケールがここではかなり重要だと思う。自分で何かを作ったり、小さなチームでやっているなら、投稿に書いてあることには完全に同意するよ。実際、そういう状況では迅速で雑な開発手法に頼るべきだと思う。これが小規模開発の強みだからね。うまくやれば、大きなプロジェクトよりもずっと早く進められる。バグは小さなチームやソロ開発者にとってはほとんどいつでも簡単に修正できるし、関わる全員がプロジェクト全体のほぼ完璧なメンタルモデルを持っているから、コード自体もコンウェイの法則のおかげで比較的シンプルに保たれる。大規模な開発プロジェクトでは、バグや特にアーキテクチャのミスを修正するのは、コードの理解が断片的で、アーキテクチャが悪夢のように複雑だから、指数関数的にコストがかかる。大規模なリファクタリングは、コードベースの一部をロックダウンすることを意味して、数十人から数百人が何もできなくなる（つまり、ほとんど起こらない）。そんな状況では、全てのステップでの正確さが重要な焦点になるべきだと思う。スケールの経済は、個々の開発者がそんな風に働いていても、許容できるペースで物事を進める助けになるよ。

最近、十分に堅牢なシステムを素早く構築する方法を学んだよ。ここで学んだことをいくつか挙げるね。* 一つのツールをしっかりと使いこなすこと。表面的には問題に適しているように見えるツールよりも、自分がよく知っているツールを使う方が多くの場合良い。非常に多くの現実の問題に対して、Djangoは絶妙な選択なんだ。何度かプロジェクトを始めるときにDjangoは重すぎるかもと思ったけど、すぐにそのプロジェクトは初期のアイデアを超えて成長した。例えば、最近ステータスページアプリを作ったんだけど、最初は単一ファイルのDjangoアプリだったけど、Djangoの制限を回避するのは意味がないとすぐに気づいた。* Djangoモデルに合うアプリケーションでは、データモデルが全ての中心にある。ラフなプロトタイプを作るときでも、データモデルのリファクタリングを後回しにしないこと。時間が経つにつれて、変更するのがどんどん高くつくし難しくなるから。* ほとんどのアプリケーションはシングルページアプリである必要もないし、重いフロントエンドフレームワークも必要ない。恩恵を受けられるものでも、従来のDjangoビューで80%のページは十分だよ。残りについてはAlpineJS/HTMXを考えてみて。* ほとんどの場合、自分で作った方が簡単だよ。顧客を保存して編集する必要がある？Djangoを使えば、数時間でアプリ内にシンプルなCRMアプリを開発できる。商業CRMを統合するのはもっと時間がかかる。これはステータスページ、CRM、サポートシステム、営業プロセスなど、ほとんどのDjangoアプリやライブラリにも当てはまるよ。* いつも超つまらない技術を選ぶこと。全てにPython/Django/Postgresを使って。KubernetesやRedis、RabbitMQ、Celeryは忘れて。Alpine/HTMXは例外だけど、JavaScriptスタックの多くを避けられるからね。

実は、プロトタイプでも最初から「ちゃんと」作るようにしてるんだ。成功してるとは言えないけど、少なくとも頑張ってるよ。これがすべてにテストを書くって意味じゃないし、時にはテストを書かないこともあるけど、コードを「テストしやすく」するように最善を尽くしてる。これに時間がかかるべきじゃないんだよね。テストしやすくするためにクラスを増やすのは、もう間違ってるってこと。可読性を妥協するわけでもないし、「クリーンコード」みたいなやり方は避けるべきだと思う。関数は必要な大きさにするべきだし、特にRubyやJavaを使ってる人たちがここに時間をかけすぎることが多い気がする。個人的には、5行の関数がたくさんあるのは全然必要ないから、このステップは飛ばしちゃう。抽象化について妥協するわけでもないし、「三つの法則」も好きじゃないな。後で余計な手間が増えるからね。でも、ジョン・アウスターハウトのスタイルで、DEEPなクラスとSMALLなインターフェースを好むから、コードを書くのにそんなに時間はかからないよ。考える必要はあるけど、普通のことだし。人が inertia でやらないだけのことだと思う。一つだけこだわってるのはスコープかな。スコープが大きすぎると、プロトタイプやMVPには向かないから、縮小するために戦うよ。EDIT: kukkeliskuuが「一つのツールをしっかり学ぶ」って言ってたけど、これも重要だね。プロトタイプや初期段階で「流れに逆らわない」ようにしよう。フレームワークと戦ってるなら、間違った道に進んでるよ。

「ラフドラフト」を「ドラフト」として維持するのが難しいって感じる。典型的な技術マネージャーがいると、最終的なコードになっちゃうんだ。最初から出荷用のコードを書く傾向があるけど、柔軟性を持たせるようにしてる。どこでも「出荷する」ことを学んだし、テストハーネスもかなり堅牢な出荷品質のアプリになることが多い。大事なのは、非常に高品質なモジュールだね。変わらないことが分かっている部分は常にあるし、もし変わる場合はそれが大きな問題になるから、そういう部分はスタンドアロンのモジュールに分けて、依存関係としてインポートしてる。これが最近リニューアルしたモジュールの一例だよ[0]。このアプリ[1]の設定ポップオーバーで使ってるし、ほとんどすべてにインポートしてるベースライン依存関係もある[2]。これで新しいアプリを開発するのがすごく早くなって、品質もかなり高く保てるんだ。たとえそれが主な目的じゃなくてもね。[0] https://github.com/RiftValleySoftware/RVS_Checkbox [1] https://github.com/RiftValleySoftware/ambiamara [2] https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool...

すごく共感する。ラフドラフト、手動実行が多くて、ユニットテストの実行者にラップされてたり、アイデアを確認するために別のスクリプト言語で書かれたりすることがよくある。これが、実際にはそのものを作りたくない理由を示すのに役立ったことが多い。人々が望むようには機能しないからね。コードの中の気が散る部分についても本当に実感する。自分は「整理整頓したくなる」傾向があって、そうするとウサギの穴にハマって、変更が大きくなって仲間がレビューするのが嫌がるサイズになっちゃう。こういう試みは、完全に捨てて元に戻ることが多いし、メインのことを小さく集中させるために頻繁に小さなローカルコミットが助けになる。時には何かを救って、時間があれば別のPRで公開することもある。ビジネスは結果を早く求めていて、コードのトレードオフを理解しないことが多い。負債が山のような大きさになるまで、些細な変更すらも痛みを伴うからね。でも、バランスが大事で、プロジェクトによって違うかもしれない。小さく、集中した、シンプルな変更は確実に助けになる。ただ、人々は大きな解決策を小さな部分に分けるのが得意じゃないことが多い。完全に使われないコードを含むコミットを見かけることがあって、「これは将来の作業の一部になる」ってコメントがついてることがあるけど、優先順位が変わったり、人が入れ替わったりして、1年後にはそれが現在の状態に適用されなくなって、誰もその計画を覚えていないことが多い。

例えば、24時間のゲームジャムでゲームを作るとき、クリーンなコードを優先するのはあまり良くないと思うよ。時間の無駄だし！コードがエレガントでバグがないかなんて、誰が気にするの？ちょっと話が逸れるけど、過去に（ゲーム以外の）ハッカソンでコードレビューをたくさんやってきた経験から言うと、パフォーマンスが良かったチームは、だいたいコードの質も良くて、基本的なテスト環境も整ってたことが多かったよ。

「私のチームにとっての『十分良い』とは何か？」受け入れられるバグは何か？早く物事を進めるために、どこで完璧じゃない仕事をしてもいいのか？私はプロジェクトを頻繁に行き来していて、これがキャリアの中でチーム間の対立の最大の原因だった。異なるバックグラウンドを持つ人たちが「十分良い」と思うレベルはそれぞれ違う。大手テック出身の人は、他の誰も徹底的にテストしていないことにイライラしてるし、スタートアップ出身の人は、みんなが遅すぎることにフラストレーションを感じてる。チームが同じページにいるために、「十分良い」を明確にできたらいいのに。

例えば、24時間のゲームジャムのためにゲームを作っているなら、クリーンなコードを優先するのはあまり良くないよね。それは時間の無駄だ！コードがエレガントでバグがないなんて、誰が本当に気にするの？24時間のゲームジャムに参加したことがあるけど、逆のことを感じたよ。本当に急いでいるときこそ、悪いコードは許されない。より良いコードを書くことで、正しく作るのが楽になって、作業メモリへの負担も減るし、早く試すことができて、最後の変更もやりやすくなる。最後の方で機能を追加するのも簡単になるし、重要なのは、集中的なデバッグが必要になる可能性を減らして、デバッグ自体も楽にしてくれること。良いコードで作業するのは本当に楽だよ。24時間のプロジェクトを壊すのは、コードを書くのが遅いことじゃなくて、自分を追い込むようなコードを書いたり、作業を脱線させる問題にぶつかることだよ。それは解決するのに何時間もかかるし、締切を過ぎても解決しないこともある。ゲームジャムではすべてのバグを潰そうとするのは無理だけど、それはやっていることの問題であって、やり方の問題じゃない。その状況でも良いコードを書きたいのは、時間の制約の中で自分の生活を楽にするためだし、いくらかのバグには目をつぶれるとしても、ゲームを不快にしたりプレイできなくするバグはたくさんあるから。どんなバグでも修正しなきゃいけないし、できれば少ない方がいいし、簡単なバグを修正したい！長期的な視点でも同じことが言えるよ。時間があれば、悪いコードに対処する余裕があるけど、それが書く意味があるってことにはならない！もちろん、正しい習慣を身につければ、質の高いコードを書くのはほぼタダになってくるけど、たとえ本当に意味がある遅れをもたらしたとしても、期待値的にはやる価値があると思うよ。