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

コンピュータープログラミングの書き換えとは、ソースコードを再利用したり、碑文を書いたりすることなく、既存の機能の大部分を再実装する行為または結果です。書き換えが既存のコードをまったく使用していない場合、書き換えをゼロから話すのが一般的です。

動機

ソフトウェアの一部は、通常、次の1つ以上が適用されるときに書き換えられます。

• そのソースコードは利用できないか、互換性のないライセンスの下でのみ利用可能です
• そのコードは新しいターゲットプラットフォームに適合できません
• 既存のコードは扱いにくく、拡張するのが困難になりました
• デバッグのタスクは複雑すぎるようです
• プログラマーはソースコードを理解するのが難しいと感じています
• 開発者は新しいテクニックを学ぶか、大幅な変更を必要とする大きな機能のオーバーホールを行いたい
• 開発者は、記述された新しいコードが以前の問題を修正または上書きできるコンテンツオプションを拡張する可能性があることを学びます
• ソースコードのプログラミング言語を変更する必要があります

リスク

Joel Spolskyなどのいくつかのソフトウェアエンジニアは、特にスケジュールの制約や競争圧力の下で、全面的な書き換えを警告しています。開発者は当初、歴史的な設計ミスを修正する機会を歓迎するかもしれませんが、書き直しは必要に応じて機能する設計の部分も破棄します。書き換えにより、開発チームは新しい機能だけでなく、以前のコードに存在するすべての機能を提供する一方で、潜在的に新しいバグや以前に修正されたバグのリグレッションを導入します。書き換えは、古いバージョンの修正されていないバグの追跡にも干渉します。

インクリメンタルリライトは、開発者が既存のコードを新しい実装への呼び出しで徐々に置き換え、古い実装を完全に置き換えるまでその実装を拡張する代替アプローチです。このアプローチにより、書き換え中の機能の大幅な損失を回避できます。クリーンルームソフトウェアエンジニアリングは別のアプローチであり、コードにアクセスすることなく、チームがソフトウェアの機能に関する包括的な仕様書から作業する必要があります。

注目すべき例

Navigator 4のHTMLレイアウトを改善するNetscapeのプロジェクトは、書き換えの失敗の例として引用されています。新しいレイアウトエンジン（Gecko）はNavigatorから独立して開発されていたため、Navigatorのコードと簡単には統合できませんでした。そのため、Navigator自体が新しいエンジンを中心に書き直され、多くの既存の機能が破壊され、リリースが数か月遅れました。一方、MicrosoftはInternet Explorerの漸進的な改善に重点を置いており、同じ障害に直面していませんでした。皮肉なことに、Navigator自体は、そのプログラムの開発者が監督するNCSA Mosaicのクリーンルームの書き換えに成功しました。ブラウザ戦争を参照してください。