複雑さのジャンプをどのように管理しますか？
時々プロジェクトに取り組んでいて、突然何かが突然現れて、作品に巨大なスパナを投げ込み、複雑さを大幅に高めることは、まれではあるが一般的な経験のようです。 たとえば、私は他のさまざまなマシンでSOAPサービスと通信するアプリケーションで作業していました。正常に動作するプロトタイプを作成し、その後、通常のフロントエンドを開発し、一般的に、すべてを素晴らしく、非常にシンプルで、簡単にフォローできる方法で実行しました。より広いネットワークでテストを開始し、接続の待ち時間とリモートマシンで計算を実行するのに必要な時間がSOAPサービスへのタイムアウトリクエストになったため、突然ページがタイムアウトするまで、うまくいきました。要求ごとに計算を実行するのではなく、バックグラウンドで段階的に更新できるように、要求を独自のスレッドにスピンアウトし、返されたデータをキャッシュするようにアーキテクチャを変更する必要があることが判明しました。 そのシナリオの詳細はあまり重要ではありません-実際、それは非常に予見可能であり、このタイプの環境用にこのタイプのアプリをたくさん書いた人々はそれを予想したかもしれないので、素晴らしい例ではありません-単純な前提とモデルから始め、突然プロジェクトの開発に複雑さをエスカレートさせることができます。 開発プロセスの後の段階で、またはテストの結果として、多くの場合仕様変更ではなく環境要因の結果として、これらのタイプの機能変更の必要性に対処するための戦略はありますか？可能性はあるが必ずしもそうではない可能性のある問題を軽減するソリューションを設計することで、同じくらい効果的である可能性が高いが、準備が整っていないソリューションを設計することで、時期尚早な最適化/ YAGNI /オーバーエンジニアリングのリスクを回避することのバランスをどのように取るか起こりうるあらゆる事態？ 編集：Crazy Eddieの答えには、「あなたはそれを吸い込んで、新しい複雑さを実装するための最も安価な方法を見つける」ということが含まれています。それで、質問に暗示されている何かを考えさせられましたが、具体的には挙げませんでした。 そのバンプにヒットしたら、必要な変更を組み込みます。プロジェクトをできるだけスケジュールに近づけるが、保守性に影響を与える可能性があることを行いますか、またはアーキテクチャに戻って、保守性が高いかもしれないが開発中にすべてを元に戻すより詳細なレベルでやり直しますか？