예를 들어 Autodesk Maya의 규모와 복잡성에 따라 2 천만 ~ 3 천만 줄 이상의 코드, 소프트웨어에 대해 이야기하고 있습니다.

개발이 필요한만큼 개발을 중단한다면, 컴퓨터로 검증 할 수 있다면 버그가 하나도 없을 때까지 모든 버그를 실제로 고칠 수 있습니까? 버그없는 시스템의 존재와 반대에 대한 주장은 무엇입니까?

모든 수정 사항이 더 많은 버그를 생성한다는 개념이 있기는하지만 이것이 사실이라고 생각하지 않습니다.

버그로 나는 UI에서 가장 간단한 오타부터 해결 방법이없는 더 심각한 예방 버그까지 의미했습니다. 예를 들어 특정 스크립팅 함수는 법선을 잘못 계산합니다. 또한 해결 방법이 있어도 문제를 해결해야합니다. 따라서 제공된 기능을 사용하는 대신이 특정 작업을 수동으로 수행 할 수 있지만 해당 기능은 여전히 ​​수정해야한다고 말할 수 있습니다.

Mikey가 언급했듯이 버그없는 코드 작성은 목표가 아닙니다. 그것이 당신이 목표로하는 것이라면, 나는 당신에게 아주 나쁜 소식이 있습니다.

요점은 소프트웨어의 복잡성을 크게 과소 평가하고 있다는 것입니다.

가장 먼저해야 할 일-프로그램 운영 방식에 대한 더 큰 그림을 무시하고 있습니다. 완벽한 시스템에서는 단독으로 실행되지 않습니다. 가장 기본적인 "Hello World"프로그램도 운영 체제에서 실행되므로 가장 간단한 프로그램이라도 운영 체제에있을 수있는 버그에 취약합니다.

라이브러리의 존재는 이것을 더 복잡하게 만듭니다. 운영 체제는 상당히 안정적인 경향이 있지만 라이브러리는 안정성면에서 혼합 백입니다. 일부는 훌륭합니다. 기타 ...별로 ... ... 코드에 100 % 버그가 없도록하려면 실행중인 모든 라이브러리에 완전히 버그가 없어야하며 여러 번이 가능하지 않습니다. 소스 코드가 없을 수 있습니다.

그런 다음 고려해야 할 스레드가 있습니다. 대부분의 대규모 프로그램은 모든 곳에서 스레드를 사용합니다. 경쟁 조건과 교착 상태가 발생하지 않는 방식으로주의를 기울이고 스레드를 작성하려고하지만 가능한 모든 코드 조합을 테스트하는 것은 불가능합니다. 이를 효과적으로 테스트하려면 CPU를 통과하는 가능한 모든 명령 순서를 검사해야합니다. 나는 이것에 대한 수학을하지 않았지만 가능한 모든 체스 게임을 열거하는 것이 더 쉬울 것이라고 생각합니다.

우리가 기계 자체를 볼 때 일이 힘들어지고 불가능 해집니다. CPU가 완벽하지 않습니다. RAM이 완벽하지 않습니다. 하드 드라이브가 완벽하지 않습니다. 기계 내의 어떤 구성 요소도 완벽하게 설계되지 않았습니다. "충분히"적합하게 설계되었습니다. 완벽한 프로그램조차도 결국 기계의 딸꾹질로 인해 실패합니다. 그것을 막기 위해 할 수있는 일은 없습니다.

결론 : "버그 프리 소프트웨어"를 작성할 수 있습니까?

아니

달리 말한 사람은 실마리가 없습니다.

이해하고 유지하기 쉬운 소프트웨어를 작성하십시오. 그렇게하면 하루에 전화 할 수 있습니다.

편집 : 일부 사람들은 내가 완전히 간과 한 훌륭한 점에 대해 언급했습니다 : 컴파일러.

어셈블리로 작성하지 않는 한 컴파일러가 코드를 엉망으로 만들 수 있습니다 (코드가 "완벽"하다는 것을 증명하더라도).

가장 일반적으로 사용되는 컴파일러 중 하나 인 GCC의 버그 목록 : http://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=c%2B%2B&resolution=---

