"코드 개선"의 우선 순위와 심각도를 결정하는 방법은 무엇입니까?

버그 추적 시스템에는 "우선 순위"및 "심각도"필드가 있습니다. 우리는 심각도를 "사용자에게 미치는 영향"으로 정의하고 우선 순위를 "제품에 미치는 영향"으로 정의합니다.

내 질문은 "코드 개선"작업을 심각도와 우선 순위로 분류하는 방법에 관한 것입니다. 개선 사항이 동작을 변경하지 않고 "더 나은 코드"로 만든다고 가정합니다. 전체적으로 장기적인 유지 보수 개선이 예상되지만 수량화하기는 어렵습니다.

우선 순위와 심각도에 대한 정의를 사용할 때, 장기적인 이점을 예측하기 어려운 그림이 없다면 코드 개선은 두 가지 모두에 대해 가장 낮은 값을 얻습니다. 따라서 코드 개선은 어려운 작업이므로 절대 시도해서는 안된다는 것을 의미합니다.

그러나 코드를 지속적으로 개선하고 리팩터링하는 것은 매우 비판적이라고 생각합니다.

• 소프트웨어 개발 자체는 지속적인 학습 과정이며 코드를 개선하지 않으면 더 나아질 수 없습니다.
• 팀은 자신의 코드를 자랑스럽게 생각해야합니다.
• 향후 유지 관리에 소요되는 시간이 줄어들고 장기적으로 절약되는 비용이 크게 늘어납니다.

또는 그러한 작업을 절대로 생성해서는 안되고 그러한 개선 사항은 "버그와 관련하여" "주문형"으로 만 수행한다고 생각하십니까? 버그와 관련되어 있어도 코드 검토에 대한 논의의 요지는 아닙니다. 예를 들어 "왜 이렇게 구조를 크게 변경 했습니까?"

일반적으로 코드 개선 자체가 사용자 스토리 또는 요구 사항을 완료하는 데 직접적인 영향을 미치지 않기 때문에 "코드 개선"활동을 별도의 할당 가능한 작업으로보고 싶지 않습니다. 이것이 코드 개선 작업이 항상 할당되지 않은 우선 순위가 낮은 이유입니다.

코드 개선은 일정하다고 생각합니다. 모든 개발자가 키보드를 입력하는 것처럼 자연스럽게해야합니다. 나는 그것을 어떤 작업에 대한 나의 추정치에 포함시킨다. 내 임무가 오랫동안 보지 않은 클래스 나 소스 코드를 만지는 것과 관련이 있다면, 일부 교묘 한 작업이 순서대로 진행되어 있다고 가정하고 그에 따라 내 추정치를 증가시킵니다.

최상의 시나리오 작업을 조기에 끝내고 남은 시간을 사용하여 코드 나 디자인을 개선 할 수 있습니다. 최악의 시나리오 작업이 예상보다 훨씬 오래 걸리지 만 추가 시간을 버퍼로 사용합니다.

코드를 리팩터링하려면 정의에 따라 태스크의 우선 순위를 설정하십시오 (예 : "제품에 미치는 영향"). 일부 리팩토링은 필요한 작업 범위에 따라 제품에 많은 영향을 미치지 않으며 일부는 영향을 미칩니다. 우선 순위를 높게 설정하면 리팩토링이 완료된 후 예상치 못한 일이 발생하지 않도록 더 많은 테스트를 수행해야 함을 나타냅니다.

이러한 종류의 작업을 "리팩토링"작업으로 분류하기 위해 버그 추적 시스템에 새로운 범주를 도입 할 수도 있습니다. 이 방법으로 우선 순위 값을 해석하는 방법을 알 수 있습니다. 즉, 우선 순위가 높을수록 더 큰 영향을 미치므로 더 많은 테스트가 필요합니다.

누락 된 것은 기존 코드에 대한 가정을 확인하는 것입니다. 코드를 개선하면 시간이 절약되고 비용을 크게 절약 할 수 있습니다. 이 화장품입니까 아니면 심각한 문제가 있습니까?

디버깅 및 개선 예상치를 확인하십시오. 시간이 더 걸리고 코드를 먼저 리팩토링하거나 정리해야하는 것에 대한 지속적인 의견이있는 경우, 이것이 최선의 측정 일 수 있습니다. 그런 다음 코드베이스를 다음과 같이 식별 할 수 있습니다. 양호, 약간의 재 작업 또는 심각한 리팩토링이 필요합니다.

이 모든 것은 상대적입니다. 더 많은 기능을 원하는 고객이 청구 가능 시간을 즉시 지불 할 의사가있는 경우이 우선 순위를 높이기가 어렵습니다.

흥미로운 질문입니다.

코드 줄 수와 변경 사항에 영향을 줄 수있는 모듈 수를 추정해야한다고 생각합니다.

어쩌면 단위 테스트가 몇 개인 지 변경하면 변경 될 수 있습니다. 이것은 아마도 지점에서 변경을 시도하여 아이디어를 얻는 것을 의미합니다.

그런 다음 이러한 일치 레벨 우선 순위 및 심각도에 대한 임계 값을 갖습니다.

또한 테스터 테스트가 많이 필요하다는 점을 고려해야합니다. 변경 사항이 앱의 넓은 표면 영역에 닿으면 많은 시스템 테스트를 다시 방문해야 할 수 있습니다.

여기서 두 가지 가정을 시작하겠습니다.

1. 모든 새로운 이야기에 대해, 당신은 가능한 한 팀의 주변 지식을 바탕으로 코드를 작성합니다.
2. 기존 코드의 기능을 변경하는 스토리가있을 때마다 시스템에 대한 새로운 지식과 더 나은 기술을 사용하여 새 스토리를 구현하는 과정에서 코드를 향상시킵니다.

이러한 두 가지 가정을 고려할 때 명시적인 "코드 개선"노력이 필요하지 않습니다. 시스템을 작성할 때 코드가 향상됩니다. 즉, 모든 코드가 유지 관리성에 대한 최신의 가장 큰 표준에 해당하는 것은 아니지만 "만약 깨지지 않았다면 해결하지 마십시오"라는 의미입니다. 불필요한 가시적 기능을 추가하는 것만 큼 "골드 도금"으로 변경할 필요가없는 리팩토링 코드를 고려합니다. 코드가 어떤 식 으로든 깨진 경우 실패한 유효한 테스트를 작성하십시오. 버그를 기록; 그런 다음 버그를 해결하기 위해 리팩터링합니다.

나는 민첩한 운동에서 투표를 훔칠 것입니다 :

버그를 입력하고 심각도와 우선 순위를 대략적으로 추측하십시오.

그런 다음 매일, 매주 또는 매월 새로운 버그를 모두 검토하고 등급에 투표하십시오. 이상적으로는 최종 사용자와의 스프린트 계획 회의에서이 작업을 수행합니다. 그런 다음 그 당시의 다음 기능에 대해서도 이야기하고 긍정적일 수 있습니다.