알려진 버그로 소프트웨어가 계속 릴리스되는 이유는 무엇입니까? [닫은]

대규모 프로젝트에서 자주 버그 추적기가 버그로 가득 찬 상태로 소프트웨어가 출시되는 것 같습니다. 이제 기능 요청을 이해할 수 있지만 여러 번 버그가 여전히 해결되지 않았거나 검토되지 않았거나 완료되지 않았지만 릴리스가 계속 진행되는 것을 보았습니다.

왜? 오픈 소스 프로젝트 또는 일반적인 프로젝트가 알려진 버그 로 릴리스되는 이유는 무엇 입니까? 버그 추적기가 0 개의 열린 버그를 가질 때까지 왜 기다리지 않습니까?

다음을 포함한 여러 가지 이유 :

1. 회사는 특정 시간에 릴리스하기 위해 사용자 기반을 약속했습니다
2. 버그는 미션 크리티컬하지도 않았고, 심지어 큰 것도 아니었다
3. 새로운 기능 개발이보다 중요하게 여겨졌습니다 (올바르 든 아니든)

프로그래밍 지식이 "완전하지 않은"경우에도 프로그래머로서 왜 일하는지 묻는 것과 같습니다. 대부분의 복잡한 프로젝트에는 많은 버그가 있습니다. 새로운 기능을 추가하면서 이들을 다루는 것은 어렵고 복잡한 작업입니다.

버그가있는 소프트웨어는 소프트웨어가없는 것보다 낫기 때문입니다.
같은 이유로:

• 운송 회사는 항상 지연이 있더라도 일정 수립을 방해합니다.
• 제약 회사는 알려진 (그리고 대부분 문서화 된) 부작용이있는 약물을 판매합니다.
• 세계 각국의 학교는 뉴턴 물리학을 가르치지 만, 알려진 한계가 있습니다.

알려진 결함이있는 솔루션을 갖는 것이 솔루션이 없거나 결함이 알려지지 않은 솔루션을 갖는 것보다 훨씬 낫습니다.
내가 가장 좋아하는 IDE에는 많은 새로운 기능이 있으며 안정적이지 않습니다. 그냥 말하자 : 나는 20 년마다 손으로 무언가를해야하는 것이 좋다. 왜냐하면 모든 것이 손으로하는 것이 아니라 기능이 실패하기 때문이다.

또는 Voltaire의 말로 "Le mieux est l' ennemi du bien"이라고 말하면됩니다.

궁극적으로 무료 및 오픈 소스 소프트웨어의 경우에도 비즈니스 결정입니다. 존재하는 결함이 릴리스, 소프트웨어를 사용자에게 제공하고 피드백 (기능 요청 및 발견되지 않은 결함에 대한 새로운 버그 보고서를 포함하지만 이에 국한되지 않음)이 더 낫다는 영향이 적은 지점이 있습니다. 테스트에서). 이 결정은 경쟁사들 사이에서 소프트웨어 시장에 대한 관심을 끌기 위해 필요합니다. 소프트웨어가 영향을 미치려면 새로운 기능이나 개념으로 경쟁 업체를 이겨야합니다.

모든 것이 비용 대비 이익 분석으로 귀결됩니다. 각 버그 수정에는 관련 비용이 있습니다 (수리하는 데 몇 시간, 릴리스 X 일 전 더 많은 코드 변경 위험이 있습니다 ...). 동시에, 각 버그 수정은 더 많은 기능, 유용성 등의 측면에서 부가 가치를 분명히 제공합니다.

따라서 이것은 모든 개발 팀이 릴리스 할 때 직면하는 질문입니다 .1) 버그 #i는 비용과 추가 가치를 감안할 때 수정 가치가 있으며 2) i = 0에서 N까지의 모든 열린 버그에 대해 반복합니다.

출시되지 않은 소프트웨어 제품은 누구에게도 가치가 없다는 것을 명심하십시오. 200 개의 뛰어난 버그가 있지만 기능의 90 %가 작동하는 소프트웨어 제품은 릴리스 당시의 기능에 만족하는 모든 사람들에게 가치가 있습니다.

나는 0 버그로 출시 된 제품에 대해 어떤 회사에서도 본 적이 없으며 그것이 완전히 정상적이라고 생각합니다. 어느 시점에서, 당신은 당신의 손실을 줄이고 작동하는 것을 활용하십시오. 그렇지 않으면 아무 것도 해제하지 않습니다.

큰 프로젝트에서는 버그 찾기를 멈추지 않습니다. 모든 버그가 수정되고 수정 회귀 테스트가 완료 될 때까지 기다려야한다면 절대 릴리스되지 않습니다.

또한 모든 버그가 내부에있는 것은 아닙니다. 모든 프로그램은 다른 소프트웨어의 복잡한 웹의 일부이며 다른 곳에서 변경하면 소프트웨어에서 "버그"로 나타날 수 있습니다. 당신은 세상을 멈출 수 없습니다.

많은 좋은 답변 외에도 때때로 새로운 제품과의 시장 경쟁이 있습니다. 중요하지 않은 결함이 15 % (또는 다른 수) 인 경우에도 시장 점유율의 대부분을 확보 할 수 있다고 생각하면 경쟁 업체에 우위를 점하기 위해 제품을 출시하는 것이 좋습니다.

이 버그는 아주 작을 수 있습니다. 상용 소프트웨어를 배송하고 디스크 등을 눌러야합니다. 이 릴리스 날짜를 충족시키는 것은 심각한 재정적 영향을 미치며 일부 사소한 문제에 대한 지연은 다른 이유로 시장에 출시해야 할 필요성을 언급하는 것이 아닙니다.

잠재적 답변 :

• 누구나 버그를 만날 가능성은 거의 없습니다.
• 버그에 대한 해결 방법이 있습니다.
• 소프트웨어는 언젠가 릴리스되어야하며 완벽을 달성 할 수는 없습니다.

이상적으로는 대부분의 개발자가 자신의 응용 프로그램에서 버그가없는 것을보고 싶을 것입니다. 슬프게도 조건이 그러한 유토피아 상태를 허용하지 않을 수 있습니다.

사용자 기반에 새로운 기능이 필요하고 추가 기능에 대해 동일하거나 더 많은 버그를 기꺼이 기꺼이 받아들이 기 때문이라고 생각합니다.

경영진이 참여하는 경우 광고 일정, 추가 직원 가용성 문제, "우리는이 기능을 가장 먼저 사용해야합니다"라는 사고 방식과 같은 다양한 이유로 마감일을 준수해야합니다.

내 생각에는 낙관적이지 않다. 아마도 개발자가 게으 르기 때문 일까?

또한 오픈 소스 커뮤니티에서는 일반적으로 "누가"버그 / 기능 / 문제 요청을 처리하기를 원한다는 사실을 기억하십시오. 아마도 더 큰 문제로 인해 발생하는 문제를 아무도 처리하려고하지 않을 것입니다.

가장 간단한 프로그래밍 방식 테스트에서 :

if (management->perceived_cost_to_fix > management->perceived_benefit_release_now) {
    release;
}

버그 수정, 시간 / 공간 / 메모리 또는 보안 / 사용성 등 모든 것이 항상 상충 관계입니다. 수행 된 트레이드 오프 계산에 대해 생각해보십시오. 동의하지 않을 수 있지만 이해하지 못하면 문제가 있습니다.

또한 종 곡선에서 이러한 계산을 생각해보십시오. 어떤 사람들은 양쪽에 정말 나쁜 계산을 할 것입니다. 커브의 한쪽 끝은 Duke Nukem Forever를 참조하십시오.