수학적으로는 모르지 는 '버그'를 정의하는 방법에 따라, 이러한 복잡성의 'bugless'소프트웨어를 작성하는 것이 가능합니다. 그것을 증명하는 것은 모르지 가능한 모든 사용 사례 - 또한 가능한 모든 방법으로 코드의 모든 라인을 행사할 것이다 테스트 시스템을 설계함으로써, 수학적으로 가능하다. 그러나 확실하지 않습니다-복잡한 계산을 수행하는 시스템을 다루는 경우 '무한대 문제'가 발생할 수 있습니다 ...

실제로 말하면, 당신이 말하는 크기와 범위의 시스템에서 이것은 불가능 합니다. 그러한 '버그 프리'시스템을 작성하고 기하 급수적으로 더 많은 시간이 걸린다는 것을 입증하기 위해 시스템을 작성하는 데 1000 년이 걸릴 수 있습니다. 가능한 모든 사용 사례를 생각해 내고 각각을 테스트 할 시스템을 작성해야합니다. 하나-나는 당신이 합리적인 시간과 비슷한 어떤 것에 대해 이야기하고있는 크기와 범위의 시스템에서 모든 사용 사례를 실제로 다루었다고 결정하는 방법이 없다고 생각합니다.

IMO 귀하의 질문은 약간 잘못 지시되었습니다. 개발자로서 우리의 목표는 '버그없는'소프트웨어를 작성하지 않는 것입니다. 우리의 목표는 사용 가능하고 유연하며 쉽게 관리 할 수있는 소프트웨어를 작성하는 것입니다.

사용 가능 : 시스템은 설계된 필수 요구 사항을 충족합니다. 버그가있을 수 있지만 시스템의 기본을 손상시키는 버그가 아닌 이상치 또는 성가신 '가장 큰 사례'에있을 것입니다.

유지 관리 가능 : 버그를 쉽게 격리하고 수정할 수 있으며 새로운 버그를 만들지 않습니다.

융통성 : 시스템은 재 설계 및 중단 시간없이 변경 및 확장이 용이합니다. 대부분의 변경은 이미 잘 설계된 패턴 및 프레임 워크에 맞는 새로운 클래스 또는 모듈을 추가하면됩니다.

좋은 설계 관행, 좋은 통제 관행, 좋은 팀워크, 양심적 인 개발자-이것이 GOOD SOFTWARE 의 공식입니다 . ( 완벽 하지는 않지만 GOOD )

이 기사 에 따르면 우주 왕복선 용 온보드 소프트웨어는 매우 가까워졌다. 420,000 라인 프로그램의 마지막 3 가지 버전에는 각각 하나의 오류 만 있었다. 이 소프트웨어는 260 명의 남녀 그룹이 관리했습니다. 이 사람들 중 다수는 검증 자였으며 그 목적은 오류를 찾는 것이 었습니다.

셔틀이 글로벌 포지셔닝 위성 (Global Positioning Satellites)으로 이동할 수 있도록하는 소프트웨어 업그레이드는 프로그램의 1.5 % 또는 6,366 줄의 코드에 영향을 미쳤습니다. 한 번의 변경 사항에 대한 사양은 2,500 페이지를 실행했습니다. 전체 프로그램의 스펙은 30 개의 볼륨을 채우고 스펙의 페이지 당 40,000 페이지 또는 평균 10 줄의 코드를 실행했습니다.

예산은 문제가되지 않았다-연간 $ 35 백만, 그들은 일을 제대로 감당할 수 있었다.

본질적으로, 그러나 당신은 어쨌든 최선을 다해야합니다. 이유를 설명하겠습니다 (또는 인내심이 충분하지 않으면 결론으로 ​​건너 뜁니다)

이진 검색의 구현만큼 사소한 문제를 고려하십시오. 매우 인기있는 구현 중 하나 는 약 20 년 동안 발견되지 않은 버그 가 있었습니다 . 버그가없고 널리 사용되는 것으로 20 개 라인이 20 년이 걸린다면, 실제로 큰 프로그램에 버그가 없을 것으로 예상 할 수 있습니까?

