사용자가 기능이라고 생각한 버그를 처리하는 방법은 무엇입니까?

질문 :

최종 사용자가 기능이라고 생각한 버그를 해결하는 올바른 방법은 무엇입니까?

정교함 :

많은 비율의 사용자가 기능으로 예상 한 경우 더 안정적으로 "고정되지 않은"또는 "고정 된"상태로 두어야한다고 생각합니다. 그러나 아주 적은 비율의 사용자가이 기능이 0.1 % 또는 1 %라고 생각하면이 버그를 수정해야합니다.

이론적으로 이것은 사소한 버그 수정이기 때문에 시맨틱 버전 관리에서 고려할 때 PATCH로 자격이 될 수 있습니다. 문서화되어있는 한 여전히 기능으로 의도되지 않았으므로 PATCH로 자격을 부여받을 수 있습니까?

편집 :이 특정 경우에는 다른 개발자가 사용하는 내부적으로 사용되는 라이브러리의 API에 버그가 있습니다.

많은 비율의 사용자가 기능으로 예상 한 경우 더 안정적으로 "고정되지 않은"또는 "고정 된"상태로 두어야한다고 생각합니다.

버그가 가치를 추가합니까? 그렇다면 더 많은 기능입니다. 때때로 "버그"는 부가 가치 "기능"으로 끝날 수 있습니다.

모든 상황이 다르기 때문에 결정적으로 대답하기가 어렵습니다.

이 특정 경우에는 다른 개발자가 사용하는 내부적으로 사용되는 라이브러리의 API 버그입니다.

이 경우, 이전 버전과의 호환성과 관련하여 다음 번 변경 사항의 일부로 수정 사항을 포함시킵니다. 당신은 할 수없는 정말 대부분의 환경에서 지속적으로이 작업을 수행하고 일정 / 기간이 대한 아마이있다.

개발자로서 마지막으로 다루고 싶은 것은 잘못되었거나 일관성이없는 API입니다. 버그는 이것으로 간주됩니다.

최소한 내부적으로 일종의 "현재 버전의 알려진 버그"문서 / 위키를 작성하면 모든 내부 사용자가 기능이 버그와 유사한 것임을 알 수 있습니다. 사람들이 기능별 버그를 사용하는 영역에 대해 충분한 테스트를 수행하여 버그를 고치면 언제 / 어떻게 부서 지는지 알 수 있기를 바랍니다.

더 안정적으로 만드는 것이 좋습니다. 사용자는 소프트웨어의 정식 소스입니다. 그들이 그것을 원하고 그것에 의존하게되면, 나는 그것을 두드리는 것에 대해 두 번 생각할 것입니다.

이에 대한 좋은 예는 비디오 게임 "Tribes"의 "Skiing"정비공입니다. 물리 엔진이 언덕에서 점프를 처리하는 방식의 원래 버그로 인해 핵심 게임 메커니즘 중 하나가되었습니다. 궁금한 점이 있으면 여기 에서 조금 더 읽을 수 있습니다 .

버그가 라이브러리에 있기 때문에 다음과 같은 다른 방법을 사용할 수 있습니다.

1. 잘못된 라이브러리 함수의 복제본을 만듭니다. 대부분의 경우 사람들 2은이 경우 함수 이름에 a 만 추가 하지만 해당 함수의 인터페이스에 적용하려는 다른 변경 사항이 있으면 완전히 다른 이름을 지정할 수도 있습니다.

2. 클론의 버그만 수정하십시오 (그리고있는 동안 원하는 다른 모든 인터페이스 변경 사항을 구현하십시오).

3. 더 이상 사용되지 않는 원래 기능을 선언하십시오.

4. 다음 주요 릴리스에서 원래 기능을 제거하십시오.

이 방법은 인터페이스가 근본적으로 손상된 기능에 특히 유용합니다. 사용자 코드를 즉시 중단하지는 않지만 깨진 코드에 의존하여 고정 코드 사용으로 전환하는 사람에게 경고를합니다. 그리고 사람들이 경고에주의를 기울이지 않더라도 실제로 고장난 기능을 제거하면 그들은 당신을 탓할 수 없습니다.

