답변:
소프트웨어 결함의 주요 원인은 해석입니다.
기능에 대한 고객 해석은 설계자 해석과 다릅니다.
디자이너 해석은 프로그래머 해석과 다릅니다.
대부분의 방법론은이 효과에 대응하는 방법을 고안했습니다. 그러나 결국 우리는 오직 인간 일 뿐이며 완벽하지 않습니다. 게다가, 종종 시간 압력이 있고 대부분의 방법론 마술은 종종 압력을받는 동안 생략됩니다.
테스트는 문제를 조기에 감지 할 수 있습니다. 그러나 테스터조차도 인간이며 100 %를 테스트하는 것은 불가능합니다. 유니버스가 끝나기 전에 해제하려면
소프트웨어 결함의 주요 원인은 프로그래머라고 생각합니다.
말하는 아니 그냥 재미로,하지만 난 내 직업에서 관찰 한 가장 큰 문제 중 하나이기 때문에 빈약 한 요구 사항은 프로젝트의 주요 결함 및 유용성 문제를 일으키는 원인이되는 문제 영역의 이해 부족과 함께, 수집.
그 중 일부는 최종 사용자의 용어를 기꺼이 배우거나 이해하지 못해 오해의 원인이됩니다.
그 중 일부는 프로세스 초기에 기술에 대해 너무 일찍 이야기하여 자신이 무엇을 말하고 있는지 또는 왜 중요한지를 알지 못하는 사람들에게 제공됩니다.
가장 좋은 예는 질문 / 답변이 문자로 얼마나 오래 갈지 알아 내려고 노력하는 프로그래머 중 한 명을 들었을 때였습니다. 데이터베이스에서 사용할 크기 필드를 알아 내려고한다는 것을 알고 있었지만 이를 요청하는 부서는 왜 중요한지 또는 그 수를 세는 지에 대해 가장 안개가 끼지 않았습니다. 우리에게는 분명해 보이지만 그들에게는 실제 계시였습니다.
결함의 주요 원인은 나쁜 관리입니다 .)
진지하게, 좋은 상태에서 일하고, 과로하지 않고, 품질을 낮추고, 적절한 도구를 가지고, 조용한 작업 조건을 유지하는 개발자는 어려운 압력을받는 사람보다 버그가 적습니다.
또한 나쁜 개발자를 고용하는 경영진은 버그 수를 늘리는 데 도움이됩니다.
나쁜 관리 .
(면책 조항 : 개발자를 고용하고 관리해야합니다)
한 가지 주요 원인은 보이지 않지만 언급되지 않은 한 가지 원인은 의도하지 않은 다른 코드와의 결합입니다 . 보이지 않는 부작용이 있고, 추상화 계층을 돌파하며, 데이터에 대한 가정 (변수가 없거나, 상수가 아니며 사용자의 입력이 안전하지 않음)을 염려하지 않아도됩니다. 그 자체로 등등.
내가 공부 한 대부분의 개발 관행 N은 프로그램의 복잡성이 적어도 O(N^2)가능 하기 때문에 축소로 귀결된다 O(k^N). 정의 N는 독자에게는 연습으로 남겨 두지 만 여기서 순환 복잡성 같은 것을 생각하고 있습니다. 논리와 데이터를 캡슐화하면 문제를 구획화하여 N을 줄이는 효과가 있습니다.
완전히 이해하지 않고 사물에 빠지다. 기능 요구 사항 또는 기술 아키텍처를 완전히 이해하지 않고 코드 작성을 시작합니다.
프로그래밍은 거의 자동으로 이루어져야하며, 자명하고 이미 마음에 이미 작성된 프로그램을 작성하면됩니다. 실제로 코드에서 수행해야 할 작업을 정확하게 처리하기 위해 코드에 많은 결함이 있음을 알았습니다. 나는 여러 번 유죄를 선고 받았다.
소프트웨어 엔지니어링은 본질적으로 복잡하기 때문입니다. 에세이 "No Silver Bullet"은 이에 대해 논의합니다.
아이러니하게도, 여기에 나오는 다른 많은 답변들은 그 에세이의 언어로 "사고 적으로 복잡한"주제에 대해 다루지 만, 실제로 소프트웨어 개발자들이하는 대부분의 작업은 "본질적으로 복잡하다". 소프트웨어는 어렵고, 소프트웨어에는 버그가있을 것이며, 우리의 임무는 소프트웨어를 다루는 것입니다.
상태 머신의 네트워크로서 소프트웨어를 이해하지 못하고, 동작의 기본 원리 (상태, 결정 및 전환) 및 상태 머신의 상호 작용.
"일어날 수 없다"거나 일어날 가능성이없는 것들을 확인하지 못하는 것은 큰 일입니다. 때로는 완벽한 것이 선의 적입니다. 잘 고려 된 예외 계층 구조의 가치가 없다면, 빠르고 더러운 처리는 항상 아무것도 아닌 것보다 낫습니다. 나는 거대하다릴리스 빌드에서 성능에 거의 영향을 미치지 않는 단식, 단언, 단언 등의 팬. 모든 입력 데이터를 제어하는 빠르고 더러운 일회성 스크립트에서도 일반적으로 assert와 동일하지만 항상 유지되는 함수를 사용하여 일부 빠른 / 더러운 오류 처리를 수행합니다. 내 경험에 따르면, 발생하지 않을 수 있거나 발생할 수 없다고 생각되면 사용자 친화적 인 오류 메시지로 정상적으로 실패 할 필요는 없지만 최소한 다음과 같은 오류 메시지로 빠르게 실패해야합니다. 프로그래머에게 무엇이 잘못되었는지에 대한 힌트를 제공합니다.
편집 : 관련된 유용한 전술 중 하나는 assert를 주요 디버깅 도구로 사용 하고 디버깅 세션이 끝난 후에도 그대로 두는 것입니다 . 그 시점부터 코드베이스에는 관련 버그가 다시 발생하기가 매우 어려워지는 내장 검사 기능이 내장되어 있습니다. 이것은 단위 테스트하기 어려운 코드에 특히 유용합니다.