기본적으로 구조가없는 프로젝트를 수정하는 방법은 무엇입니까?

저는 5 년 넘게 주로 솔로로 소프트웨어 프로젝트를 진행하고 있습니다. 시작하는 것은 엉망이었습니다 (저는 작업하는 세 번째 또는 네 번째 개발자입니다). 엉망이 아니지만 지금은 여전히 ​​엉망입니다. 그것을 통제하는 과정의 진행률은 빙하 적이며 현재 상태에 대해 낙담하기 시작합니다. 어떻게 고치려면 어떻게해야합니까?

프로젝트 세부 사항 : MySQL 백엔드와 C #으로 작성된보고 엔진을 사용하여 거의 VB6 (Visual Basic Classic)으로 작성된 판매 프로그램입니다. C #보고 모듈은 작업의 즐거움으로, 지난 몇 년 동안 만 작성되었으며 Crystal Reports 9에서 모든 보고서를 작성하기 전에 작성되었습니다 (예, 여기에 의존하는 보고서가 여전히 있습니다).

그러나 실제 프로그램 자체는 완전한 재앙입니다. 총 90k LOC는없고 약 10k 줄의 주석이 있습니다 (주로 문서는 아니지만 주석 처리 된 이전 코드). 양식 파일 158 개, 모듈 파일 80 개 프로그램의 일부 기능은 단순히 더 이상 사용되지 않으며 관련 코드를 프로그램에서 제거하지 않고 (때로는) 언급하기 때문에 실제로 얼마나 많이 사용되는지 알 수 없습니다. 코드의 50 %만이 실제로 생산적으로 사용되는 것 같습니다.

하나의 모호한 클라이언트가 의존하는 것을 깨뜨릴 수 있는지 확실하지 않기 때문에 많은 코드를 터치하는 것이 두렵습니다. 코드 전체에 지뢰가 흩어져있는 것과 같습니다.

프로젝트에는 실제로 구조가 없습니다. 내가 지금까지 개혁을 인내 한 소수의 장소를 제외하고는 객체 지향이 아니다. 폼에서 데이터를 가져와야하는 경우 데이터베이스 개체를 인스턴스화하고 함수에서 쿼리를 바로 선언 한 후 실행하고 데이터 세트로 수행 할 작업을 수행하십시오.

프로젝트 작업을 시작했을 때 사용중인 소스 컨트롤이 없었습니다. 나는 다른 사람들이 그것을 사용하도록 격려하려고 노력했지만, 나는 새로운 사람이었고 사람들이 전복을 사용하도록 시도했지만 실패했습니다. 이 회사의 수석 개발자는 지난 몇 년 동안 마침내 수은 버그를 발견했으며 모든 개발자가 현재 모든 프로젝트에서 소스 제어를 사용하도록했습니다.

풀 타임으로 프로젝트를 개혁 할 수 있었다면 괜찮은 진전을 이룰 수 있었으며 프로젝트를 완전히 개조하는 데 걸리는 시간을 예상 할 수도 있지만 적극적으로 사용하고 있습니다. 계속해서 불을 끄고, 버그를 수정하고, 기능을 추가하는 등의 요청을받습니다.

이 프로젝트를 어떻게 고칠 수 있습니까? 다른 언어로 VB6 도구를 사용해보십시오. 여가 시간에 프로그램을 다시 작성해보십시오. 아니면 완전히 희망이 없습니까?

최신 정보

이 글을 읽은 후 나는 새로운 열정으로 프로젝트로 돌아 갔지만, 느린 진행 속도를 본 후 몇 개월 안에 절망에 빠졌습니다. 그런 다음 내년 정도에 걸쳐이주기를 2 ~ 3 회 더 반복했습니다.

나는 다른 직업으로 옮겼습니다. 수년간의 vb6과 다른 기술에 대한 주변 경험만이 있었지만 검색이 어려웠고 그 과정에서 많은 거부에 직면했습니다 (1 년 동안 약 12 ​​건의 인터뷰). 이 상황에서 다른 사람들에게 내 충고는이 요소를 혼자 떠나는 것을 고려하는 것입니다. 이와 같은 막 다른 위치에 머물면서 경력에 미칠 수있는 피해를 고려하십시오.

