「すべてのソフトウェアには有効期限があり、それまでにゼロから書き直す必要があります。」
先輩エンジニアと非技術系の人との議論に出くわしましたが、これはある場所では強く信じられているようです。
そのような状況は、開発者とプロジェクトマネージャー、元のシステムの作成に関与している人々、および現在それを変更するのに苦労している人々の側の純粋な能力不足にあると私は考えています。特にこれらのグループの両方と交差する人。
私が間違っている？もしそうなら、なぜですか？
そうでない場合、この問題を克服するためにソフトウェア開発へのアプローチを変更する必要があること、および2〜3年ごとにシステムをゼロから書き直すことは避けられない事実ではないことを、開発者に私の年齢の2倍に説得するにはどうすればよいでしょうか。
この問題について引用できる本や影響力のあるプログラマーはいますか？
「単一の最悪の戦略的誤りソフトウェア会社が犯す可能性のある単一の最悪の過ち/（+）/：彼らはコードをゼロから書き直すことにしました。」[ 1 ]-ジョエルスポルスキー
短期間に何個のものが変化するかを考えてみましょう。新しいOSが登場します。既存のOSが再構築されます。サードパーティのパッケージが表示され、開発され、サポートが中止されるか、廃止されます。完全に新しいデバイスとパラダイム（例：タッチスクリーンが標準になっている）を含む新しいハードウェアが登場します。
既存のパラダイムは、悪用可能な欠陥があるとして公開されており、放棄されているか、市場から消え去っています。これらはすべて、アプリケーションを変更する必要があり、noneは、先輩の能力不足に陥っています。
ソフトウェアalwaysをゼロから書き直さなければならないことには同意しませんが、書き換えの唯一の（そして優れた）代替手段は、定期的な継続的なリファクタリングです。アプリケーション全体を記述でき、それがいつまでも行われるという考えは、まったく間違っています。
私は以前、ファイルの先頭に「著作権1984」が含まれているソースコードを持つ会社で働いていました。動作したため、コードベースに残っていましたが、-まだ動作しているであるため、削除も置換もされていません。
最終的には書き直されるものはたくさんありますが、非常にまれなので、そうなることはありません。例えば。 IPの書き換えを実装しようとしているにもかかわらず、TCP/IPはまだ残っています。 HTTP 1.1で少しリファクタリングされたにもかかわらず、HTTPはまだここにありますが、それでも以前とほとんど同じです。他にもたくさんの例があります。
常に書き直している人々は、ソフトウェアを最初から正しく設計する方法を知りません。
「すべてのソフトウェアには有効期限があり、それまでにゼロから書き直す必要があります。」
これは、不適切に設計および実装されたソフトウェアにのみ当てはまります。適切に設計されたソフトウェアの場合、次のことが当てはまります。
「すべてのソフトウェアは時々完全に置き換えられます。」
しかし、これは「人体の細胞は7〜10年ごとに完全に交換される」と同じです。それは、期間が経過した後、人が完全に生まれ変わるという意味ではありませんが、小片が継続的に交換されるため、10年以上経過した細胞はありません。適切に設計されたソフトウェアは同じ特性を持つべきです。特にそれが複雑で大きなシステムである場合。プラットフォーム、フレームワーク、言語が変わると、以前のもののために開発するのははるかに高価になります。しかし、Joel Spolskyが言うように、1回の大きな書き換えでシステム全体を置き換えるのはひどい考えです。代わりに、維持するにはコストがかかりすぎる部分を書き換えることは、はるかに現実的なアイデアです。したがって、数年かけて、コードベース全体を置き換えながら、長時間にわたってソフトウェアが機能しないことによる影響を最小限に抑えることができます。
コード、それが何をするか、そして誰がそれを書いたかによります。
正しい答えは、もちろん、数年ごとに完全に廃棄したり書き直したりせずに簡単に更新できるようにソフトウェアを設計して実装することです。積極的に考慮し、段階的に展開し、テストテストテストを行い、先を読みます。
だが...
新しいプラットフォームに移行するリスクが非常に高いため、80年代のヴィンテージのハードウェアとソフトウェアで実行されているデータセンターもあります。これらは、投資銀行や数十億ドル規模の企業向けの注文管理システムなど、非常に大量のオンライントランザクション処理システムであり、ダウンタイムは1分あたり数百万ドル単位で測定されます。新しいプラットフォームへの切り替え1 効果的に瞬間的である必要があり（数分のダウンタイムよりも短い）、新しいシステムは少なくともを既存のシステムと同じくらい確実に実行する必要があります。エンドユーザーのPOVから、遷移は非表示である必要があります。
そのコードがすぐに破棄されることはありません。可能な場合、移行は段階的に行われますが、これらのシステムの多くは一体型のCOBOLアプリであり、簡単にリファクタリングできません。それは当時の検討事項ではありませんでした。
1.ハードウェア、OS、データベースエンジン、アプリケーションコードなど。幸運を感じますか？
たった2〜3年で廃棄、再設計、書き直さなければならないようなシステムを設計することは想像できませんが、それが可能ではないことを全面的に表明したくありません。ソフトウェア開発には多くのアプリケーションドメインがあり、企業の競争力を維持するために必要なさまざまなニーズと実践があります。 「市場投入までの時間」が最も重要である企業は、そのカテゴリーに分類されると思います。残念ながら、私はその主張をする企業の99％が実際に「市場に出すまでの時間」は彼らが信じているほど重要ではないと思います。数か月後には、より堅牢なアプリケーションの方がはるかに優れた利益をもたらす可能性がありますが、堅牢なアプリケーションを構築するにはスキルと忍耐力が必要です。
とにかく、私はかなりの数の「シニア」開発者と仕事をしてきましたが、2〜3年でシステムを修正するよりもスクラップしやすくなったので、作業をやり直した（ときどき何回もやり直した）私は彼らの仕事を製品にしました。したがって、「上級」であることは、必ずしもその人がソフトウェアを効果的に開発する方法を知っていることを意味するわけではありません。
作業しているアプリケーションドメインの詳細を知らなくても、質問に対する「正しい」回答はないと思います。「再構築された」システムは、基本的に拡張された同じシステムですか、それとも本当に新しいアプリケーションですか？それらが本質的に同じである場合、あなたの「シニア」の人は完全に間違っています。彼らは明らかに多くの分野でスキルに欠けています。一方、新しいアプリケーションが実際には「新しい」アプリケーションであり、以前のアプリケーションといくつかの類似した特性しか共有していない場合、「上級者」はより効率的なアプローチを取っている可能性があります。
2〜3年ごとにゼロから書き直すことは、私には極端に思えます。しかし、ゼロから書き直すことにした理由は、現在のシステムの要件が大幅に変更されたため、元の仕様に類似していないためです。つまり、基盤となるアーキテクチャ可能性がありますは、現在の要件に適したものではありません。したがって、適切に設計およびコード化されたシステムの代わりに、1日目から要件の進行を見て初めて意味のあるパッチと奇妙な設計変更で構成されるシステムがあります。