Rewrite (programming)

컴퓨터 프로그래밍에 A에서 rewrite는 행위 또는 그것의 소스 코드를 재사용 없이 기존 기능의 큰 부분 re-implementing의 결과이다.는 언제에서 rewrite모든 기존 코드를 사용하는 것이 아니라면, 그것은 다시 쓴 것의 처음부터 말해 일반적이다.

동기

때 다음 중 하나 이상 신청하다 소프트웨어 한조각의 일반적으로:다시 쓴다.

• 그것의 소스 코드 또는 호환되지 않는 허가를 받고 가능하다 사용할 수 없습니다.
• 그 코드는 새로운 타깃 플랫폼에 적응할 수 없다.
• 기존 코드를 처리하거나 확장하기가 너무 어려워졌습니다.
• 그것을 디버깅하는 작업은 너무 복잡해 보인다
• 프로그래머는 소스코드를 이해하는 것이 어렵다는 것을 안다
• 개발자들은 새로운 기술을 배우거나 많은 변화가 필요한 큰 기능 정비를 하고 싶어 한다.
• 개발자는 작성된 새로운 코드가 이전 문제를 수정하거나 덮어쓸 수 있는 콘텐츠 옵션을 확장할 수 있음을 알게 됩니다.
• 소스 코드의 프로그래밍 언어를 변경해야 합니다.

리스크

Joel Spolsky와^[1] 같은 몇몇 소프트웨어 엔지니어는 특히 스케줄 제약이나 경쟁상의 압박으로 인해 전면적인 개서를 하지 말라고 경고했습니다.개발자들은 처음에는 과거의 설계 실수를 수정할 기회를 환영할 수 있지만, 재작성에서는 필요에 따라 작동하는 설계 부분들도 폐기됩니다.재작성 시 개발팀은 새로운 기능뿐만 아니라 이전 코드에 존재하는 모든 기능을 제공함과 동시에 새로운 버그나 이전에 수정된 ^[2][3]버그의 퇴행도 발생할 수 있습니다.개서에서는 이전 ^[4]버전에서 수정되지 않은 버그를 추적하는 것도 방해됩니다.

증분 개서란, 개발자가 기존의 코드를 콜과 함께 단계적으로 새로운 실장으로 대체해, 낡은 것을 완전히 대체할 때까지 실장을 확대하는 대체 어프로치입니다.이 어프로치를 사용하면, 개서중에 큰폭의 기능 손실을 회피할 수 있습니다.Cleanroom 소프트웨어 엔지니어링은 또 다른 접근방식으로,^[5] 코드에 액세스하지 않고 소프트웨어 기능의 완전한 서면 사양을 바탕으로 작업해야 합니다.

예

Navigator 4의 HTML 레이아웃을 개선하기 위한 Netscape의 프로젝트는 실패한 개서의 한 예로 인용되었다.새로운 레이아웃 엔진(Gecko)은 Navigator와 독립적으로 개발되어 Navigator의 코드와 쉽게 통합되지 않았습니다. 따라서 Navigator 자체가 새로운 엔진 주위에 다시 쓰여져 많은 기존 기능이 손상되고 출시가 몇 달 지연되었습니다.한편, 마이크로소프트는 Internet Explorer의 점진적인 개선에 초점을 맞췄고, 같은 ^[3][6]장애물에 직면하지 않았다.아이러니하게도 Navigator 자체는 NCSA Mosaic의 클린룸 개서를 성공시킨 프로그램 개발자들이 감독하고 있다.브라우저 전쟁을 참조하십시오.

「 」를 참조해 주세요.

• 코드 리팩터링
• 오픈 소스 소프트웨어 개발
• 기술채무
• 개발 지옥
• 포팅
• 게임 엔진 레크리에이션

일부 프로젝트에서는 이력의 주요 개서를 언급하고 있습니다.

레퍼런스

외부 링크

• C2 Wiki의 Rewrite Code From Scratch
• 절대 하지 말아야 할 일, 파트 1 by Joel Spolsky