코드 리팩토링 시간을 정당화하는 방법?

70k LOC 이상의 매우 큰 프로젝트가 있어야합니다.

이 프로젝트에는 Core Framework 및 다른 부분에서도 일부 코드 리팩토링이 필요합니다. 리팩토링 프로젝트를 시작할 때 정해진 시간이 없었습니다. 그러나 시간이 흐르면서 40 명 이상의 개발자가 프로젝트를 공동으로 진행했습니다. 내 관점에서 볼 때 필연적입니다.

적절한 소프트웨어 개발 원칙을 주장하고 방어하는 데있어 핵심은 무엇입니까?

레거시 또는 브라운 필드 응용 분야에서 작업 할 때는 모든 것을 다시 형태로 리팩토링하기 위해 "스프링 클리닝"을 시도하고 있습니다. 그것은 결코 자원의 정당한 사용이 아닙니다. 결국, 작업 소프트웨어 개발을 중단하는 방법 (작업 코드 만 리팩토링 가능)은 어떻게 결정될 수 있습니까? 빅 리팩토링 단계에 소요 된 시간이 나중에 지불되고 프로젝트에서 퇴보를 일으키지 않을 것이라고 보장 할 수 있습니까?

코끼리는 어떻게 먹습니까? 한 번에 한 입. 새로운 기능을 구현하거나 버그를 수정해야 할 때마다 해당 부분을 개선해야하는지 확인할 수 있습니다. 보이 스카우트 규칙에 따르면 : "항상 캠프장을 찾은 것보다 더 깨끗하게 두십시오." 리팩토링은 별도의 단계가되어서는 안되며, 매일 개발의 일부입니다.

이러한 품질 문화를 개발 팀에 도입하면 품질이 향상됩니다. 그 후 경영진에게 정당화 할 것이 없습니다.

일반적으로 리팩토링은 코드를 변경해야하는 또 다른 변경을 가능하게하거나 코드를 변경 한 후 자연스러운 정리 단계로 수행해야합니다. 이 경우에는 정당화 할 것이 없습니다. 리팩토링은 단순히 프로젝트 작업을 수행하는 프로세스의 일부입니다. 리팩토링을 수행 할 때 수행 한 작업에 시간이 청구됩니다.

조금씩 증가하지 않으면 실제로 리팩토링하지 않습니까?

여기에 모든 좋은 답변이 있지만 이것에 비즈니스 차원을 추가 할 수 있습니다. 왜 / 왜 그렇게 물어 볼까요 ? (뾰족한 머리 보스 (PHB)를 생각하십시오 :)

PHB : 왜요?
당신 : 그것은 일을 더 쉽게 만들 것입니다
PHB : 무엇?
당신 : 그것은 처리량을 증가시킬 것입니다 – 우리는 더 빨리 새로운 건물을 만들 수 있습니까?
PHB : 무엇?
당신 : 어 ... 행복한 고객?
PHB : WTF?
당신 : 나는 추천 증가, 더 큰 만족, 
     낮은 처리 시간으로 인해 더 많은 이익을 더 빨리
PHB : 아! 좋은 소리. 그러나 그것은 단지 "소리"만 볼 수 있습니까?
당신 : WTF?
PHB : 돈을 보여줘! (즉, 숫자를 입력하십시오)
당신 : 아! Brb ... (가서 간단한 스프레드 시트에 숫자를 입력하여 사례를 작성)

기본적으로 비즈니스 사례 를 만들어야합니다. 몇 가지 숫자를 실행하여 사고 과정을 명확하게하고 숫자가 '이익'을 객관적으로 반영하도록합니다. 소요 시간, 대략적인 비용 등도 알 수 있습니다. 그것이 가치가 있다면 녹색 신호를 얻고 아마도 이니셔티브를 주도 할 것입니다 :)

모든 것을 어떻게 측정 할 수 있다고 생각한다면이 책을 사용해보십시오