어쨌든 거대한 프로그램이 얼마나 많은 버그를 예상 할 수 있습니까? 내가 찾은 숫자 중 하나는 "1000 줄당 10 개의 결함"(517 페이지의 코드 완성 2 판-데이터를 인용하지 않고 예제를 사용한 것임)입니다. 다행히도 프로그램의 품질을 향상시킬 수있는 방법이 있습니다. 단위 테스트, 코드 검토 및 일반 수동 테스트는 버그 수를 줄이는 것으로 알려져 있습니다. 여전히 숫자는 여전히 높습니다.

우리가 믿을 수 없을 정도로 모든 버그의 95 %를 해결할 수 있다면. 그러나 우리는 여전히 소프트웨어에 10 만에서 15 만개의 버그가 있습니다.

다행히도 소프트웨어가 널리 사용되므로 널리 테스트되므로 버그가 발견 될 것입니다. 따라서 버그가 점차 줄어 듭니다. 그러나 버그가 적다는 것은 나머지 버그를 찾기가 어렵다는 것을 의미하므로 버그 수정에 선형 곡선을 기대하지 마십시오. 마지막으로 몇 가지 버그 찾기가 정말 힘들 것입니다 (그들은 가정하에 몇 년 동안 탐지를 피할 수있는 지금까지 발견).

또한 소프트웨어가 변경되지 않으면 새로운 버그가 나타나지 않는다고 가정하는 실수가있는 것 같습니다. 소프트웨어가 타사 라이브러리에 의존하는 경우 새 버전은 일부 기능을 손상시킬 수 있습니다. 응용 프로그램 코드가 여전히 동일하더라도 새로운 버그가 발생할 수 있습니다. 새로운 운영 체제는 이전에 완벽하게 작동했던 응용 프로그램을 손상시킬 수도 있습니다 (일반적인 예는 Windows Vista 참조). 컴파일러 버그 등도 고려하십시오.

코드 교정 도구가 버그가있는 소프트웨어의 문제를 진정으로 해결할 수 있는지 여부는 확실하지 않습니다. 어떤 프로그램에서든 정지 문제 를 해결할 수는 없지만 프로그램이 지정된대로 작동 함을 증명할 수 있습니다. 어쩌면 증명 프로그램에 버그가있을 수 있습니다. 사양 자체에 버그가있을 수 있습니다.

따라서 버그 수를 크게 줄일 수는 있지만 실제로 제로가 될 가능성은 거의 없습니다.

모든 수정 사항이 더 많은 버그를 생성 한다는 개념이 있기는 하지만 이것이 사실이라고 생각하지 않습니다.

(강조 추가)

당신이 올바른지. 이 진술은 잘못되었습니다. 예를 들면 다음과 같습니다.

int main() {
    int x[10];
    x[10] = 8; //Buffer overflow here
    return 0;
}

이제이 버그를 수정 해 봅시다 :

int main() {
    int x[11];
    x[10] = 8; //No buffer overflow here
    return 0;
}

보다? 우리는 버그를 수정하고 새로운 버그를 도입하지 않았습니다.

그러나 버그를 수정할 때마다 새로운 버그를 생성 할 위험이 있지만,이 위험을 완화 할 수 있습니다 (예 : 단위 테스트 등).

내가 고치는 100 개의 버그마다 우연히 새로운 버그를 소개한다고 가정 해 봅시다. 10 만개의 버그를 고치면 100 개의 새로운 버그가 생깁니다. 새로운 버그를 수정하면 하나의 버그를 소개합니다. 그러나 무엇? 이 프로그램은 버그가 9,999 개 적으므로 이전보다 버그가 10000 배나 높다고 가정했을 때보 다 더 나을 것입니다.

또한 버그를 수정 하면 새로운 버그가 노출 될 수 있습니다. 그러나 이러한 버그도 수정 될 수 있습니다. 올바르게 작업하면 결국 소프트웨어가 시작된 것보다 나은 상태가됩니다.

나는 OP에서 언급 한 개념으로 인해 많은 버그를 수정하지 않는 것이 더 좋은 몇 명의 최고 프로그래머에 의해 늙었습니다.

