버그가 5 세 이상인 경우 기능입니까? [닫은]

세부 정보를 추가 할 수 있습니다. 많은 코더, 테스터, QA 분석가, 제품 소유자 등이있는 기관에서 근무하며 여기에 버그가 있습니다.

우리는 10 년 넘게 크 래피 (아주 기능적인) 소프트웨어를 판매 할 수있었습니다. 그것은 많은 기능을 가지고 있으며 제품은 경쟁력이 있지만 몇 가지 심각한 버그와 수천 가지 "종이 삭감"이 있습니다-고객이 익숙해 져야하는 작은 성가심.

컴퓨터가 우리의 삶을 더 편하게하는데 도움이되지 않는다면 우리는 그것들을 사용해서는 안된다는 것을 굳게 믿고 있기 때문에 일부 것들을 살펴 보는 것은 저를 고통스럽게합니다. 나는 동료들에 대해 확신을 가지고 있습니다. 그들은 똑똑하고 능력이 있으며, 집중할 때 일을 개선 할 수 있습니다.

그러나 일부 이전 기능에 대해 버그를 닫거나 잊어 버리지 않으면 버그를 신고하기가 어려울 수 있습니다. "이온을 위해 그렇게 작동했다"는 전형적인 대답입니다. 또한 QA가 회귀를 수행 할 때 옳지 않은 것만 큼 다른 것을 찾는 경향이 있습니다. 따라서 "나의 시간이되기 전에도 그렇게 되었기 때문에"오래된 문제에 대한 해결책을 버그로 작성할 수 있습니다.

내 젊은 코더는 생각합니다 :이 괴물을 다시 작성하십시오! 영업, 고객과 가까이 할 수있는 기회를 가진 사람으로서 저는이 방법에 의문의 이익을주고 싶습니다.

귀하의 의견 / 경험에도 관심이 있습니다. 위험, 혜택 비용 및 기타 비 기술적 요소를 고려하십시오.

나는 너의 고통을 느낀다.

그러나 버그이기 때문에 무언가를 고치는 것은 충분한 이유가 아닙니다.

수정 사항이 다른 코드 (사용자 코드뿐만 아니라 코드를 사용하는 클라이언트 코드)를 위반하지 않도록해야합니다. 수정 프로그램을 배포하여 모든 고객 시스템을 망가 뜨리면 불만족스러운 고객이 생길 수 있습니다.

오래된 시스템을 대체하기 위해 새로운 코드가 작성된 유명한 예가 많이 있습니다. 사용자가 해당 버그에 의존하기 때문에 이전 시스템에서 버그의 기능을 명시 적으로 추가 해야하는 곳 (이름을 지정하지는 않지만 Google에서 할 수 있다고 확신합니다).

회귀 테스트는 기본적으로 고객이 기대하는 바에 대한 테스트입니다. 회귀 테스트를 제거하기 전에 누군가에게 상처를 입히지 않도록하십시오 (이것은 거의 불가능합니다). 당신이 버그를 고칠 수있는 경우 및 이 회귀 테스트를 아프게하지 않습니다 다음은 실제 수정합니다.

버그 수정을 결정할 때 고려해야 할 사항 ... 모두 포함되지는 않습니다.

• 중요합니까 (시스템 충돌)? ... 확실히 이것들은 고정됩니다.
• 고객이 종종 그것에 대해 불평하고 있습니까? 코드에서 무언가가 깨졌을 때의 버그 일 수도 있고, 기능이 사용자에게 친숙하지 않거나 다르게 작동하는 것과 같은 요구 사항 버그 일 수도 있습니다.
• 비즈니스 관점에서 버그를 수정하거나 새로운 기능을 구현하는 것이 더 유리합니까?
• 버그가 상당히 구조적인 변경을 필요로합니까? 아니면 다른 서브 시스템에 크게 의존하는 시스템의 일부입니까? 이는 테스트 시간에 큰 영향을 미치고 버그를 검증하는 데 필요한 테스트 범위를 복잡하게 만들 수 있습니까? 실제로 오래된 경우 버그가있는 코드 섹션을 수정하여 시스템에 어떤 영향을 줄지 정확히 이해하기가 어렵습니다.
• 버그가 많은 시스템으로 인해 잠재 고객을 잃고 있습니까?

버그를 정의하십시오. "사양은 날짜별로 정렬되어 있지만 거래 금액별로 정렬되어있다"고 코드에서 반드시 버그는 아닙니다. 문서화되지 않은 변경 일 수 있습니다. 언젠가 누군가가 정렬 순서를 변경하도록 요청했지만 사양, 요구 사항, 매뉴얼 (UI의 단추 및 레이블조차도)이 일치하도록 변경되지 않았으며 아무도 신경 쓰지 않았습니다. "날짜 별"로 표시하고 다시 변경하면 혼란이 발생할 수 있으며 UI, 사양, 설명서 등을 업데이트하려면 기본적으로 약간의 "깨진 창 이론"을 제외하고는 시간이 낭비됩니다. "

어떤 것은 분명히 버그입니다. 이 버튼을 클릭하면 폭파됩니다. 또는 월요일에이 버튼을 클릭하면 폭파됩니다. 다른 사람이 왜 그 이유를 이해하는 데 시간을 투자하지 않으면 조사에 많은 노력을 기울일 수 있습니다. 그리고 왜 그 이유를 알게되면, 사용자 나 경영진에게 더 중요한 것을 망칠 수 있기 때문에 그것을 바꿀 수 없을 수도 있습니다.

메모리 누수, 자신에게 맞지 않는 최적화, 들여 쓰기 및 명명 규칙이 분명히 필요한 코드 인 "느슨 함"이 표시되는 경우, 다른 일이 없거나 자신의 시간에 언젠가는 문제를 해결하는 것이 좋습니다. . 그러나 이러한 "수정 사항"은 소스 제어의 역사를 엉망으로 만들거나 이익을 거의 얻지 못합니다. "프로덕션에서 사용하는 이진 파일이 손실 된 코드로 작성 되었기 때문에 모듈을 컴파일하지 않습니다. ","고장 "한 사람들을 심각하게 화나게 할 수 있습니다.

상사와 일대일로하는 것이 좋습니다. 코딩 스타일, 사용자를 괴롭 히거나, 부정확 한 숫자, 불일치 또는 재난이 발생할 때까지 기다려야하는 것이 무엇인지 설명하십시오. 그런 다음 지시를 구하고 (이것이 핵심입니다) 가져 가십시오.

오래된 버그를 수정하려면 기존 기능을 손상시키지 않도록주의해야합니다. 단위 테스트가 있으면 더 쉽지만 회사와 소프트웨어의 나이를 암시하면 존재하지 않습니다. Martin Fowler의 Refactoring 책을 통해 부작용을 최소화하면서 버그를 올바르게 리팩토링하고 수정하는 방법을 살펴 보는 것이 좋습니다. 또한 정기적으로 오래된 버그를 겪고 회사에 문제가 없는지 확인하는 것이 좋습니다. 그들은 당신이 시간 외 근무를 할 경우에만 당신을 할 수 있습니다.

또한 버그가 기능이 된 경우 즉, 무언가를 제공하기 때문에 클라이언트가 실제로 사용하는 경우, 해당 동작을 원할 때 적절한 대체 방법을 제공해야합니다 (또는 버그 대신 기능으로 문서화).