BIG Rewrite에 참여한 적이 있습니까? [닫은]

Joel Spolsky 는 그의 유명한 게시물 중 하나에서 다음과 같이 말했습니다.

모든 소프트웨어 회사가 할 수있는 최악의 전략적 실수 : 코드를 처음부터 다시 작성하십시오.

차드 파울러 는 다음과 같이 썼다.

비디오, 웹 로그 게시물 및 과대 광고를보고 Rails (또는 Java, .NET 또는 Erlang 등)에서 제품을 다시 구현하기로 결정했습니다.

조심하십시오. 이는 예상보다 길고 단단하며 오류가 발생하기 쉬운 경로입니다.

BIG Rewrite에 참여한 적이 있습니까?
이 비극적 인 주제에 대한 귀하의 경험, 특히 성공적으로 완료된 큰 재 작성에 관심이 있습니다 (있는 경우).

나는 내 경력에 대한 몇 번의 재 작성에 참여했으며 모두 재앙이었습니다. 모두 같은 이유로 실패한다고 생각합니다

• 필요한 노력의 과소 평가 : 누군가가 다시 쓰기를 원할 때마다 기존 시스템은 오래된 기술을 사용하고 유지하기가 어렵 기 때문입니다. 그들이 고려하지 않은 것은 나이 때문에 30-40 년의 개발 노력이있을 수 있다는 것입니다. 5 개월로 6 개월 만에 모든 것을 다시 쓸 수 있다고 생각하는 것은 어리석은 일입니다.
• 잃어버린 지식 : 오래된 시스템은 오랫동안 사용되어 왔으며 많은 일을하며 모든 것에 연결되어 있습니다. 최신 문서가 없으며 시스템이 수행하는 모든 작업을 실제로 알고있는 단일 권한 지점이 없습니다. 특정 부서의 특정 사용자에 대한 지식이있을 수 있으며,이를 모두 찾아내는 것은 어렵거나 불가능합니다.
• 불쌍한 경영진 결정 : 내가 관여했던 재 작성은 경영진과 비슷한 기대를 가졌다 : 새로운 시스템은 '완료'되어야하며, 기존 시스템은 특정 날짜, 기간에 단순히 꺼질 수있다. 다른 옵션은 허용되지 않았습니다. 나는 그들이이 거대한 프로젝트를 위해 새로운 사람들을 고용하기 위해이 모든 돈을 소비하고 있기 때문에 그들이 이것을 머리 속에 넣는 것 같아요. 실제로 더 나은 위험 완화 전략은 이전 시스템의 주요 기능을 다시 작성하고 이전 릴리스의 50-75 %를 첫 번째 릴리스로 처리 한 다음 작동 방식을 확인하는 것입니다! 위의 # 1 및 # 2로 인해 누락 된 기능 중 일부와 이전 시스템을 실제로 끄는 데 필요한 기능을 발견하면 훨씬 잘 작동합니다.

범위를 올바르게 지정 하면 다시 쓰기가 매우 성공적 일 수 있습니다 . 이 프로젝트가 "BIG"(TM) 프로젝트의 임계 값을 충족하는지는 잘 모르겠지만보다 성공적인 몇 가지 재 작성에 대해 설명하겠습니다.

프로젝트 1

내가 근무 회사는 당신이라는 것을에서 소매 선반에 표시되는 레이블을 생성하는 데 사용 선반 스트립 인쇄 시스템했다 플라 노 그램을 . 플래 노 그램은 산업 표준 소프트웨어로 생성되었으며 툴은 대상 상점의 템플리트를 사용하여 선반 스트립을 작성하기 위해 해당 문서를 읽습니다. 템플릿 소프트웨어는 여러 클래스와 3 개의 DLL을 포괄하는 중첩 된 유한 상태 머신의 혼란이었습니다. 페그 보드를 위해 특허 출원중인 접근 방식을 구현할 때가되었지만 현재 코드가 우리가 원하는 것을 지원할 수 없다는 것이 분명했습니다.

솔루션 : 우리는 단지 재 작성을 템플릿 엔진에만 적용했습니다. 우리는 적절한 OO 설계를 사용하여 현재 요구 사항을 처리하고 새로운 페그 보드 요구 사항을 해결했습니다. 재 작성 시간은 1 개월입니다. 전체 툴 체인을 전체적으로 재 작성하면 1 년이 넘게 걸렸지 만 그렇게 할 필요는 없었습니다.

프로젝트 2