이 동작은 무시됩니다. 버그가 있으면 고칠 수 있습니다. 해. 물론 새로운 버그를 추가하지 않도록 최선을 다해야하지만 내가 고쳐야 할 10 개의 심각한 버그마다 작은 버그 하나를 도입하면 버그 수정을 중단 할 수있는 정당한 이유가 아닙니다. 실제로 버그를 수정 하는 것이 좋습니다 .

더 적은 버그를 수정하면 앞으로 더 적은 버그가 다시 나타납니다.

수정하는 버그가 적을수록 소프트웨어에 더 많은 버그가 남아 사용자를 성가 시게합니다. 실제로, 그들은 "미래에 당신에게 돌아 오지 않을 것"입니다. 그들은 처음부터 떠나지 않았기 때문에 돌아 오지 않을 것입니다. "복귀"라는 개념은 회귀와 관련이 있습니다. 다시, 회귀의 위험을 줄일 수 있습니다.

사람들이 버그에 의존하기 시작하여 버그를 수정하면 해당 사용자의 프로그램이 중단 될 수 있기 때문에 일부 버그는 널리 사용되기 때문에 수정할 수 없습니다. 일어난다. 그러나이 경우 실제로 버그로 간주 될 수 있습니까?

"버그 수정, 버그 만들기"사고 방식은 그 끔찍한 괴물 과 관련이있을 수 있습니다. 그 코드는 읽을 수없고 관리 할 수없는 코드만으로 버그를 만듭니다. 코드베이스에 몬스터가있는 경우, 어떤 작업을 수행하기 전에 먼저 몬스터를 해제해야합니다.

마지막으로, 당신이 끔찍한 프로그래머라면, 만지는 것이 새로운 버그 를 일으킬 위험이 있습니다 . 이것은 분명히 상급 프로그래머를 긴장하게 만들 것입니다. 그러나 "아무것도하지 마십시오. 아무것도 만지지 마십시오. 숨을 쉬지 마십시오"라고 말합니다. 건강한 작업 환경을 조성하는 올바른 방법이 아닐 수도 있습니다. 교육이 더 좋습니다.

결론:

• 수많은 새로운 기능을 계속 제공하지만 버그 수정이없는 소프트웨어는 필연적으로 빨라질 것입니다.
• 적당한 수의 새로운 기능을 갖지만 버그가 수정 된 소프트웨어는 사용 가능성이 더 높습니다.
• 버그가 거의없는 사람들은 관심이없는 사람들보다 평균적으로 버그가 적습니다.
• 프로그램이 결국 버그가없는 것으로 기대하는 것은 합리적이지 않습니다.
• 선임 프로그래머가 반드시 유능한 것은 아닙니다.
• 버그를 수정하십시오.
• 소프트웨어의 품질을 향상시키는 방법론을 채택하십시오.

버그가없는 프로그램을 작성 하지 않는 이유 는 대부분 경제적입니다.

프로그램의 정확성을 입증하는 수학적 방법 이 있습니다 . 고품질의 컴퓨터 과학 과정에서 학생들이 언급 될 것입니다. 이 목적을 위해 특별히 고안된 프로그래밍 언어가 있습니다. 이론적으로 버그없는 프로그래밍 이 가능합니다.

그렇습니다. 수백만 년 전에 먼 초신성에서 발사 된 중성미자가 바로 그 자리에서 프로세서를 때리기 때문에 비트 값이 변경 될 수있는 불완전한 하드웨어가 있습니다. 모든 이론에는 가정과 추상화가 있습니다. 그러나 프로세서가 광고 된대로 작동한다고 가정하면 프로그램이 올바르게 작동하는지 확인하는 matmematical 도구가 있습니다.

이 주제에 대한 투표가 많은 답변은 오해의 소지가 있습니다. 예를 들어, 괴델의 불완전 성 정리 및 정지 문제는 당신이 예를 들면의 정확성 또는 부정확 결정할 것 자동화 된 도구를 가질 수 있음을 의미 있는 프로그램. 그러나 우리는 어떤 프로그램 의 정확성을 결정하고 싶지 않고 특정 프로그램 의 정확성에 대한 증거 만 원합니다 .