이제 소스 제어에 있으므로 주석 처리 된 코드를 제거 할 수 있습니다.

비슷한 상황에서 시작했습니다 (소스 제어, 실제 구조, 거의 모든 이벤트 핸들러에서 수행되는 80KLOC VB6 앱).

약 2 년 동안 온 / 오프에서 절반 이상이 C #으로 변환되었습니다 (일반적으로 중요한 새 기능이 필요한 경우). 모든 새로운 C # 코드에는 단위 테스트 적용 범위가 있습니다. 그래도 C #으로 변환하는 데 더 많은 시간이 걸립니다. 중요한 새 모듈을 추가하지 않으면 해당 경로를 따르지 않습니다.

내가 한 일은 데이터베이스에서 자동 생성되는 기초적인 데이터 액세스 계층을 만드는 것이 었습니다. 적어도 테이블 열 이름이 변경되어 코드에서 모든 위치를 찾지 못한 문제가 발생했습니다. 또한 비즈니스 로직을 양식 이벤트 처리기에서 모듈로 천천히 이동했습니다.

그러나 응용 프로그램이 내부 전용이라는 이점이있었습니다. 배포 할 사이트가 하나뿐이므로 사용자보다 더 큰 위험을 감수 할 수 있습니다. 내가 실수를했다면 대개 고치는 것이 큰 문제가 아니 었습니다. 그런 사치가없는 것 같습니다.

정말 최선의 방법은 다음과 같은 접근법을 취하는 것입니다.

1. 각별한 세부 사항을 익히십시오. 이로 인해 실수로 무언가를 깰 가능성이 줄어 듭니다.
2. 분리와 구조를 개선하기 위해 무자비하게 리팩터링하지만, VB6가 그것을 빨아 들이기 때문에 객체 지향 프로그래밍과 같은 새로운 방법론을 구체화하려고하지 마십시오.
3. 그것을 학습 경험으로 취급하십시오. 열등한 방법을 본 적이 없다면 다른 방법이 더 나은지 어떻게 알 수 있습니까?
4. 작성할 주요 모듈이없는 한 새로운 언어 / 프레임 워크 / 플랫폼으로 다시 쓰지 않아도됩니다. 그럼에도 불구하고 신중하게 고려하십시오.

프로그램의 목표는 회사의 돈을 버는 제품이라는 것입니다. 그것은 완벽한 예술 작품 일 필요는 없습니다 (그리고 저는 완벽 주의자이므로 인정 하기가 정말 어렵습니다). 때로는 실용주의를 포용하는 것이 좋습니다.

엄청난 양의 레거시 코드를 유지 관리하는 COBOL 프로그래머가 많이있을 것입니다. 나는 그들이 새로운 언어로 그것을 다시 쓰는 데 미친 듯이 일하고 있다고 의심합니다. :)

당신이해야 할 일은 리팩토링입니다. 리팩토링은 단위 테스트가없는 상황에서 거의 불가능합니다. 따라서 단위 테스트 작성부터 시작하십시오. 종이의 코드 동작을 문서화해야하지만 더 많은 코드에서는 단위 테스트를 문서화해야합니다. 테스트가 완료되면 코드 재구성을 시작할 수 있습니다.

David Agan의 " 디버깅 " 규칙 중 하나가 떠 오릅니다. 많은 양의 텍스트를 처리 할 수있는 기계를 마음대로 사용할 수 있습니다. 더 이상 사용하지 않는 코드를 정확하게 파악하고 자비없이 제거하십시오. 실수를한다면 그게 소스 컨트롤입니다.

쉬운 부분입니다. 다음에 생각해야 할 것은 코끼리를 어떻게 먹습니까? 한 번에 한 입. Martin Fowler의 " 리팩토링 "을 선택하여 파일별로 기능별로 가져갑니다. 무언가를 완전히 긁어 내고 요구 사항이 생각하는 것에서 다시 쓰지 마십시오. 등산가처럼 일하고 다음 안전 장치가 설치 될 때까지 이전 안전 장치를 제거하지 마십시오.