우리 팀이 처음부터 구축 한 웹 응용 프로그램은 원래 디자인을 능가하기 시작했습니다. 우리의 고객은 또한 사용자들에게 더 나은 사이트를 제공 할 수있는 새로운 요구 사항을 갖추 었으며, "웹 2.0"에 더 적합 할 것입니다. 기존 디자인을 현재 가지고있는 프레임 워크에 적용 할 수 있었지만 유지 관리는 악몽이었습니다. 우리는 응용 프로그램을 자세히 알고 있었고, 어떤 부분을 가져와야하고 어떤 부분이 새 버전의 일부로 사라질지 알고있었습니다.

해결 방법 : 우리 팀은 완료하는 데 3 개월이 걸렸습니다. 최종 제품은 최종 사용자에게 더 빠르고 확장 가능하며 더 즐거웠습니다. 우리는 고객의 기대를 뛰어 넘었습니다. 즉, 기존 시스템에서보다 즉각적인 버그 수정 및 반창고 패치를 수행하고 나머지 절반은 새로운 시스템에서 작업 할 수 있도록 팀을 분할해야했습니다. 우리는 광범위한 테스트를 실시했으며 프로세스 초기에 통합했습니다. 이것이 잘 된 이유는 우리 가이 응용 프로그램과 고객을 친밀하게 알고 있기 때문입니다.

프로젝트 3

여기에 실패를 포함시켜야합니다. 우리는 재난 / 위기 상황에서 사용하기 위해 정보 관리 도구가 필요한 고객을 지원하고있었습니다. 우리는 원래 개발자가 Swing을 완전히 이해하지 않고 작성한 Java Swing 응용 프로그램을 상속했습니다. 즉, Swing을 다루고 UI를 올바르게 관리하기위한 Sun의 권장 사항을 따르지 않았기 때문에 무한한 이벤트 루프 및 기타 이상하고 추적하기 어려운 문제가 발생합니다. 결과적으로 버그, 사용자 인터페이스 문제 등으로 가득 차있었습니다. 이것은 매우 복잡한 응용 프로그램이었습니다. 우리의 정신을 보존하기 위해, 우리는 잘못 작성된 Swing 앱을 잘 작성된 Swing 앱으로 다시 작성하려고 시도했습니다.

솔루션 : 우리는 약 3 개월 후에 3 개월 동안 재 작성을 완료했습니다. 응용 프로그램은 UI와 처리 할 수있는 데이터 양에서 더 잘 수행되었습니다. 2004 년 쓰나미가 발생했습니다. 그들이 추적해야 할 사람들의 수는 엄청나게 많았 기 때문에 Swing이 실제로 필요한 것에 대해 잘못된 기술 이라는 것을 보여주었습니다 . 우리는 성능 조정을 따라 잡을 수 없었고, 결국 그들은 사내에서 보유한 Oracle 팀이 만든 함께 묶인 웹 앱을 선호하여 툴을 포기했습니다. 물론 우리가 당시에 알고 있던 지식을 바탕으로 우리가 한 일을 정당화 할 수 있었지만, 재 작성은 충분히 공격적이지 않았으며 추적해야 할 수 있는 사람들의 수에 대한 요구 사항도 고객에게 알리지 못했습니다. 낮은.

결론

다시 쓰기는 때로는 필요, 당신은 제대로 계획하는 경우에 그들은 성공적으로 완료 할 수 있습니다. 전체 판매 재 작성보다 시스템의 일부에 대해 대상 재 작성을 통해 더 많은 것을 얻을 수 있습니다. 마지막으로, 프로젝트 실패의 원인은 반드시 재 작성 자체가 아닙니다. 우리는 결코 천박 할 수는 없지만 최악의 시나리오를 생각해 낼 수 있습니다. 제가 생각할 수있는 최악의 시나리오를 두 배로 지원하도록 시스템을 설계하는 법을 배웠습니다. 위기 관리 시스템의 경우에는 충분하지 않습니다. 실제 수치는 최악의 시나리오 시나리오의 20 배입니다. 그러나 이것이 우리가 생각할 수있는 최악의 시나리오는 아니 었습니다.

• 다시 쓰기 위해 다시 쓰기는 친구가 아닙니다. 당신은 보지 못하는 복잡성이 항상 많으며, 당신이 보는 추악한 것들이 고객을위한 훈련 도구라는 것을 알게 될 것입니다. 항상 현재 진행 상황을 정기적으로 고객에게 보여 주어 최악의 범죄를 포착 할 수 있도록하십시오.
• 대상 재 작성은 코드 기반의 최악의 범죄를 처리하는 데 유용합니다. 범위를 제한하고 대부분의 문제를 해결할 수 있으면 완전히 다시 쓰지 마십시오.