이 특정 경우에는 다른 개발자가 사용하는 내부적으로 사용되는 라이브러리의 API 버그입니다.

다른 개발자가 동작을 기능이라고 생각하면 해당 기능을 사용하고 작동하는 소프트웨어 를 구축했을 가능성이 높습니다 . 버그를 수정하면 기존 코드가 손상 될 수 있으며 이에 대한 책임은 사용자에게 있습니다. 이로 인해 버그 수정이 절충되므로 고려해야합니다.

• 버그를 수정하는 것이 중요합니까? 예를 들어 버그가 수정되지 않은 경우 API 사용자가 애플리케이션을 중단시킬 위험이 높기 때문입니까? 아니면 이것이 API의 일관성에 관한 것입니까?

• 또는 기존 소프트웨어를 안정적으로 유지하고 라이브러리를 이전 버전과 호환하는 것이 더 중요합니까?

질문에 대한 대답이 항상 간단하지는 않습니다. 가능한 API 사용자 수, 소프트웨어를 변경해야 할 잠재적 작업량, API를 변경하면 중단 될 소프트웨어의 양을 고려해야합니다. API를 수정 하지 않으면 발생할 수있는 위험도 있습니다 .

"다음 주요 릴리스의 주요 변경 사항 목록"에 버그 수정 변경 사항을 문서화한다고해서 고객이 만족 스럽지는 않습니다. 이렇게하면 API를 그대로 둘 수없는 이유에 대한 최소한의 증거가 있어야합니다. 전에 있었다. 버그를 수정하는 것보다 하위 호환성을 유지하는 것이 더 중요합니다. 따라서 사용자 기반과 해당 소프트웨어에 미치는 영향을 추정 할 수 있고 최신 라이브러리 릴리스로 업데이트하려고 할 때 무리한 노력을 기울이지 않을 경우에만 수정하십시오. 이에 대한 충분한 정보를 얻지 못하면 행동을 바꾸지 않는 것이 좋습니다.

(그렇습니다. 이전 버전과 호환되지 않는 API 변경을하려면 버전 번호를 명확하게 표현해야합니다. 이름을 "버그 픽스"로 지정했는지 여부는 중요하지 않습니다.

받아들이십시오. 전체 제품을 만들 수 있습니다.

GunZ : The Duel (온라인 게임)에는 전체 게임 플레이를 거의 변경하기 위해 악용하고 지속적으로 악용 할 수있는 버그가있었습니다 (K- 스타일, YouTube에서 찾아보기). 전체 게임 방식을 더욱 어렵게 만들었습니다. 그것은 기술을 가지고 그것을 놀랍고 재미있게 만들었습니다 .. 너무 재미있어서 중재자조차 공개적으로 그들의 주요 플레이 스타일로 사용했습니다.
그것이 게임을 만든 것입니다.
나는 수년간 플레이하지 않았지만 오늘날까지 게이머로서 그것은 기술 기반이고 너무 재미 있고 버그로 인해이 경이로움 때문에 항상 가장 좋아하는 게임 중 하나입니다.

그들은 결국 문제를 해결했지만 사람들은 너무 싫어하여 개발자가 심각하게 버그를 해결했습니다.

그래서 내 대답은 안정화하고 유지하십시오 (필요한 경우 리 팩터).

그 아름다운 이야기는, 같은 대답이 직접적인 이점이없는 것에 적용되지 않는다고 생각합니다. 버그로 인해 이벤트로 인해 이점이 발생하는 경우 일반적으로 버그를 수정하고 가능한 모든 것을 달성 할 수있는 다른 방법을 찾는 것이 더 현명합니다. 범위를 벗어난 경우 범위를 벗어나기 위해 그대로 두거나 다른 모듈 (작은 모듈)을 만들어 소개하십시오. 기본적으로 : 단일 책임 원칙을 위반하지 마십시오 .