아직 은유가 충분 했습니까? 요점은 함수의 이름을 바꾸거나 분할하는 것만 큼 간단하게 많은 기능을 개선하여 느리고 꾸준하게 수행하면 수년간의 디버깅 및 기능 요청을 통해 구축 된 코드의 좋은 부분을 파괴하지 않고 코드의 나쁜 부분을 개선 할 수 있다는 것입니다 . 코드를 항상 배송 할 수 있기를 원합니다. 더 현대적인 언어로 포팅하는 동안 그렇게 할 수 있다면 그것을 찾으십시오.

나는 그것을 말하기를 싫어하지만 패치 / 향상의 끝없는 순환을 계속하는 것 이상으로 "완전히 희망이없는"것으로 가고 아무것도 깨지 않기를 바랍니다. 나는 당신이 묘사 한 것과 같은 너무 많은 VB6 프로젝트를 보았고 C # / .NET으로 리팩토링 / 재 작성 / 다시 실행하려는 시도는 종종 실패했습니다. 종종 시도를 담당하는 사람들이 해고당했습니다.

문제는 처음부터 완전히 다시 작성해야한다는 것입니다. 이를 지원하는 VB6 및 Windows 버전은 감소하고 있습니다. VB6의 단점을 알고 있고 이와 같은 프로그램에 기꺼이 참여하려는 개발자를 찾는 것이 점점 더 어려워지고 있습니다. VB6의 내부 한계는 이와 같은 거대한 프로그램에서 발생하여 이상한 오류가 발생합니다.

이 시점에서 전체, 기초, 재 설계 및 재 작성에 대한 합의와 약속이 있다면, 작업을 시작하고 다른 사람 (계약자, 하급 프로그래머, 자신에게 적합한 것)에게 지속적인 유지 보수를 위임하십시오. 사람들이 아직 이것을 시작하기에 충분하지 않다면 고통이 커질 때까지 기다리거나 녹색 목초지로 넘어가십시오.

여기에 좋은 대답이 있습니다. 한 가지를 추가하고 싶습니다. 모든 것을 다시 쓰려고 시도하는 대신 아마도 그 모듈 중 적어도 일부를 대부분 1 : 1로 VB.NET에 이식 할 기회가있을 것입니다. 내 경험에 따르면, 기존의 모든 기능을 처음부터 다시 작성하는 것보다 5 ~ 10 배 적은 노력으로 이러한 이식 작업을 수행 할 수 있습니다. 당신이 그것을 이식 한 후, 다음 당신은 리팩토링을 시작할 수 있습니다 - 등 좋은 단위 테스트 도구, 자동 리팩토링 도구, 실제 OOP처럼 .NET의 세계에서 사용할 수있는 모든 도구

비슷한 16 비트 C ++ 프로그램 (150k LOC)을 32 비트 월드로 마이그레이션해야했던 비슷한 상황에 처해있었습니다. 원래 GUI 프레임 워크를 더 이상 사용할 수 없었습니다. 재 작성이 비현실적이라는 것을 이해하는 데 약간의 시간이 걸렸지 만 C ++, C ++ / CLI 및 C #을 사용하여 .NET 세계로 이식하기로 결정한 후에는 약 9 개월이 소요되었습니다. 그 프로젝트에서 풀 타임으로 일하고 있습니다). 우리는 사용 가능한 GUI 부분에 대한 단위 테스트가 없었으며 수동으로 해당 부분에 대한 모든 테스트를 수행했습니다.

스티븐 맥코넬 (Steven McConnell)은 VB6에서해야 할 중요한 일이긴하지만 응용 프로그램을 단위 테스트하는 데 많은 역점을두고 있지만 그러한 프로젝트를 다루는 방법에 대한 훌륭한 책을 썼습니다.

한번보세요 :

Steven C. MCCONNELL : 레거시 코드로 효과적으로 작업하기 제 2 판. Microsoft Press, 2004 년 6 월

기본적으로 그의 요점은 한 번에 한 비트 씩 천천히하는 것입니다. 또한 리팩토링 기술을 사용하여 무언가를 깰 가능성이 거의없고 때로는 단기적으로는 조금 더 나빠질 수 있으며 코드가 깨끗 해지고이를 지원하기위한 단위 테스트가있을 때 고급 기술을 사용하는 것이 좋습니다.