경영진이 리팩토링에 노력을 기울 이도록 설득하기위한 논쟁을 찾고 있습니다.
Jira를 사용하여 작업을 기록하고 모든 svn-commit을 jira 호출과 관련시킵니다.
내 생각은 다음을 수행하는 것입니다.
- User-POV 및 Developer-POV (버그 수정) 모두에서 매우 잘못 구현되었지만 자주 사용되는 코드 영역을 수동으로 발견
- JIRA- 문제가 포함 된 svn-commits 가져 오기
- 일부 기준 (문제 유형, 버전, prio 등)에 따라 문제를 필터링합니다.
- 이 버그에 소요 된 시간 / 노력 계산
- 리팩토링의 노력과 위험 평가
- 숫자를 제시하고 고치려고 노력하십시오.
이것에 대해 어떻게 생각하십니까? 그러한 측정이 유용하고 설득력 있는가? 장단점은 무엇입니까?
답변
유효한 숫자를 제공 할 수 있으면 관리자가 행동 할 가능성이 더 높습니다. (논리와 비용 / 혜택을 이해할 수 있다면)
IMHO, 설득력있는 사례를 만들려면 그것이 얼마나 나쁜지를 보여주기 위해 다음이 필요합니다.
- 문제에 대해 기록 된 지원 문제 수
- 잘못된 코드 유지 보수 / 대역 지원 / 지원 수정 수행에 소요 된 시간
- 유지 보수 / 밴드 보조 / 지원을 수행하는 사람들의 시간당 비율에 따른 시간
- 이러한 아이템이 비즈니스에 얼마나 중요한지 보여줄 수있는 방법
리팩토링 사례를 만들려면 다음이 필요합니다.
- 이러한 나쁜 것들 중 3 가지를 각각 리팩토링하고 구현하는 데 필요한 시간
- 구현 비용 추정 (위에서 사용한 것과 동일한 시간당 요금)
이를 통해 리팩토링이 상위 3 개 항목 각각에 대해 3 건의 사건에 대한 지원 시간보다 훨씬 적은 시간이 소요되는 경우 시간을 절약 할 수 있습니다. 이 짧은 시간이
- n 건 이상의 지원 사건보다 적다
- 이 사건들에 대해서는 더 이상 이러한 사건이 발생하지 않을 것입니다.
그러나이 판매의 가장 어려운 부분은 다음과 같은 질문에 답할 것입니다. 많은 사람들이 귀하가하고있는 모든 지원에 대해 일정에 시간을 투자하지 않기 때문입니다.
X 관련 문제를 해결하는 데 시간을 소비하는 동안 현재 프로젝트 Y가 완료 될 때까지 얼마나 더 기다려야합니까 ????? (Gantt 차트에서 예측 및 예약 할 수없는 현재 지원 시간 싱크에도 불구하고)
의사 결정자와 의사 소통이 얼마나 잘되고 상황을 어떻게 이해하는지에 따라 달라집니다.
나는 이것이 분명히 가치가 있다고 생각하므로, 당신은 통계로 사건을 구축하는 연습을 얻고, 그들이 그것을하지 않더라도 스스로 시간을 절약 할 수 있습니다. 불행히도, 데이터에도 불구하고 모든 사람이 확신하기 쉽지는 않습니다. 행운을 빕니다!
답변
리팩토링은 버그도 도입한다는 점을 명심하십시오 (테스트에서 발견 할 수 있지만 그럼에도 불구하고 버그이므로 수정해야합니다). 사고로 Netscape를 당기지 마십시오. “리팩토링”에 대한 개인적인 정의에 따라 다릅니다. 어떤 사람들에게는 이것은 “모든 코드를 다시 작성”한다는 것을 의미하며 “내부 변경”을 의미합니다. 어떤 종류인지 어떻게 알 수 있습니까? 다음과 같은 질문을 해보십시오.
공용 인터페이스를 전혀 바꾸고 있습니까?
대답이 예이면 재 설계를 수행하는 것입니다. 대답이 ‘아니요’인 경우 리팩토링을 수행하고 있으며 특별한 승인없이 일상 활동 과정에서 수행 할 수 있습니다. 리디자인은 더 많은 버그를 생성하고 리팩토링은 일반적으로 수행하기가 더 쉽기 때문에 질문과 관련이 있습니다.
X가 1 년 전에 수행 된 리 팩터가 있거나없는 비용을 아는 사람이 없기 때문에 어려운 경우입니다. 내 경험상 실용적인 관리자는 항상 다음과 같은 이유로 이러한 종류의 문제를 해결합니다.
- 노력으로 인한 직접적인 수입원이 없음 (재무 비용, 청구 불가능)
- 추악한 작업 코드는 여전히 작업 코드이므로 문제를 해결하는 대신 문제를 일으킬 위험이 있습니다 (잠재적 품질 비용)
- 리팩토링하는 동안 다른 프로젝트가 지연됩니다 (시간 비용).
답변
이러한 모든 번호는 궁극적으로는 비용이 추측 양을 비교 귀하의 경우, 추측을 기반으로 하지 당신이 비용이 어떻게 됐을까 대 리팩토링 에 리팩토링을. 당신이 할 수있는 최선의 방법은 당신이 추측에 대한 일종의 수치적이고 사실적인 근거를 가지고 있으며, 당신은 꽤 좋은 것을 가지고 있다는 것을 보여주는 것입니다.
장점은 아마도 리팩토링하도록 설득하는 데 효과적 일 것이며 버그 수를 줄일 수 있다는 것입니다.
버그 수정에 소요 된 시간이 최소한 리팩토링에 소비 된 시간만큼 줄어들지 않는다면, 더 이상 리팩토링 할 수 없으며 아마도 “폐기 된”시간에 대한 책임이있을 것입니다 .
전체 프로젝트의 복잡성을 줄이거 나 기능을 쉽게 추가하여 디버깅 시간을 절약하는 것은 측정하기가 너무 어려울 수 있지만 이러한 기능이 있다고 말할 수는 있습니다.