(유비, 자동의 진리를 결정하는 프로그램을 쓸 수 없습니다해서 어떤 수학적 정리를, 그건 당신이 증명할 수없는 것을 의미하지 않는다 하나 개의 특정 수학적 정리를.)

대신 문제는 다음과 같습니다.

이론적으로 버그가없는 프로그램을 작성하는 것이 가능하지만 그렇게하는 것은 비용이 많이 듭니다 . 정확성 이 입증 된 코드 를 작성하는 것은 벽에 무언가가 붙어 있는지 보는 것보다 복잡합니다. "고착 여부 확인"이 단위 테스트로 수행 되더라도; 많은 프로그래머들이 그렇게하지 않아도됩니다. 대부분의 프로그래머는 그렇게하는 방법조차 몰랐기 때문에 회사로서 더 비싼 것을 고용해야합니다.

모든 비용을 고려할 때, 일반적인 고객은 100 % 더 잘 작동하는 1000 배 더 비싼 소프트웨어를 사용하는 것보다 99 % (그리고 추가 업데이트를 설치 한 후 99.9 %) 잘 작동하는 저렴한 소프트웨어에 더 만족합니다. 시간. 또한 고객은 10 년에서 20 년이 아니라 지금 이 소프트웨어를 갖고 싶어합니다 .

따라서 사람들은 의도적으로 버그가 발생할 가능성이 높은 소프트웨어를 제작하여 버그가 너무 자주 발생하지 않고 심각하지 않은 최적의 조합을 만들려고 노력하며 생산 속도가 빠르고 저렴합니다. 실생활에서 가장 많은 이익을 제공하는 조합. (때로는 경쟁 업체가 무언가를 출시하기 전에 버그로 가득 찬 소프트웨어를 출시하고 경쟁사가 첫 번째 괜찮은 버전을 출시 할 준비가되었을 때 더 적절한 버전 2.0 만 공개하는 것을 의미하기도합니다.)

개발이 필요한만큼 개발을 중단한다면, 컴퓨터로 검증 할 수 있다면 버그가 하나도 없을 때까지 모든 버그를 실제로 고칠 수 있습니까?

수학적으로 말하면 가능합니다. 경제적으로 말하자면 왜 그렇게할까요? 아마도 20 년과 수백만 달러를 소비한다는 의미 일 것입니다. 한편, 고객은 새로운 기능을 원할 것이며 냉동 된 응용 프로그램에서는이를 제공 할 수 없습니다. 따라서 완벽한 버전이 준비되면 시장은 이미 경쟁 업체가 차지합니다.

경제적 추론은 괜찮습니다. 우리는 돈과 시간이 중요한 세상에 살고 있습니다. 그러나 우리는 경제적 인 이유로 무언가를하지 않기 때문에 이론적으로도 어떻게 할 수 없는지 말도 안됩니다. 누가 알겠는가? 아마도 몇 년 안에 정확성을 쉽게 증명할 수있는 새로운 프로그래밍 언어와 도구가있을 것이다.

아니.

데이비드 힐버트 (David Hilbert) 는 1900 년에 수학의 두 번째 문제 를 제안하여 본질적으로 산술이 의도 한대로 작동했음을 증명하도록 요구했습니다. 그는 나중에 " 엔트 샤이 둔스 문제 (Entscheidungsproblem) "를 제안 했는데, 논리적으로 비슷한 용어를 요구했다. Kurt_Gödel의 " 첫 번째 불완전 성 정리 "는 1931 년에 기초 산술 이론이 일관되고 완전 할 수 없음을 증명했습니다. Alan Turing 이 Entscheidungs 문제를 " 멈춤 문제 "로 표현한 것은이 문제 의 핵심으로이 문제를 옮겼으며, 프로그램이 완료 될지 여부를 증명할 수 없다는 것을 증명했습니다. 그 결정 불가능 성을 감안할 때프로그램에 버그가 있는지 여부를 증명하는 것도 불가능합니다.

그 중 어느 것도 우리 중 연습 프로그래머가 버그를 만들려고 애 쓰지 않습니다. 그것은 단지 우리가 일반적으로 성공할 수 없다는 것을 의미합니다.

