이 용어는 당신이 생각하는 것보다 더 문자 적입니다.

모든 프로그래머가 버그에 익숙하다고해도 안전합니다. 정의에 따라 프로그래밍 버그는 다음과 같이 설명됩니다.

컴퓨터 프로그램 또는 시스템의 오류, 결함 또는 결함으로 인해 부정확하거나 예상치 못한 결과가 발생하거나 의도하지 않은 방식으로 작동합니다 — Wikipedia.

의도하지 않게 코드를 코드에 몰래 넣는 데 일부를 사용했거나 다른 사람의 디버깅을 통해 문제를 해결할 가능성이 있습니다. 결국 버그는 무한 루프에서 0으로 나누기, 초기화되지 않은 변수 사용에 이르기까지 모든 것이 될 수 있습니다! 이 예제는 단순한 간과가 코드에서 원치 않는 동작을 의미 하는 방법을 보여줍니다 .

경우에 따라 버그의 정확한 근본 원인을 정확히 찾아 내기가 어려운 경우가 있습니다. 특히 일부는 코드에서 관련없는 내용을 손상시킬 수 있기 때문입니다. 이러한 잘못된 플래그는 종종 다른 원인이 원인이라고 생각하게합니다. 그러나 대부분의 편집기는 개발자가 코드를 매우 쉽게 디버그 할 수 있도록하여 디버그 모드 에서 솔루션을 실행할 수 있습니다 . Visual Studio Code는 디버그 모드를로드하는 버튼에 작은 버그 아이콘이있는 용어를 포함합니다. GitHub는 문제를 제기 할 때 사전 정의 된 레이블 중 하나로 용어를 포함합니다. 그리고이 단어는 스탠드 업에있는 개발 팀 사이에서 이따금 씩 던져집니다. 그러나 그 용어가 어디서 왔는지 궁금한 적이 있습니까? 생각보다 훨씬 더 많이 되돌아갑니다!

기계적 오작동

이 맥락에서 버그에 대한 가장 초기 기록 된 언급은 프로그래밍 및 심지어 컴퓨터보다 앞서 있습니다. 하드웨어 엔지니어링의 기계적 오작동을 설명하기 위해 1870 년대에 처음 사용 된 것으로 생각됩니다. Thomas Edison은 1878 년 그의 발명품을 설명 할 때 동료에게 보낸 편지에서이를 "작은 결함과 어려움"으로 묘사했습니다.

그 이후로 핀볼 게임 은 "버그가없는"것으로 광고되었고 군사 장비의 문제는 버그로 묘사되었으며 영화 제작자는이 용어를 스크립트에 추가하기 시작했습니다. 이 용어는 기계 발명 및 일상적인 기계에서 원치 않는 동작을 설명하는 데 점점 인기를 얻었습니다.

소프트웨어 프로그래밍에 관해서는 솔루션에있는 오류의 가능성에 대해 처음 쓴 사람은 Ada Lovelace였습니다. 그녀는 Charles Babbage의 분석 엔진 (범용 컴퓨터)이 삽입 된 프로그램 카드에서 잘못된 명령을받을 가능성에 대해 우려를 표명했습니다. 즉, 예상과 다른 명령을 수행하는 것입니다. 그렇지 않으면 버그라고합니다.

약 100 년 후, 가장 특이한 만남은 그 용어의 기원을 설명 할 때 가장 먼저 기억되는 사람이 될 것임을 확인했습니다.

실제 버그

인정해야하는데, 컴퓨팅의 맥락에서 실제 버그와의 만남이 역사에 기록 되었다는 사실을 읽고 즐거웠습니다 . 전자 컴퓨터 Mark II의 운영자는 컴퓨터 연구실의 Harvard 교수진에서 유명한 컴퓨터 과학자 Grace Hopper가 작업했습니다. 기계의 릴레이 중 하나에 나방이 갇혀 오작동을 일으키는 것을 발견했습니다.

조심스럽게 곤충을 제거한 후, 그들은 "버그가 발견 된 첫 번째 실제 사례"라는 주석과 함께 기계 로그의 페이지에 그것을 테이프로 붙였습니다.

곤충에서 재해로

심각하게 말하면 소프트웨어 버그가 발견되지 않고 제거되면 심각한 결과를 초래할 수 있습니다. 다음은 역사상 소프트웨어 버그로 인한 가장 유명한 재해입니다.

화성 기후 궤도 선

NASA는 사용 된 측정 시스템 간의 불일치로 인해 화성 기후를 연구하기 위해 1998 년에 발사 된 화성 기후 궤도 우주선을 잃었습니다. 지구에서 탐사선을 제어 한 내비게이션 팀은 영국 단위의 매개 변수를 사용했으며 우주선 소프트웨어는 미터법을 사용했습니다. 이 단위를 미터법으로 변환하지 못하면 궁극적으로 NASA가 수백만 달러의 비용을들이는 Orbiter의 궤적을 잘못 계산했습니다.

Therac-25

