소프트웨어 성공 / 실패 비율의 재 작성에 대한 실제 사례 연구가 있습니까?

나는 응용 프로그램의 재 작성이 나쁘고 프로그래머에 대한 사람들의 경험과 Joel Spolsky 가 주제에 대해 준비한 기사에 대한 여러 게시물을 보았지만 확실한 증거 나 사례 연구는 없습니다. Joel이 제시 한 두 가지 예와 여기에 다른 게시물이 있습니다. 나쁜 코드베이스로 무엇을하고 실제 연구를 기반으로 어떻게해야합니까?

예를 들어, 둘 다 오래된 레거시 코드를 가지고 있다는 것을 알고있는 두 명의 클라이언트가 있습니다. 그것들 중 하나는 재 작성이 재앙이었고 비용이 많이 들고 실제로 코드를 많이 향상시키기 위해 작동하지 않았기 때문에 계속 절뚝 거리고 있습니다. 그 고객은 재 작성자가 빨리 알게되면서 매우 복잡한 비즈니스 로직을 가지고 있습니다.

두 경우 모두 회사에 많은 수익을 가져다주는 미션 크리티컬 애플리케이션입니다. 다시 쓰기를 시도한 사람은 레거시 소프트웨어가 향후 어느 시점에서 업그레이드되지 않으면 벽돌 벽에 부딪 칠 것이라고 생각했습니다. 나에게 이런 종류의 위험은 성공적인 길을 보장하기 위해 연구와 분석을 보증합니다.

이것을 조사한 실제 사례 연구가 있습니까? 실제 연구를 기반으로 한 모범 사례, 함정 및 성공을 알지 못하고 주요 재 작성을 시도하고 싶지 않습니다.

여파 : 좋아, 더 많은 검색을 한 후, 사례 연구에 관한 세 가지 흥미로운 기사를 찾았습니다.

1. 다시 쓰거나 재사용하십시오 . 그들은 Java로 변환 된 Cobol 앱에 대한 연구를 수행했습니다.
2. 다른 하나는 소프트웨어 재사용 : 개발자 경험 및 인식 이었습니다.
3. 재사용 또는 재 작성 유지 비용과 재 작성에 대한 또 다른 연구.

: 나는 최근에 주제에 다른 기사를 찾을 위대한 재 작성을 . 그곳에서 저자는 몇 가지 주요 문제에 부딪힌 것 같습니다. 이와 함께 제안 된 새로운 기술 스택을 사용하고 개발자가 얼마나 빨리 그것을 픽업했는지 측정하여 프로토 타입을 만드는 아이디어가있었습니다. 이것은 모두 재작 문의 전주곡이었습니다. 훌륭한 아이디어라고 생각했습니다!

나는이 위대한 논평들에 대한 신용을 얻을 수는 없지만 원저자에 의한 답변에 결코 답변하지 않았으므로 커뮤니티 위키에 표시하고 있습니다.

사례 연구에 대해서는 잘 모르지만 접근 방식에 대한 표준 답변은 "단위 테스트 추가 및 리팩터링"이라고 생각합니다.

그것은 가능한 가장 낮은 위험 접근 방법으로 필자가 놀랐습니다. 물론, 나는 그것이 올바른 접근법인지 확신하기에 충분한 세부 사항을 알지 못하지만, 지금까지 내가 알고있는 것을 기반으로, 특히 훨씬 나아질 지 많이 알지 못합니다.

단위 테스트를 수행하면 (적절하게 모든 요구 사항을 파악) 리팩토링을 통해 진정한 재난을 초래할 수있는 방법을 마련하기가 어렵습니다. 일어날 수있는 최악의 상황은 원하는만큼 빨리 진행하지 않는다는 것입니다. 동시에, 코드베이스가 문제가 암시하는 것처럼 모양이 좋지 않으면, 경로를 막론하고 진행을 가능하게하기 위해 진지한 노력이 필요할 가능성이 매우 높습니다.

재 작성 프로젝트는 일반적인 프로젝트와 실패율이 크게 다르지 않으며 최상의 정보는 최신 CHAOS 보고서를 참조하십시오.

나는 미끄러 져 효과적으로 레거시 코드로 작업을 마이클 깃털에 의해 잠시 뒤로하고 (당신이 코드가 무엇인지 모르는 경우에도) 필기 시험을, 레거시 코드를 유지 포함한 실제 연습에 좋은 통찰력을 제공하는 발견의 과정 리팩토링 / 재 작성. 조금 오래되었지만 아마존에서 높은 평가를 받았습니다.

처음부터 엔터프라이즈 아키텍처를 제대로 구상하지 못한 회사에서 경험하고 생활하면서 말하면 가장 큰 문제는 포괄적 인 이해를 개발하는 것입니다.