오류가있는 Humanum est

B-method 와 같은 공식 언어로 코드를 작성하더라도 요구 사항이 충족되었음을 수학적으로 증명하는 데 사용할 수 있습니다.

공식 사양 언어를 사용하더라도

하나 이상의 두뇌에서 컴퓨터로 사용자의 요구를 추출하는 것으로 구성된 인간 단계가 항상 있습니다.

이 인간 단계는 오류가 발생하기 쉽고 웜은 사과에 있습니다.

내가 경험 한 "버그"의 상당 부분은 시스템 설계와 고객의 기대치가 일치하지 않는 것으로 더 잘 설명 될 수 있습니다.

우리가 이러한 버그를 부를 것인지의 여부는 학문적이지만, 의사 소통이 불완전하고 고객의 기대가 바뀌는 결과로 많은 유지 보수 작업이 발생한다는 사실이 남아 있습니다.

시스템이 사양을 충족한다는 의미에서 기술적으로, 아마도 "정확한"(그러나 실제 상용 소프트웨어에서는 불가능할 수 있음), 소프트웨어 기능을 고객의 항상 일치시키는 문제가 여전히 있습니다. 변화하고 잘못 정의 된 기대.

한마디로 :

아니.

사양이 충분히 엄격하고 제한적인 경우 버그가없는 프로그램을 증명할 수 있지만 시스템의 다른 모든 기능이 올바르게 작동하는지에 대한 예측할 수없는 가정만을 기반으로합니다. 이는 원래 문제를 제기 한 사람 또는 서비스를 사용하는 사람이 사양을 올바르게 간주한다는 것을 증명할 수있는 방법이 없다는 점을 감안한 것입니다.

Jim Shore의 No Bugs 섹션 에서이 주제에 대한 유용한 정보를 찾았습니다 . 짧은 형식 : 버그를 만들지 않고 개발할 수는 없지만 가능한 빨리 버그를 감지하는 방식으로 작업 할 수 있습니다.

코드 자체를 제작하는 동안 예를 들어 개발 중에 단위 테스트를 자주 작성하고 실행함으로써 코드가 수행해야 할 작업을 지속적으로 보장합니다. 또한 의도 한 시스템 동작을 가장 명확하게 표현하는 방식으로 기존 코드를 영구적으로 다시 작성하는 것이 유용합니다.

그러나 귀하의 경우, 수백만 줄의 코드가있는 기존 코드베이스에 대해 이야기하고 있습니다. 이러한 시스템 버그를 없애려면 우선이 시스템의 "버그"가 무엇인지 알아야합니다. 시스템 기능을 확인하는 사후 테스트 모음을 작성할 수 있습니다 (아직없는 경우). 이러한 테스트 웹은 올바른 시스템 동작에 대한 대략적인 정의 로 제공 될 수 있습니다. 그러나 코드가 많을수록 그러한 연습에 더 많은 노력이 필요합니다. 따라서 대부분의 회사는 타협을합니다. 시스템에서 가장 성가신 버그를 얻기 위해 불완전한 버그 목록 및 유지 관리 작업을합니다.

컴퓨터 별 검증 정보

컴퓨터를 사용하여 프로그램을 확인하는 방법에는 두 가지가 있습니다. 하나는 테스트 중이고 다른 하나는 증명 시스템을 사용 중입니다.

철저한 테스트가 불가능 해지 자마자 테스트는 프로그램에 버그가 없음을 보여주지 못합니다. (그리고 테스트 자체가 버그가 있는지 테스트하지 않는다는 것을 보여주는 문제가 있습니다).

증명 시스템을 사용하려면 공식적인 요구 사항부터 시작해야합니다 (그리고 버그가있을 수 있습니다. 요구 사항에 사용 된 언어가 프로그래밍 언어보다 버그가 없다는 것을 확신하기에 더 적합 할 것입니다). 프로그램이 버그가 없다는 증거 시스템의 도움 (그리고 증거 시스템에는 버그가 있지만 그 자체가 올바른 것으로 판명되었습니다). 현재의 최신 기술은 C 부분 집합을위한 컴파일러입니다 (그리고 부분 집합은 "CompCert는 C의 모든 MISRA-C 2004 부분 집합과 MISRA에서 제외 된 많은 기능을 지원합니다").