VB6에서 .NET으로 여러 번 다시 작성했습니다. 2 건의 경우 재 작성이 순조롭게 진행되었으며 실제로 일정보다 앞서 완료되었습니다. 다른 재 작성은 예상보다 오래 걸리지 만 큰 문제없이 완료되었습니다.

우리의 특별한 경우에 다시 쓰기는 회사가 할 수있는 최악의 결정이 아닙니다. 최종 결과는 실제로 원본보다 훨씬 안정적이며 우리를 훨씬 더 나은 곳으로 인도했습니다.

기존 시스템을 완전히 다시 작성할 때 가장 큰 함정 중 하나는 "새로운 시스템이해야 할 일을 지정할 필요가 없습니다. 매우 간단합니다. 이전 시스템이하는 일을 정확히 수행하면됩니다!" .

문제는 대부분 이전 시스템의 기능을 정확히 아는 사람이 없으며 이전 시스템의 다른 사용자가 작동해야한다고 생각하는 방식에 따라 새 시스템이 작동하는 데 많은 시간을 소비한다는 것입니다. 기존 시스템의 원래 요구 사항도 대부분 사용할 수 없습니다.

광산은 "성공"이야기입니다. 내 프로젝트에는 4 개의 독립적으로 관리 / 기록 된 위성 사이트 (서로 다른 응용 프로그램이있는 하위 도메인)가있는 기본 사이트가 포함되었습니다. 우리는 4 개의 주요 사용자 기반 (모두 별도의 활성 디렉토리 내에 있음)을 가지고 있었으며 공통 인증 시스템이 없었습니다. 3 개는 잘 정립되고 사일로 애플리케이션이며 4 번째 위성은 아주 새롭고 가장 설립 된 사이트에서 코드 기반의 많은 부분을 복사했습니다.

목표 : 4 개의 도메인에서 계정을 인증하고 1 개 도메인에서 셀프 서비스 계정으로 전체 관리 계정을 인증 할 수있는 전사적 자격 증명 시스템을 구현합니다. .Net은 이미 위성에 구현 되었기 때문에 "리드 인"역할을하는 클래식 ASP 사이트를 다시 작성하고 ID 관리 기능을 추가했으며 모든 사이트에 회귀 테스트를 수행하여 서비스에 영향을 미치지 않도록해야했습니다.

리소스 : 3 명의 기본 설계자-프로그래머, ID 관리, 프로젝트 관리자. 약 20 명의 개발자, 10 명의 분석가, 10 명의 테스터

완료 시간 (완료 시작) : 1.5 년

발사 성공 : 거의 실패

장수 성공 : 대단한

ID 관리 아키텍트 였으므로 모든 위성이 상호 작용할 수있는 데이터베이스, 하위 시스템 및 논리 인터페이스를 설계했습니다. "프로그래머"아키텍트는 모든 위성에 대한 광범위한 비즈니스 지식과 그 시점까지의 응용 프로그램 및 개발 경험이있는 수석 개발자였습니다.