다른 활동과 마찬가지로 리팩토링에는 명확한 목표가 정의되어 있어야합니다. 목표가 명확 해지면 현재 프로젝트 상태와 수명주기 단계를 고려하게됩니다. 80 % 완료, 30 % 뒤쳐진 개발 프로젝트의 경우 앞서 설정 한 목표에 따라 리팩토링 노력을 정당화해야합니다. 이 예제에서 코드 조각이 단위 테스트되었고 개발 환경에서 제대로 작동하면 리팩토링을 정당화하기가 어렵습니다.

40 명의 개발자가 떠난 사실은 들리는 것처럼 극적이지 않을 수 있습니다. 나는 그 개발자들이 검토하고 테스트 한 작업 코드를 제공했을 것으로 기대합니다. 따라서이 코드에 알려진 문제가 없으면 그대로 두십시오. 아이디어는 귀하와 같은 큰 프로젝트에서 표준과 절차가 있었고 코드가 완전히 엉망이 아니라고 기대합니다.

리팩토링은 모든 테스트가 반복되는 것은 아니지만 많은 원인이 될 수 있음을 기억하십시오. 또한이 크기의 리팩토링은 한 두 명의 선임 멤버가 수행 할 수 없으므로 리팩토링은 존재하지 않는 문제를 유발할 수 있습니다. 이것은 무시해서는 안되는 위험입니다.

그러나 예기치 않은 일이 발생했을 때 프로젝트에 작업을 추가하는 것은 드문 일이 아닙니다. 따라서 개발자가 어떤 이유로 사라 졌다면 이는 특별한 성격의 사건으로 간주되며 상황을 해결하기위한 조치가 취해 져야합니다. 화재 나 지진 등으로 취급 될 것입니다.

요약하면, 좋은 기술적 이유없이 큰 프로젝트에서 큰 작업 코드를 리팩터링하지 않을 것입니다. 특히 우리는 대부분의 프로젝트가 일반적으로 늦은 상태임을 알고 있습니다.

길고 거대한 벽 앞에 있다고 상상해보십시오. 반대쪽으로 가야합니다.

문을 만들기 위해 벽을 리팩터링하거나 주변을 둘러보십시오.

두 솔루션의 시간을 모두 예측하면 리팩토링에 대한 정당성이 확보됩니다.

두 번째 해결책의 시간에 벽 반대편으로 가야하는 사람들의 수를 곱하는 것을 잊지 마십시오.

다른 답변 중 하나를 읽으면서 한 번에 한 입씩이 코끼리를 먹으십시오. 팀원이 지리적으로 분산되어있는 대규모 국제 프로젝트 감사에 참여하고 있습니다. 팀은 소프트웨어의 첫 두 버전을 구축 한 후 접근 방식, 코딩 스타일 및 솔루션 구축 방식이 일치하지 않는다는 데 동의했습니다. 그들은 새로운 규칙과 규칙에 따라 응용 프로그램의 새로운 부분을 작성하기로 동의했으며 이전 코드 중 일부를 변경해야 할 때 먼저 새로운 규칙을 충족시키기 위해 리팩토링합니다. 모든 것이 잘 작동합니다. 리팩토링 프로세스는 거의 5 개월 만에 이루어지며 일부 코드는 리팩토링되고 일부는 아직 리팩토링되지 않습니다. 새로운 기능은 시간 내에 제공되며 고객은 행복하고 개발자는 행복합니다. QA 팀도 행복합니다. 상생 상황 :)

리팩토링의 주요 요점은 미래에 일을 더 쉽게 만드는 것입니다. 지속적인 리팩토링없이 거의 수행하지 않은 다수의 장기 프로젝트를 비교하지 않으면 리팩토링의 이익을 보여줄 수 없습니다. 리팩토링은 유지 관리 비용과 변경 구현 비용을 줄이는 것이 일반적으로 개발자들 사이에서 받아 들여지지 만 비즈니스 관점에서 증명하기는 어렵습니다. 리팩토링을 구현하는 주요 이유는 기술 부채 를 줄이는 것 입니다.

또한 리팩토링은 지속적인 프로세스 여야하며 리팩토링에 소요되는 시간은 개발 작업 자체에 포함되어야합니다. 특별한 "리팩토링 작업"을 갖는 것은 좋은 생각이 아닙니다.