書き換え（プログラミング）

コンピュータ プログラミングにおける書き換えとは、ソース コードを再利用せずに既存の機能の大部分を再実装する行為または結果です。書き換えで既存のコードをまったく使用しない場合は、最初から書き換えると言われることがよくあります。

ソフトウェアは通常、次の 1 つ以上の条件が当てはまる場合に書き換えられます。

• ソースコードが入手できない、または互換性のない ライセンスの下でのみ入手可能である
• そのコードは新しいターゲットプラットフォームに適合できない
• 既存のコードは扱いにくく、拡張も困難になっている
• デバッグ作業は複雑すぎるようだ
• プログラマーはソースコードを理解するのが難しいと感じる
• 開発者は新しい技術を学んだり、大きな変更を必要とする大規模な機能の見直しを希望している
• ソースコードのプログラミング言語を変更する必要がある

ジョエル・スポルスキー^[1]などのソフトウェアエンジニアは、特にスケジュールの制約や競争圧力がある状況では、全面的な書き直しに対して警告を発しています。開発者は当初は過去の設計ミスを修正する機会を歓迎するかもしれませんが、書き直しは要求通りに機能する設計部分も破棄します。書き直しは、開発チームに新しい機能だけでなく、以前のコードに存在するすべての機能を提供することを約束し、新しいバグや、以前に修正されたバグの回帰を引き起こす可能性があります。^{[2] [3]}書き直しは、古いバージョンで修正されていないバグの追跡にも影響します。^[4]

増分書き換えは代替アプローチであり、開発者は既存のコードを新しい実装への呼び出しに徐々に置き換え、その実装を拡張して、古い実装を完全に置き換えます。このアプローチは、書き換え中に機能が広範囲に失われるのを防ぎます。クリーンルームソフトウェアエンジニアリングは別のアプローチであり、チームはソフトウェアの機能の徹底的な仕様書に基づいて作業する必要がありますが、コードにはアクセスできません。^[5]

NetscapeのNavigator 4 の HTML レイアウトを改善するプロジェクトは、書き直しの失敗例として挙げられています。新しいレイアウト エンジン ( Gecko ) は Navigator とは独立して開発され、Navigator のコードと簡単に統合できませんでした。そのため、Navigator 自体が新しいエンジンに合わせて書き直され、多くの既存の機能が壊れ、リリースが数か月遅れました。一方、Microsoft はInternet Explorerの段階的な改善に注力していたため、同じ障害に直面することはありませんでした。^{[3] [6]皮肉なことに、Navigator 自体は、そのプログラムの開発者が監督した}NCSA Mosaicのクリーンルーム書き直しの成功例でした。ブラウザー戦争を参照してください。

歴史上、大幅な書き換えがあったとされるプロジェクトをいくつか紹介します。

• 絞め殺しのイチジクの模様

• コードリファクタリング
• オープンソースソフトウェア開発
• 技術的負債
• 開発地獄
• 移植
• ゲームエンジンの再現
• リバースエンジニアリング

• C2 Wiki の RewriteCodeFromScratch
• 絶対にしてはいけないこと、パート 1ジョエル スポルスキー著