다른 작업을하는 동안 기존 결함을 수정해야합니까?

수수께끼 : 새로운 기능을 사용하거나 결함을 수정하는 과정에서 코드에 레거시 문제가 있습니다. 어떻게해야합니까? 이를 수정하고 코드의 동작을 변경시킬 위험이 있습니다. 지금까지 약간의 문제가 발생했거나 결함이 발견되지 않았거나 다른 사람이보고 할만한 가치가 없었습니다. 혼자 남겨두고 문제로 인해 나중에 코드를 다루기가 더 어려워 지도록해야합니까? 문제를 해결하면 원래 작업 시간 만 추가되고 회귀 테스트를 수행하게됩니다. 그 일에 감사 할 사람은 거의 없다. 그러나 그것을 고치는 것은 어떻게 든 옳아 보입니다. 문제가 적은 코드는 리팩토링 및 빌드하기가 더 쉽습니다.

우리는 웹 애플리케이션을 현대화하기 위해이 상황에서 몇 번이고 자신을 발견했습니다. 이 오래된 버그를 해결하기 위해 탄젠트 작업을 할 때 강박 관념인지 존경받을 수 있는지 알 수 없습니다. 이러한 상황을 어떻게 처리합니까?

고마워, 코리

나는 아주 작은 팀에서 일하기 때문에 변화가 무엇인지에 달려 있습니다.

작고 명백한 버그 수정이라면, 나는 분명히 그것을 위해 간다. 다른 사람의 코드와 "보이 스카우트 규칙"에 해당하는 다른 작은 개선 사항을 통해 작업해야하는 경우에도 추가 의견을 제시합니다.

코드가 너무 얽혀서 "이것을 바꾸면 테스트가 필요하다"고 물어야한다면 변경하지 말아야한다. 걱정이되는 경우 버그 추적 시스템으로 가져 오십시오.

이것이 우연히 더 명확한 유형 서명으로 더 작은 메소드를 코딩하려고하는 이유입니다. 부작용이없고 인 / 아웃을 일치시킬 수 있다는 것을 알고 있다면 위험없이 내부 코드를 수정, 재배치 또는 조정할 수 있습니다.

그러나 감사의 부족이 발견 한 버그를 수정하지 않거나 어떤 이유로 든 코드 기반을 개선하지 않는 이유는 아닙니다. 다른 것이 없다면, 당신은 미래에 친절하여 다른 무언가를 고치기 위해 다시 거기에있을 것입니다.

편집 : 또한 프로젝트에서 시간을보아야합니다. 분명히 마감 기한이 지남에 따라 주요 작업을 완료하는 데 집중해야하지만 "정상적 인 부하"에 처한 경우 여기를 약간 정리하면 장기적으로 모든 사람이 더 행복 해집니다.

항상 그렇듯이 그것은 다릅니다.

• 사소하고 고칠 수 있다고 확신하면 고치십시오.
• 단위 테스트가 많으면 아무 것도 깨지지 않았 음을 확신 할 수 있습니다.
• 그렇지 않으면 // TODO를 추가하고 버그 추적에 추가하십시오.

기본적으로 위험 평가를 수행하고 있습니다. 변화의 위험과 변화가없는 위험. 충분한 프로그래밍 경험이 없다고 생각되면 (일반적인 프로그래밍, 특히 시스템 사용) 팀의 다른 사람에게 문의하십시오.

Pragmatic Programmer는 이것을 'Broken Windows'라고 부릅니다.

깨진 창을 수정하지 않으면 코드 품질의 하향 나선형을 만드는 경향이 있습니다. 그리고 그것들이 많을수록 수정 작업이 더 커지므로 고정 될 가능성이 적습니다.

지금 또는 나중에 고칠 지 여부는 판단의 문제입니다. 간단한 수정입니까? 코드가 생각하는대로 작동하고 있습니까? 현재 작업을 방해 할 가능성이 있습니까? 시간 제약이 있습니까? 더 많은 버그가 발생할 가능성이 있습니까?

