![나는 철인28호 FX보다 블랙옥스가 더 좋았다 💜 [철인 28호 FX]](https://i.ytimg.com/vi/o98Hqb4JBHM/hqdefault.jpg)
콘텐츠
출처 : Abscent84 / iStockphoto
테이크 아웃 :
사려 깊은 지도자는 개발 및 프로덕션 환경을 연결하기 위해보다 유동적 인 소프트웨어 릴리스 구조를 꿈꾸었지만 컴퓨터 프로그래밍에는 여전히 마법의 요소가 있습니다.
가장 기본적인 프로젝트조차도 코딩 작업을 한 사람은 프로세스에 인내심이 필요하다는 것을 알고 있습니다. 처음부터 코드를 작성하려는 수많은 함정은 인간 프로그래머 나 개발자가 잘못 할 수있는 모든 방법의 노래와 춤입니다. 긴 목록이며 일반적으로 컴파일러에 의해 잡히는 구문 오류부터보다 지능적인 검토가 필요한 더 깊은 "비전 수준"버그까지 모든 것을 포함합니다. 이를 위해 학교 및 교육 센터는 컴퓨터 과학 학생들에게 프로그램을 "디버그"하는 방법을 가르칩니다. 그러나 흥미로운 점은 모든 개인이이 도전에 대한 자신의 고유 한 반응을 개발한다는 것입니다. 실제로 이것은 약간의 개인적인 통찰력이 필요한 영역 일 수 있습니다. (컴퓨터 프로그래밍의 선구자에서 가장 중요한 프로그래밍에 대해 읽으십시오.)
디버깅 코드 : 완료 방법
일부 경우 컴퓨터 과학 전문가는 개발자 스튜디오 또는 프로그래밍 환경의 리소스를 사용하여 프로그램의 버그를 격리 할 수 있습니다. 그러나 이러한 종류의 오류 처리 또는 시스템을 사용할 수 없거나 유용하지 않은 경우 디버깅에는 코드를 한 줄씩 수행해야합니다. Microsoft Visual Basic Studio와 같은 많은 프로그래밍 환경에는 코드를 통해 명확하고 시각적으로 한 줄씩 단계별로 "스텝핑"할 수있는 기능이 있습니다.
코드를 단계별로 실행하면 두 가지 주요 방법이 도움이됩니다. 첫째, 프로그래머는 컴퓨터가 코드를 읽을 때 발생하는 상황과 재귀 함수 및 기타 코드 상호 작용의 관점에서 초점이 어디로 가는지 확인할 수 있습니다. 둘째, 프로그래머는 종종 마우스 오버 명령이나 인터페이스의 다른 부분을 사용하여 다른 변수의 값을 볼 수 있습니다. 변수에 어떤 값이 있는지 아는 것은 컴퓨터가 제공 한 코드로 무엇을하고 있는지 이해하는 핵심 방법입니다.
싸우는 버그
위에서 설명한 프로세스는 간단하게 들릴 수 있지만 실제 디버깅 문제는 훨씬 더 복잡 할 수 있습니다. 이 프로세스의 훌륭한 예는 전직 개발자이자 IT 전문가 인 엘렌 울만 (Ellen Ullman)의 기술 스릴러라는 제목의 글에서 문체가 문학적 방식으로 빛나고있다. 이 책은 허구이지만 프로그래머와 컴퓨터가 상호 작용할 때 실제로 어떤 일이 벌어지고 있는지에 대해 많은 정보를 제공합니다.
책에서 어둡고 개인적인 세부 사항을 많이 남겨두고 테스터와 프로그래머 인 Ullman의 두 인물에 대한 묘사는 소프트웨어 개발 초기에 이러한 경력 기술 전문가가 직면 한 주요 과제 중 일부를 보여줍니다. 기본적으로, 그녀가 "The Jester"라고 부르는 그녀의 버그는 1980 년대 소프트웨어 회사의 모든 직원을 피하고 직원 관계를 긴장시키고 투자자 신뢰를 무너 뜨리며 일반적으로 소동을 일으켰습니다. 한편 저자는 컴퓨터가 우리에게 어떤 영향을 미치는지, 왜 우리가 자신의 특질을 극복하기 위해 "기계처럼 생각해야"하는지에 대해 약간 생각합니다. 프로그래밍 역사에 대해 배우려면 컴퓨터 프로그래밍 : 기계 언어에서 인공 지능에 이르기까지 컴퓨터 프로그래밍을 확인하십시오.
버그가 캡쳐를 피하는 이유
울만 (Ullman)의 책에서 다루기 어려운 버그가 다루기 어려운 이유 중 하나는 이상한 시간에만 팝업되기 때문입니다. 이러한 도전은 다른 많은 결함에 실제로 적용됩니다 (사용자가 런 어웨이 프리우스에 대한 소문을 낸 후 Toyota의 광범위한 시도를 기억하십시오). 누군가가 당신에게 버그가 있다고 말한다고 가정하자. 컴퓨터에 문제를 일으킬 수 없다면, 문제를 해결하기 위해 어디서부터 시작해야합니까?
책 끝 부분에서 밝힌 바와 같이이 결함이 발생하는 이유는 그 당시 개인용 컴퓨터에 대한 코드 작성의 복잡성, 그리고 아마도 우리 시대의 또 다른 훌륭한 예입니다. 본질적으로 버그는 다른 코드 조각에 기본 방향을 제공하는 작은 중첩 함수에 숨겨져 있습니다. 타사 프로그래머가 작성했으며 프로그래머 간의 의사 소통 부족으로 인해 문제의 실제 원인은 몇 달 동안 숨겨져있었습니다. 문제에 대한 진정한 증거는 부적절하게 문서화 된 팀워크에서 발생할 수 있습니다.
컴퓨터 버그와 관련하여 까다로운 디테일은 다른 방식으로 주문 된 시스템을 혼란에 빠뜨릴 수 있습니다. 따라서 우수한 코딩 기술은 때로는 과학보다 더 예술적 일 수 있으며 (Ullman은이를 "광기"라고 부름) 코딩을 본질적으로 지저분한 사업으로 만듭니다.
버그 없음, 스트레스 없음-인생을 파괴하지 않고 인생을 바꾸는 소프트웨어를 만드는 단계별 가이드
아무도 소프트웨어 품질에 신경 쓰지 않으면 프로그래밍 기술을 향상시킬 수 없습니다.
디버깅의 철학
프로그래머는 결과를 얻기 위해 종종 사람이 아닌 컴퓨터와 협력해야합니다. Ullman은 코더와 테스터가 인간의 사고의 모든 뉘앙스를 제거하고 추론을 기본 논리 컴퓨터 사용으로 제거 할 수있을 때 가장 효과적이라고 말합니다. 이것은 우리가 명확하게 초점을 맞추기 위해 우리 모두가 매일 함께 할 일을 많이 버리는 것을 의미합니다. 대부분의 프로젝트를 위해 더 많은 프레임 워크가 설치되어있는 시대에도 많은 컴퓨터 과학 전문가들이 번성 할 수있는 것이 바로이 품질입니다.
사려 깊은 지도자는 개발 및 프로덕션 환경을 연결하기 위해보다 유동적 인 소프트웨어 릴리스 구조를 꿈꾸었지만 컴퓨터 프로그래밍에는 여전히 마법의 요소가 있습니다. 그렇기 때문에 최고의 프로그래머는 단순한 구조적 코더가 아닙니다. 그들은 점점 더 의존하는 기계의 기능을 위협하는 버그를 근절하고 수정하려는 본능을 가지고 있습니다.