우리 회사의 여러 부서에서 온 50여 명의 다른 사람들과 몇 달 동안의 요구 사항을 수집 한 후 논리 아키텍처를 정리하고 코드를 작성하기 시작했습니다. 변경의 특성으로 인해 자체 웹 사이트와 웹 사이트에 포함 된 모든 기능을 .Net에 다시 작성해야했습니다. 어떤 경우에는 리팩토링 문제 일뿐입니다. 많은 경우, 프로세스를 둘러싼 프로세스를 완전히 다시 작성해야했습니다. 두 경우에서 우리는 단순히 원래 기능을 중요하지 않은 것으로 포기했습니다. 우리는 그 과정에서 2 개의 마감일을 놓쳤습니다 (그러나 내가 제안한 원래의 마감일이 거의되지 않았습니다. 출시 당일 아무 효과가 없었습니다. 토요일에 시작하여 영향을 최소화했지만 하루 종일 로그를 정리하고 조각을 다시 작성하고 서버로드를 평가했습니다. 더 많은 테스트가 도움이 될 수 있습니다.

첫날이 끝날 무렵, 모든 사이트가 가동되어 모든 것이 작동했습니다 (공인 성공이라고 말하겠습니다). 지난 2.5 년 동안 모든 것이 대단한 성공을 거두었습니다. 공통 프레임 워크 기반의 공통 아키텍처에 모든 사이트를 배치함으로써 개발 및 교차 개발자 작업이 훨씬 쉬워졌습니다. 2.5 년 전에 사이트에 쓴 기능 (다시 작성하는 동안)은 몇 개의 위성 사일로에 의해 보이거나 채택되었습니다.

로깅, 사용자 추적, 가동 시간 증가, 인증 / 인증 / 식별을 담당하는 단일 애플리케이션이 증가했습니다. 위성 사일로는 응용 프로그램에 전적으로 집중할 수 있으며, ID 관리 응용 프로그램에 인증 / 권한 문제가 있음을 신뢰할 수 있습니다.

우리의 프로젝트는 많은 좌절, 상심 및 재난이었습니다. 결국 그것은 돈을 지불 한 다음 일부를 지불했습니다. 나는 Joel Spolsky의 재 작성에 대한 평가에 일반적으로 100 % 동의하지만 항상 예외가 있습니다. 다시 쓰기를 고려하고 있다면 꼭 필요한 것인지 확인하면됩니다. 그렇다면, 그와 함께 제공되는 모든 통증에 대비하십시오.

나는 지금 거대한 코드 다시 작성에 관여하고 있습니다 ... 유일한 문제는 내가 그것에 대한 유일한 사람입니다! 현재 소프트웨어의 유지 관리 비용은 엄청나고 버그가 많으며 1 명의 FT 직원이 유지 관리하므로 자체적으로 구축하기로 결정했습니다.

훨씬 느리게 예상했지만 결국에는 코드베이스가 있기 때문에 향후에 원하는 변경 사항을 쉽게 구현할 수 있기 때문에 훨씬 나아질 것이라고 생각합니다 (소프트웨어는 자주 변경해야합니다. 현재 시간). 또한 디자인을 다시 작성하는 동안 디자인을 크게 변경하고 있습니다.

이전 작업에서 완전히 다시 작성하는 데 참여했습니다. 그리고 우리는 그렇게해서 매우 기뻤습니다. 때로는 코드베이스가 너무 썩어서 다시 시작하는 것이 좋습니다.

실제로는 주요 비즈니스 응용 프로그램 인 내부 응용 프로그램이었습니다.

우리는 버전 2를 작성하면서 이전 시스템을 유지했습니다. 올바르게 기억한다면, 약 1 년이 걸렸습니다 (2 명의 프로그래머, 3 분의 1). 그러나 데이터베이스를 건드릴 필요가 없었으므로 최소한 데이터 마이그레이션은 문제가되지 않았습니다.

모든 것이 다릅니다. 내 경우에는 Joel Spolsky의 조언을 따르고 잘못되었습니다 . 그것은 보험 웹 사이트에 관한 것이었다. 사이트는 끔찍했고 여기에 내가 한 일이 있었고, 내가해야했던 일이 있습니다.

나쁜 전략 : 나는 4 명의 학생들로 구성된 그룹을 감독했다 :

• 학생 # 1-데이터베이스 액세스 / 쿼리를 다시 작성하여 안전하게 보호
• 학생 # 2-모든 CSS를 위로 이동
• 학생 # 3-모든 페이지 w3c 호환 가능
• 학생 # 4-대기중인 모든 버그 해결
• 내 자신 : 모든 PHP 경고 및 엉터리 물건을 제거했습니다 (중복 코드 등)

2 개월이 걸렸습니다. 그런 다음 사이트를 다시 디자인했습니다. 그런 다음 다국어를 사용했습니다. 결국 우리는 크 래피 코드의 많은 부분을 유지해야했고 데이터베이스 구조는 동일하게 유지되었습니다. 그래서 나는 여전히 1 년 동안 엉터리 물건을 연구하고 있으며 실제로 다시는 완전히 재 작성을 결정할 때까지 결코 끝나지 않을 것입니다.

좋은 전략 :

• 전체 사이트를 연구하여 "제품 요구 사항 문서"를 작성하십시오.
• 데이터베이스를 올바르게 재 설계
• 내 프레임 워크 (처음 작동)로 처음부터 시작
• 사이트를 다시 디자인했습니다.
• 다국어를하십시오.

소요 시간 : 2 개월 ( 아마도 더 적음 ).

• 좋은 코드입니다.
• 좋은 유지 보수.
• 생산력.
• "우리는 이것을 할 수없고, 웹 사이트는 그런 제품을 다룰 수 없습니다"와 같은 대답이 없습니다.

그래서, 나의 마지막 말 : 그것은 모두 당신이 다시 써야하는 것들의 복잡성에 달려 있습니다 .

영어를 올바르게 작성하기 위해 내 게시물을 수정하는 것을 망설이지 마십시오. 대단히 감사합니다.

올리비에 폰

내가 일한 회사는 코드베이스의 주요 리 팩터를 시작했습니다.

팀의 절반이 리팩터링 작업을 수행하고 나머지 절반은 기존 제품을 지속적으로 유지 보수 및 개선했습니다.

당신이 상상할 수 있듯이, 리 팩터는 실제로 어떤 일이 일어 났는지 결코 알 수 없었습니다. 그것은 계속해서 보여줄 것이 없었던 지속적인 진행 과정이었습니다.

아이디어는 리팩토링 된 코드베이스로 작업하는 것이 더 좋을 것이며 팀이 기존 제품에 추가 한 새로운 기능을 "들어가서" "잡을"수있었습니다.

그러나 결국 회사의 몰락이되었습니다.

나는 지난 3 년 동안 큰 재 작성을 해왔다. 원래 우리는이 프로젝트에 2 년이 걸릴 것으로 추정했습니다. 기본 아이디어는 하드웨어를 교체하고 기존 OS를 사용하고 비즈니스 로직을 다시 작성하고 (c에서 CPP로) 새 IO 카드를 작성하고 새 UI를 작성하는 것이 었습니다.

그 과정에서 우리는 끔찍한 결정을 내 렸습니다. 우리는 CPP에 대한 실제 경험이 없었으며 그것을 잘 가르 칠 멘토도 없었습니다. 우리는 win32를 기반으로 UI 프레임 워크를 만들려고했습니다. 하드웨어가 싸고 BSP에 버그가있었습니다. 소프트웨어는 매우 유연했지만 유지 관리하기가 어려웠습니다. 작년에 우리는 자체 개발 한 UI를 버리고 .net에서 UI를 개발했습니다. 또한 지속성 메커니즘과 데이터 통신 프로토콜을 완전히 다시 작성했습니다.

많은 노력이 필요했지만 이제 프로젝트는 거의 끝났고 첫 번째 유닛은 현장에서 테스트되었습니다. 이 프로젝트는 성공의 변화를 가져올 위험이 컸습니다. 프로젝트에 대해 긍정적 인 점이 있었으며, VSS 대신 SVN을 사용하기 시작했으며 단위 테스트를 작성하는 데 시간이 걸렸으며 야간 빌드를 구현했습니다. 또한 프로세스 개선을 위해 스크럼을 사용하기 시작했습니다.

돌이켜 보면 비즈니스 로직을 다시 작성할 필요가 없다고 생각합니다. 가장 추악한 부분 만 리팩토링해야했습니다. UI를 처음부터 작성하려면 핵심 비즈니스가 아닌 이상하지 마십시오.

실제로 나는 큰 리팩토링을 시작하고 있습니다. 4MLoc는 800KLos 이하로 다운 사이징해야합니다. 이 프로젝트에는 많은 복사 및 붙여 넣기, 언어 기능에 대한 이해, 반복되는 쓸모없는 설명, 잘못된 결정, 임시 해킹 및 해킹이 영구적으로 적용 (해결 방법 포함), 컴퓨터 과학 또는 소프트웨어 공학에 대한 기본 원칙에 대한 지식이 부족 합니다. 리팩토링 후 32 명의 나쁜 프로그래머로 구성된 유지 보수 팀이 2 명의 좋은 것으로 대체 될 것입니다.

3 주 만에 블로그 엔진을 작성했습니다. 나는 그것을 8 시간 안에 다시 썼다.

성공적인 재 작성을 위해서는 미리 계획하는 것이 중요 합니다. 시스템 내부 및 외부를 아는 것도 이점입니다.

10여 년 전, 나는 노후화 된 핵심 제품을 "재 설계"하기로 결정한 회사에서 근무했습니다. 그 이후로 "재 설계"라는 단어를 언급하는 것은 처벌 가능한 범죄입니다. 예상보다 훨씬 오래 걸렸고, 비용이 더 많이 들었고, 새로운 제품은 초기 계획보다 이전 제품과 훨씬 유사했습니다.