최소한 추적 시스템에 해당 항목을 표시하고 나중에 수정하십시오. 지금 수정하기로 결정한 경우에도 추적 시스템에 표시하고 테스트를 수행했는지 확인하고 변경 사항을 문서화하는 것이 중요합니다.

보안을 위반하거나 데이터를 손상 시키거나 사용자에게 표시되는 예외를 발생시키는 것과 같은 명백한 버그 인 경우 수정하십시오. 그렇지 않으면 코드베이스를 아는 사람에게 귀하보다 더 나은 것을 요청하십시오.

그것은 당신의 수정이 낮은 영향을 미친다고 확신하는 작은 버그라면 개인적으로 다른 작업의 일부로 수정 한 다음 PM에게 알릴 것입니다.

고객에게 위험 이 있는 경우 , 사용자 또는 회사는 프로젝트 관리자에게 연락하여 과정을 논의합니다. 위험을 평가하는 것이 그들의 일이므로주의를 기울이고 해결해야 할 경우에 집중하십시오. 그런 다음 그들의 결정을 존중하십시오.

우리 테스터는 이것을 싫어합니다. 아주 사소한 경우가 아니라면 버그 데이터베이스에 로그를 기록한 다음이를 릴리스에 할당하고 회귀 테스트를 작성하십시오. 개발자가 일정에 맞지 않는 변경 작업을 수행하려는 경우 마감일을 어떻게 유지할 수 있습니까?

중요하지 않은 결함이나 표준 위반이 "약한 코드"결함으로 제출 된 팀에 근무했습니다. 치명적인 결함을 발견 한 사람은 어떤 종류의 깃발을 던질 책임이 있습니다.

버그에 따라 다릅니다. 주요 관심사는 새로운 버그를 도입하는 것입니다. 알려지지 않은 문제보다는 알려진 문제를 처리하는 것이 좋습니다. 단순한 텍스트 변경 또는 간단한 논리 오류가 발생하면 수정하고 그렇지 않으면 그대로 두십시오.

한가지 주목할 점은, 우리는 4 명의 개발자와 인턴으로 구성된 작은 상점이며 내가 고치는 버그는 아마도 내가 만든 버그 일 것이다.

코드가 명백히 틀렸다면 수정은 매우 간단하며 사용자에게 영향을 줄 위험이 낮다고 생각하면됩니다. 그것은 전문적인 판단에 달려 있습니다.

당신이 그것을 발견했다면 아마도 사용자가 보지 않았거나 다른 사람들이 그것을 보지 않았다는 것을 기억해야합니다. 사용자가 겪을 수없는 문제를 해결하는 데 시간을 소비하지 말고 지금 사용자 문제를 일으키는 문제를 해결하는 데 시간을 투자하는 것이 좋습니다.

관찰 내용을 먼저 문서화하고 나중에 수정할 것인지 결정하십시오.

동료와 공식적인 토론 (예 : 정기 회의) 또는 비공식 토론 (예 : 점심 식사)을하고 수정하려는 코드의 동작에 대한 자신감을 얻은 후에 변경하십시오.

버그 / 결함 인 것처럼 보이지만 이번에는 실제로 "기능"일 수 있습니다. 이전 릴리스의 마지막 순간에 일부 문제를 해결하기 위해 제대로 구현되지 않은 솔루션 일 수 있으며 "깨끗한 수정"으로 인해 이전에 해결 된 일부 문제가 다시 발생할 수 있습니다.

나는 여기서 추세를 버릴 것이다. 초기 프로토 타입 개발 단계가 아니라면 즉시 수정하지 말고 버그 보고서를 작성해야합니다. 여기에는 몇 가지 장점이 있습니다.

• 팀은 그것을 평가하게됩니다. 실제 버그입니까, 수정의 위험은 무엇입니까?
• 경영진은 이번 릴리스에 포함되어 일정에 영향을 미칠만큼 중요한지 결정합니다.
• 그것을 탐지하는 방법은 테스트 스위트에 추가 될 수 있으며, 일반적으로 비슷한 오류를 찾을 수있는 충분한 방법이 있기를 바랍니다.
• 이전 단계에서 얼마나 많은 버그가 발생했는지에 대한 유용한 지표를 제공합니다.