나는 엄청나게 느슨한 제품의 기존 코드베이스를 물려 받았습니다. 근본적인 디자인은 불행히도 완전한 리 팩터 (HIGH 커플 링, LOW 응집력, 코드 중복, 기술 설계 문서 없음, 단위 테스트 대신 통합 테스트) 없이는 거의 할 수없는 일입니다. 이 제품은 역사, 위험에 대한 내성이 거의없는 중요한 "현금 소"고객에 대한 높은 노출, 그리스인을 홍당무하게 만드는 기술적 부채, 매우 큰 코드베이스 및 복잡성, 팀에 의한 전투에 대한 패배자 접근 방식을 갖습니다. 나를.
이전 팀은 다른 부서로 배를 뛰어 넘어 다른 프로젝트를 망칠 기회를 가졌습니다. 프로젝트 관리 실패와 반대로 기술적 무능력 프로젝트 실패를 경험하는 경우는 매우 드물지만 실제로는 그러한 경우 중 하나입니다.
지금은 혼자이지만 시간과 결정의 자유와 미래의 방향이 자유롭고 처음부터 팀을 구성 할 수있는 능력이 있습니다.
제 질문은 기능적 요구 사항 수집 단계에서 자유 시간이있을 때 이와 같은 프로젝트에서 영향이 적은 리팩토링에 대한 의견을 수집하는 것입니다. 수천 개의 컴파일러 경고가 있으며, 거의 모두 사용되지 않은 가져 오기, 읽지 않은 로컬 변수, 유형 검사 및 안전하지 않은 캐스트가 없습니다. 코드 형식은 읽을 수없고 조잡 해 파킨슨 병을 앓고있는 것처럼 보이며 주어진 줄에서 스페이스 바를 누르는 횟수를 제어 할 수 없었습니다. 추가 데이터베이스 및 파일 리소스는 일반적으로 열리 며 안전하게 닫히지 않습니다. 무의미한 메소드 인수, 같은 일을하는 중복 메소드 등
다음 기능에 대한 요구 사항을 기다리는 동안 갈 때 영향이 적은 저 위험 요소를 정리하고 시간을 낭비하거나 올바른 일을하는지 궁금했습니다. 새로운 기능이 이전에 시간을 보냈던 코드를 제거하는 것을 의미하는 경우 어떻게합니까? 나는 민첩한 접근 방식을 시작할 것이며 이것이 민첩한 개발 과정에서 끊임없이 리팩터링하는 것이 수용 가능하고 정상적이라는 것을 이해합니다.
내가 추가하고 싶은 긍정적 인 영향이나 부정적인 영향을 생각할 수 있습니까?