시스템을 여러 조각으로 나눌 수 있고 개별적으로 이해 될 수 있다는 아이디어는 결함이 있습니다. 어느 시점에서 한 개인 또는 여러 개인이 전체 문제를 완전히 파악할 수 있어야했습니다. 그 문제가 일련의 비즈니스 문제와 그 원인이되는 기술이라면; 재난이나 누락 된 요구 사항없이 시스템을 교체 할 수있는 수준으로 모든 시스템을 이해하려면 회사의 직원이 몇 년이 걸릴 수 있습니다. 제가 기술 이사로 인수 한 회사의 경우도 마찬가지였습니다. 내가 자신이 코더라는 사실이 아니었다면 제대로 조직되지 않고 밀접하게 결합되어 있고 밀접하게 구속 된 아키텍처와 기술 통합에 대한 모든 세부 사항을 천천히 이해할 수 없었을 것입니다. 작은 숨겨진 문서화되지 않은 세부 정보가"We put the eBay order number in the "SYSOENT.PO_NUMBER" field in the ERP system because that's what Wendell the VB coder from Florida decided to do" 간과 될 수있는 결과는 간과 될 수 있으며, 이것을 아는 유일한 방법은 천천히 모든 것을 발견하는 것입니다.

센서, 유압 시스템을 재정의하는 방법, 연료 흐름을 다시 라우팅하는 방법을 알아야하는 적절한 양의 도구와 리소스를 고려하여 비행 중 누군가 항공기의 엔진을 교체하거나 특정 사망에 직면 한 경우 외부 또는 조종실에서 변경하거나 조작하도록 설계되지 않은 시스템을 조작하십시오. 이것은 종종 비즈니스 응용 프로그램을 다시 작성할 가능성과 같습니다. 응용 프로그램은 일반적으로 다른 여러 기술 사이에서 비즈니스에 투입됩니다.

나의 주요 요점은 시스템이 거의 복잡하다는 점에서 이해되어야하며, 새로운 시스템이 "제작 된"것이 아니라 적절하게 "엔지니어링"되기 위해서는 시스템의 완성도를 어느 정도 이해해야한다는 것입니다.

쿠키는 소프트웨어로 제작되어야합니다.

Netscape와 같이 재 작성으로 사망 한 회사의 사례가 많이 있습니다 . 트위터 같은 큰 문제없이 다시 쓰기 를 견뎌낸 회사들도있다 .

다시 작성하지 않은 비즈니스 성공과 재 작성의 비즈니스 성공을 살펴 보는 제어 실험을 수행하는 것은 불가능하기 때문에 정량화 된 사례 연구는 없습니다. 응용 프로그램마다 다릅니다.

재 작성이 의미가있는 명백한 경우와 그렇지 않은 경우가 많이 있습니다. 나는 당신의 경우에 재 작성이 의미가 있는지 알아 내기 위해 약간의 요리법을 요리했습니다 .

Rails, Grails, AngularJS와 같은 침습적 프레임 워크를 개선하기 위해 신속하게 코딩하고 있기 때문에 오늘날에는 다시 쓰기가 더 의미가 있다고 생각합니다. 일반 js에서 Angular로 이동하려면 다시 작성하면 할 수있는 모든 것입니다. 여전히 많은 의미가 있습니다. 하나의 diy 구현을 다른 구현으로 대체한다면 ( Joel Spolsky 기사의 모든 예제와 같이 ) 아마 미쳤을 것입니다.

조치 후 보고서 이외의 다른 많은 편견이없는 사례 연구를 찾지 못할 것입니다. 대부분의 사람들은 동일한 작업을 최소 두 번 (한 번은 다시 쓰기, 한 번은 업그레이드로, 가장 좋은 것으로) 지불하지 않을 것입니다. 경우에 따라 여러 팀에서 여러 번 다시 작성 / 업그레이드 할 수 있습니다).

발견 한 사례 연구는 Fujitsu에서 생산 한 것으로 보이며, 당연히 Fujitsu의 도구를 사용하는 것이 더 낫다는 결과가 나왔습니다.

조직의 관점에서 재 작성은 재 작성된 응용 프로그램이 작동하지 않거나 완료되기 전에 프로젝트가 취소 된 경우에만 실패입니다. 그렇지 않으면 재 작성된 버전을 릴리스하는 지연이 당신이 겪은 손실의 원인 또는 우연의 일치. 완료하기 전에 취소하면 일반적으로 총 시간과 자원 낭비로 간주됩니다. 업그레이드는 잠재적으로 동일한 문제를 일으킬 수 있지만 점진적으로 증가하는 것은 같은 규모에 있지 않을 것입니다 (돈을 위해 무언가를 얻습니다).

프로그래밍 관점에서 가장 좋은 사례는 서로를 지원하고 고무시키는 재 작성하는 동안 증분 업그레이드를 수행하는 것입니다. 다른 팀이 없으면 자연스럽게 시간이 더 오래 걸립니다.

이것은 전체 재 작성을 고려해야 할 때에 대한 대략적인 지침을 제공합니다. 프로젝트는 쉽게 수행 할 수있을 정도로 작거나 노력 또는 학습 비용을 계산할 수있는 충분한 양을 갖습니다. 할 보람 있는. 또한 재 작성이 재 작업을 따라 잡지 않으면 여러 가지를 의미 할 수 있지만 다른 모든 것이 동일하면 재 작성이 불필요하다는 것을 의미합니다.