경우에 따라 이러한 버그는 컴퓨터 사용자에게 치명적일 수 있습니다. 이것은 1982 년에 개발 된 컴퓨터 제어 방사선 요법 인 Therac-25의 경우였습니다. 프로그래밍 오류로 인해이 기계는 때때로 암 환자에게 정상보다 100 배 더 많은 방사선 량을 주어 심각한 부상을 입었습니다. 환자들은 방사선 중독 증상과 함께 며칠 후 방사선 화상을 보였습니다. 부상당한 환자 중 3 명은 나중에 과다 복용으로 사망했습니다.

워싱턴과 캘리포니아 대학의 연구 에 따르면 소프트웨어에 대한 과신이 허용 가능한 소프트웨어 엔지니어링 관행에 미치지 못하는 것으로 추정되는 요인과 함께 기여 요인이라고 결론지었습니다.

Knight Capital Group 주식 거래

2012 년에 Knight Capital Group (2013 년에 운영을 중단 한 미국 글로벌 금융 서비스 회사)은 시스템의 소프트웨어 버그가 약 150 개의 주식을 잘못 거래하기 시작한 후 30 분 만에 4 억 4 천만 달러의 손실을 입었습니다. Knight는 이벤트가 발생한 후 여름에 경쟁자 Getco LLC에 인수되었습니다.

Apple지도

Apple Maps는 Apple OS의 기본지도 앱으로 Google Maps를 대체한다는 아이디어로 2012 년 9 월에 처음 출시되었습니다. 그러나이 앱은 잘못된 기본 위치 데이터를보고하는 전 세계 사용자들에게 즉시 신뢰할 수없는 것으로 간주되었습니다. 보고서에는 자유의 여신상 실종, 병원으로 잘못 분류 된 플로리다 슈퍼마켓, 홍콩 섬에서 몇 마일 떨어진 곳으로 표시된 홍콩 등이 포함되었습니다.

코드 대 개발자 대 프로세스

버그에 대한 책임은 누구에게 있습니까? 이 주제에 대한 논쟁의 대부분은 어떤 소프트웨어도 완전히 버그가 없을 수 없다는 개념에 있습니다. 어떤 사람들은 '벌레'라는 용어가 그것이 사람이 만든 것이라는 생각과 이혼한다고 주장합니다. 버그는 코드 특정 오류뿐만 아니라 설계 결함 및 잘못된 프로세스에서 발생할 수 있다는 점도 언급 할 가치가 있습니다. 파견 시스템을 전산화 런던 구급차 서비스 (LAS) (CAD)는 따라서 관련 여러 당사자 연루 - 자사의 프로젝트 관리도 눈살을 찌푸리게 한 경우 -이 명확한 예입니다.

요약

이러한 맥락에서 버그라는 용어는 1800 년대 전자 공학과 관련하여 처음 언급 된 것으로 밝혀졌으며 Ada Lovelace는 소프트웨어가 면제되지 않을 것이라는 우려를 표명했습니다. 전자 컴퓨터의 릴레이 내부에서 발견 된 물리적 버그를 포함하여 그 당시에도 버그가 혼란을 야기한 것으로 보입니다. 어떤 경우에는 비용이 많이 들고 그 결과는 회사와 소비자 모두에게 되돌릴 수 없습니다.

의심 할 여지없이 소프트웨어 개발자의 삶의 일부이지만, 요즘에는 프로세스 초기에 그들을 잡기 위해 많은 일을 할 수 있습니다.

대부분의 경우 각 디버깅 도구는 주로 하나 또는 두 개의 특정 언어를 대상으로합니다. 다음은 해당 언어와 함께 찾은 몇 가지입니다.

• Rookout — JVM, Node.JS 및 Python 코드를 디버깅하는 데 사용됩니다. Rookout에서 원격 디버깅을 사용할 수있을뿐만 아니라 스테이징 및 프로덕션 애플리케이션을 모두 디버깅 할 수 있습니다.
• Zend Studio — PHP 솔루션의 코드 편집, 테스트 및 디버깅 용.
• Visual Studio 및 Visual Studio Code — .NET 솔루션을 디버깅하는 데 유용하며 후자는 원격 개발 확장 팩에 대한 액세스를 제공합니다 (동료가 멀리서 코드를 디버그하는 데 유용합니다!).
• 크롬 DevTools로 - 확실히 잘 알려진 개발자 도구! Chrome DevTools는 CSS 및 JavaScript 디버깅에 매우 유용합니다. 또한 소스 코드에 적용하기 전에 다양한 스타일의 프로토 타이핑을 허용합니다. Chrome이 당신의 것이 아니라면 Firefox 에는 자체 개발자 도구도 있습니다.
• GDB — C, C ++, Go, Pascal, Rust 등을 지원하는 매우 다재다능한 디버거입니다.
• Eclipse — C #, Python, Ruby 및 PHP도 지원하는 유명한 Java 개발 용 IDE입니다.
• 기본 디버거 반응 - 를 들어, 이름이 제안 할 수 있습니다로, 당신의 반응 네이티브 디버깅을 모두!