버그 데이터베이스에서 리팩토링 추적

Question

소스 코드에 대한 모든 변경 사항이 버그 보고서나 기능 요청과 연관되어야 하고 해당 정책을 개혁할 방법이 없는 곳에서 작업한다고 가정해 보겠습니다.이러한 환경에서 코드 리팩토링(즉, 코드를 개선하지만 버그를 수정하거나 기능을 추가하지 않는 변경)을 처리하는 가장 좋은 방법은 무엇입니까?

• 버그 보고서를 작성하고 리팩토링과 연관시키세요.
• 기능 요청을 작성하고 리팩토링과 연결하세요.
• 버그 보고/기능 요청과 관련된 코드 작업을 하면서 리팩토링을 몰래 살펴보세요.
• 리팩토링을 수행하지 마십시오.
• 다른

모든 버그 보고서와 기능 설명은 관리자와 고객에게 표시됩니다.

Answer 1

나는 리팩토링이 처음부터 수행되어야 하는 방식인 "리팩토링 몰래" 접근 방식에 투표합니다."코드 청소"를 위해 리팩터를 리팩터링하는 것은 나쁜 생각 일 것입니다. 이것은 당신이 실제 이유없이 변화를하고 있음을 의미합니다.리팩토링은 정의상 버그를 수정하거나 기능을 추가하려는 의도 없이 수정하는 것입니다.KISS 원칙을 따르는 경우 처음부터 가장 확장 가능한 시스템을 만드는 방법에 대해 실제로 생각하지 않기 때문에 새로운 기능에는 최소한 약간의 리팩토링이 필요합니다.

Answer 2

코드 블록을 작업하는 경우 대부분의 경우 해당 코드 블록을 변경해야 하는 버그 수정이나 새로운 기능이 있고 리팩토링이 변경을 더 쉽게 하기 위해 변경 전에 수행되거나 변경 후 결과를 정리합니다.두 경우 모두 리팩토링을 해당 버그 수정 또는 기능과 연결할 수 있습니다.

Answer 3

우리가 일하는 방식은 다음과 같습니다:코드를 리팩터링하는 데는 타당한 이유가 있어야 합니다. 그렇지 않으면 왜 그렇습니까?

다른 기능이 동일한 코드를 사용하도록 허용하려는 이유인 경우 변경 사항을 다른 기능의 요청과 연결하세요.

더 빠른 것을 만들기 위해서는 더 빠른 'xyz'에 대한 기능 요청을 생성하고 변경 사항을 이에 연결하십시오. 그러면 고객은 귀하가 제품을 개선하고 있음을 알게 됩니다.

버그를 설계하려면 버그를 기록하세요.

내 환경에서는 정책을 시행할 수 없다는 점에 주목할 필요가 있습니다.그러나 영리한 관리자는 변경 사항에 대한 보고서를 얻을 수 있으며 커밋 텍스트에 버그/요청 참조가 없으면 후속 조치를 취합니다.

Answer 4

각 옵션을 살펴보겠습니다.

• 버그 보고서를 작성하고 리팩토링과 연관시키세요.

귀하의 의견으로는 원본 코드가 보안 위험을 초래하거나 충돌 또는 불안정성을 초래할 가능성이 있다고 생각되는 경우.위험을 설명하는 작은 버그 보고서를 작성한 다음 수정하세요.

• 기능 요청을 작성하고 리팩토링과 연결하세요.

기능 요청에 따라 리액터 코드를 작성하는 것이 더 어려울 수 있습니다.하지만 유효한 기능 요청을 사용하면 다음 요점으로 넘어갈 수 있습니다.

• 버그 보고/기능 요청과 관련된 코드 작업을 하면서 리팩토링을 몰래 살펴보세요.

유효한 버그나 기능이 있는 경우 버그를 수정하거나 기능을 추가하기 위해 x 함수를 약간 변경해야 했다고 명시합니다.

• 리팩토링을 수행하지 마십시오.

이는 애플리케이션 개선을 통한 자체 개발이 허용되지 않음을 시사하는 것 같습니다.개발자는 그렇지 않더라도 새로운 기술과 기술을 탐구하도록 장려해야 합니다.

• 다른

아마도 관련 회의에서 개선 사항에 대해 논의하면서 왜 변경해야 하는지 설득력 있는 이유를 제시할 수 있을 것입니다.그러면 최소한 다른 방법을 통해 코드를 몰래 삽입하지 않고도 변경 사항을 관리할 수 있습니다.

Answer 5

• 다른

그런 경직되고 터무니없는 정책이 있는 곳에서 일한다면 가장 좋은 해결책은 다른 직업을 찾는 것입니다!