- 最近、著名な技術系CEOとエンジニアとの会話で、興味深いソフトウェア開発手法を聞いた。この手法を通じて、別のヒューリスティックや一般化について考えるようになった。
彼の方法
- 一日の始めに機能開発に着手する。一日の終わりまでに完了できなければ、すべて削除して翌日にまた最初から始める。作成した単体テストは保持してよい。
- 数日たってもその機能を実装できないなら、その機能を可能にする基盤、インフラ、またはリファクタリングを考え、それを実装してから機能に戻る。
- この方法は、90年代後半から2000年代初頭のエクストリーム・プログラミング運動に似ている。
方法についての考え
「すべてを二度書く」
- ジュニアエンジニアに与える助言: 問題を解決し、コードをブランチに保存したあと、もう一度書き直す。
- ノートPCが故障したあと、この方法を偶然発見した。書き直しには最初の実装の25%の時間しかかからず、結果ははるかによくなった。
- 1.25倍の時間で、2倍高品質なコードを得られる。長期保守が必要なプロジェクトに有用。
- 「毎日やり直す」方法はこれよりさらに極端だ。書き直すたびに、より洗練された解決策を見つけるようになる。
「量は質を持つ」
- スターリンの引用はソフトウェアエンジニアにも当てはまる。ジュニアエンジニアには、最初の10万行のコードが不可欠だ。
- 「毎日やり直す」方法は、その10万行をより速く書く助けになる。
- 同じ問題を繰り返し解くことは、パターンを記憶するのに有益だ。
- 5,000行の完璧なコードで主要なパターンはすべて見えてくる。残りの9万5,000行は、反復を通じてニューロンを再配置する。
「頭に銃を突きつけられたら」ヒューリスティックとの比較
- 問題の解決策を提示した人に、「24時間以内に終わらせなければならないとしたら、どうするか？」と尋ねる。
- この方法はフレーミングとアンカリングのバイアスを壊す。しばしば数分で、1日で終えられる計画へと導ける。
- 実際には1日で終えられる計画ではないが、新しい解決策はしばしば数日で完了できる。
- この思考実験の目的は、実際の解決策を生み出すことではなく、解決策の下限を設定することだ。
経路探索
- 問題空間で経路を見つけることが核心だ。各経路が解決策であり、エンジニアの役割は最良の経路を見つけることだ。
- こうしたヒューリスティックと、さまざまな経路探索アルゴリズムのあいだの類似性を考えてみる価値がある。
- エンジニアリングのヒューリスティックも同様で、より優れたエンジニアになるとは、問題空間でより良い経路を見つけることだ。
GN⁺の要約
- この記事は、ソフトウェア開発における効率的な方法論とヒューリスティックを探っている。
- 「毎日やり直す」方法と「すべてを二度書く」方法は、コード品質を高めるのに有用だ。
- 反復的な問題解決は、パターン認識とニューロンの再配置に役立つ。
- 「頭に銃を突きつけられたら」ヒューリスティックは、解決策の下限を設定するのに有用だ。
- 問題空間で最良の経路を見つけることが、エンジニアの中核的な役割だ。
5件のコメント
正気ですか？ こんなこと、時間が有り余っている人間にしかできないでしょう。これが現実的に成り立つ行為だとでもいうんですか？
韓国のSI環境では無理でしょうね..（笑） 個人プロジェクトでなら
このアプローチはまったく思いつかなかった方法ですね。
一度試してみようと思います（笑）
書き直しについてはとても共感します。
以前、作業していたコードをうっかり消してしまい、書き直しているうちに
途中で設計を変えるのが面倒で無視していたことも考慮して作るようになって、
結果的にはむしろ良くなりました。
Hacker Newsの意見
新しい機能を2回書くのは良い戦略だ。ただし、ビジネス開発者やプロジェクトマネージャーには不要な遅延に見えることがある
「24時間以内に終わらせなければならないとしたら？」という質問は、プロジェクトマネージャーがするようなものではない
良いコードは、適切な抽象化を選んで書かれる
有能な同僚がいれば、短時間で何ができるかを示せる
ソフトウェアを2回書くのが良いという意見には共感する
数日たっても機能を実装できないなら、必要なインフラやリファクタリングを先に行うべきだ
「24時間以内に」と「すべてを2回書く」は互いに関連している
この投稿は最高の「プログラミングの助言」の1つだ
ときには問題を解決するためにバックグラウンドスレッドを回しておく必要がある
次のアプローチが有用だ