아니요, 응용 프로그램이 실행되는 컴퓨터 및 소프트웨어 환경은 코드가 고정 된 상태에서도 계속 변경되기 때문입니다. 운영 체제는 장치 및 드라이버뿐만 아니라 패치 및 수정으로 계속 진화합니다. 알려진 버그가없는 것으로 판단되면 AMD 또는 nVidia는 비디오 하위 시스템과의 상호 작용 방식에 영향을주는 비디오 드라이버 업데이트를 릴리스합니다. 이제 특정 비디오 카드 또는 구성 (SLI? LOL)이있는 고객에게는 응용 프로그램에 시각적 결함 (깜박임, 깜박임 또는 프레임 속도 감소 등)이 있습니다.

하드웨어 및 OS 이외에도 제어 범위를 넘어 진화 할 수있는 가장 중요한 앱 아래에는 여러 가지 미들웨어 제품이 있으며, 코드를 무결점 상태로 만들면 바로 아래에있는 레이어가 EOL을 받게됩니다.

기술은 물론 기술을 활용하는 비즈니스도 발전하고 있으며 "자유로운"코드라는 아이디어는 불가능하거나 실현 가능하지 않습니다. 새로운 기능 세트를 요구하는 비즈니스는 "알려진 모든 버그를 추적하는 동안 코드를 잠 갔으며 X 개월 내에 유효한 소프트웨어 결함을보고 한 사람은 아무도 없습니다"라고 응답하지 않습니다. 기업이 해당 라인을 구매하더라도 X 개월 후에는 새로운 기능이 어떻게 나오는지 묻게 될 것입니다. "Oracle은 패치를 릴리스하기 때문에 동결을 연장하기로 결정했으며 X 개월 더 걸릴 필요가 있습니다. 인증하기 위해 "

아니요. 어떤 시점에서 비즈니스는 기술 속도로 발전 할 필요성을 지원하는보다 유연한 개발 팀을 찾고있을 것입니다. 이것이 현대 개발 팀이 직면 한 근본적인 문제입니다.

예, 그러나 당신은 확실히 알 수 없습니다. 더 힘들어 보일수록 더 많이 찾을 수 있습니다. 시스템이 많이 사용 될수록 더 많은 경우가 사용 될수록 원래 의도 또는 사양과 다른 불일치가 발견 될 수 있습니다. 이는 버그 자체가 정확한 것은 아니며 일부 개인이인지 된 이상을 평가하는 정도에 따라 종종 해석에 의존한다는 것을 의미합니다.

퍼지입니다. 마지막 비트로 지정된 시스템은 거의 없습니다. 시스템이 잘 작동하고 사용자에게 불만 사항이없고 (아무것도 버그가없는 경우) 시스템에 완전히 적응 한 경우 버그가 없다고 부르기도합니다.

충분한 훈련과 공유 팀 문화가 주어지면 버그가없는 소프트웨어 를 지속적으로 제공 할 수 있습니다. (그리고 잘 짜여진 모듈 식 코드, 포괄적 인 자동 테스트 스위트, 결함 검사 및 프로세스 적응, 노력과 겸손이 필요하지만 수천 배를 상환하는 많은 다른 것들)

그러나 이렇게하면 일반적으로 20 MLOC 시스템을 구축하지 않습니다. 버그가없는 코드를 작성하는 것이 목표가 아닌 경우 많은 MLOC 시스템을 구축하지 않아야합니다.

내 자신의 추론은 다음과 같습니다.

어떤 사람은 성취해야 할 필요가 있습니다. 어떤 사람 (아마도 같은 사람 일 수도 있고 다른 사람 일 수도 있음)은 소프트웨어 작성을 통해 필요를 충족시키기위한 예산을 가지고 있습니다. 이 사람들은 모두 돈을 위해 이익을 기대합니다.

예산을 가진 사람은 어떤 사람들 (아마도 같은, 아마도 다른)라는 지불 프로그래머가 이러한 있도록 프로그래머가 일부 필요를 충족 소프트웨어에 자신의 시간의 양에 동의집니다.

따라서이 프로그래머들은 다른 사람의 돈을 필요를 충족시키는 소프트웨어로 변환하는 작업을합니다. 이 돈을 잘 사용하는 것은 그들의 책임입니다.

이것은 귀하의 질문과 관련하여 다음과 같은 의미를 갖습니다.

• 소프트웨어에 버그가 있다고해서 전혀 고치겠습니까? 버그를 수정하려면 프로그래머가 필요하며 프로그래머는 비용이 듭니다. 프로그래머는 돈을 쓸 것인지 결정할 수 없습니다. 예산을 보유한 사람의 역할입니다.
• 결국 수정되지 않은 버그를 남기지 않고 처음부터 20MLOC 소프트웨어를 구축 할 수 있습니까? 글쎄, 20MLOC를 건설하기 위해서는 엄청난 돈을 쓰려고했다. 이것은 재정적으로 어리석은 일입니다. 그리고 그것은 하루에 지어지지 않았습니다. 그러나 소프트웨어는 내일이 아니라 오늘날의 요구를위한 것입니다. 많은 프로그래머를 고용 하여 개발 을 병렬화 하려는 잘못된 시도가있을 것 입니다. 그러나 공유 문화를 얻지 못하고 버그가 발생하고 낭비와 지연이 발생하며 문제를 해결하기 위해 돈이 부족할 가능성이 있습니다. 이 크기의 버그가없는 시스템은 아직 보지 못했습니다. (버그없는 시스템과 20MLOC 시스템을 보았지만 같지 않았습니다)
• 내가 작성하지 않은 20MLOC 시스템을 유지 관리해야합니다. 알려진 버그가 0에 도달 할 수 있습니까? 이것은 프로그래머에게 의존하지 않습니다. 그들은 돈이 아니기 때문에 버그를 고치기로 결정할 수 없습니다. 나머지 버그를 수정하기에 충분한 ROI가 있습니까? 글쎄, 시스템은 한동안 사용되어 왔으며, 사용자는 그 시스템에 익숙해졌으며 일상적인 작업에서 시스템의 단점을 이용합니다. 원칙적으로 버그를 수정하면 돈을 가진 사람 이 시스템에서 사라진 지정되지 않은 일부 기능 을 다시 개발하기 위해 비용을 지불해야 할 수도 있습니다 .

그것은 돈에 관한 것입니다.

예.

그러나 아시다시피, 가치가 있으려면 너무 많은 노력이 필요합니다.

답변을 방어하려면 먼저 버그가 무엇인지 정의해야합니다.

• 버그는 사양과 반대되는 동작입니다.
• 그러나 사양의 결함 (예 : 0 번째 로봇 법칙)은 소프트웨어 버그로 간주되지 않습니다.
• 사양에 의해 금지되지 않는 한 추가 기능은 버그로 간주되지 않습니다.
• 논쟁의 여지가 있지만, 사양 내 모순은 소프트웨어 버그로 간주되지 않습니다.

이제 잘 알고 있듯이 좋은 소프트웨어 아키텍처는 모듈 식이므로 각 모듈을 개별적으로 단위 테스트 (또는 수동 테스트 등) 할 수 있습니다. 훈련과 신중한 테스트를 통해 버그가없는 개별 모듈을 작성할 수 있습니다.

"하지만 기다려!" "한 모듈의 예기치 않은 (그러나 그럼에도 불구하고 올바른) 동작으로 다른 모듈에 버그가 발생하면 어떻게됩니까?" 그런 다음 버그는 두 번째 모듈에 있습니다. 버그가없는 모듈은 API로 취급 될 수 있으며 API는 알고 있듯이 올바르게 사용하기 위해주의를 기울여야합니다.

방탄 코드를 작성하려면 개발자 측의 최첨단 사례 및 흐름 논리에 대한 광범위한 지식이 필요하며 대부분의 소프트웨어 개발자는 배우기가 쉽지 않거나 단순히 신경 쓰지 않아도됩니다. 또는 더 자주 마감일에 있습니다.

"하지만 저에게 설 자리를 주면 세상을 움직일 것입니다." -아르키메데스