누구도 완벽하지 않으며, 우리가 무엇을 하든지, 때때로 버그가있는 코드를 생성 할 것입니다. 새 소프트웨어를 작성하거나 기존 코드를 변경 / 유지할 때 생성하는 버그 수를 줄이는 방법 / 기술은 무엇입니까?
답변:
화려한 코딩을 피하십시오. 코드가 복잡할수록 버그가있을 가능성이 높습니다. 일반적으로 현대 시스템에서는 명확하게 작성된 코드가 빠르고 작습니다.
사용 가능한 라이브러리를 사용하십시오. 유틸리티 루틴을 작성하는 버그가없는 가장 쉬운 방법은 작성하지 않는 것입니다.
더 복잡한 것들을위한 몇 가지 공식적인 기술을 배우십시오. 복잡한 조건이있는 경우 펜과 종이로 잘 정리하십시오. 이상적으로는 몇 가지 증명 기술을 알고 있어야합니다. 코드가 정확하다는 것을 증명할 수 있다면, 수정하기 쉬운 크고 멍청한 명백한 버그를 제외하고 거의 항상 좋습니다. 분명히, 이것은 지금까지 갔지만 때로는 작지만 복잡한 것에 대해 공식적으로 추론 할 수 있습니다.
기존 코드의 경우 리팩토링 방법, 종종 자동화 된 도구를 사용하여 동작을 변경하지 않고 코드를 더 읽기 쉽게 만드는 코드를 약간 변경하는 방법에 대해 알아 봅니다.
너무 빨리 아무것도하지 마십시오. 올바른 일을하고, 행한 일을 확인하고,하고있는 일에 대해 생각하기 위해 약간의 시간을 미리 내면 나중에 큰 시간을 할애 할 수 있습니다.
코드를 작성했으면 코드를 잘 활용하십시오. 단위 테스트는 훌륭합니다. 테스트를 미리 작성하는 경우가 많으며, 이는 피드백이 될 수 있습니다 (일관 적으로 수행하면 테스트 중심 개발). 경고 옵션으로 컴파일하고 경고에주의하십시오.
다른 사람이 코드를 보도록하십시오. 공식적인 코드 검토는 좋지만 편리한 시간에 있지 않을 수 있습니다. scm이 비동기식 검토를 허용하지 않는 경우 요청을 가져 오십시오. 친구 확인은 덜 공식적인 검토 일 수 있습니다. 페어 프로그래밍은 두 쌍의 눈이 모든 것을 볼 수있게합니다.
단위 테스트를 통해 두 번째로 나타나는 버그 수를 줄일 수 있습니다. 코드에서 버그를 발견하면 단위 테스트를 작성하여 나중에 다시 나타나지 않도록하십시오. (또한 모든 경우를 생각하고 수천 단위의 단위 테스트를 미리 작성하는 것은 때로는 어려운 일입니다)
두 단위 테스트 설명에 +1
그 외에도 컴파일러에서 제공하는 최고 경고 수준을 설정하고 경고가 오류로 처리되는지 확인하십시오. 버그는 종종 "오류"오류에서 숨겨집니다.
마찬가지로 컴파일 타임에 실행되는 정적 분석 도구에 투자하십시오 (이를 추가 수준의 컴파일러 경고로 간주합니다).
언급 된 것 외에도 :
내가 지금 잊어 버린 다른 많은 것들이 있지만 다른 사람들은 분명히 그것들을 생각할 것입니다. :)
기본 언어는 C ++ 및 Python 임에도 불구하고 상당히 기능적인 프로그래밍 스타일을 개발했습니다. 모든 컨텍스트를 함수 (또는 메소드)에 전달하면 해당 함수가 작업을 수행해야하고 의미있는 데이터를 반환하면 코드가 훨씬 강력 해집니다.
암시 적 상태는 적이며 내 경험상 버그의 # 1 소스입니다. 이 상태는 전역 변수 또는 멤버 변수 일 수 있지만 결과가 함수에 전달되지 않은 항목에 의존하는 경우 문제를 요청합니다. 분명히 상태를 제거하는 것은 불가능하지만 최소화하는 것은 프로그램 신뢰성에 큰 긍정적 영향을 미칩니다.
또한 동료들에게 모든 분기 (예 :? : :)가 버그 일 가능성이 있다고 말합니다. 버그의 징후가 무엇인지 말할 수는 없지만 코드의 조건부 동작이 적을수록 실행 중 코드 적용 범위가 더 일관성이 있기 때문에 버그가 없을 가능성이 높습니다.
이 모든 것들도 성능에 긍정적 인 영향을 미칩니다. 승리!
약간 덜 기술적 인 답변 : 피곤하거나 (9h / day면 충분 함) 취하거나 '구운'상태 일 때는 프로그래밍하지 마십시오. 피곤할 때 깨끗한 코드를 작성하는 데 필요한 인내심이 없습니다.
단위 테스트 및 도구에 관한 몇 가지 훌륭한 답변이 있습니다. 내가 그들에게 추가 할 수있는 유일한 것은 이것입니다 :
가능한 빨리 테스터를 참여 시키십시오
테스트 팀이 있다면 코드 품질의 게이트 키퍼로 취급하고 결함을 잡아내는 함정에 빠지지 마십시오. 대신, 그들과 함께 일하고 가능한 한 빨리 참여하십시오 (민첩한 프로젝트에서는 이것이 프로젝트의 시작부터 이루어 지지만, 실제로 시도하면 항상 더 일찍 참여할 수있는 방법을 찾을 수 있습니다).
테스터와 좋은 관계를 유지한다는 것은 나쁜 가정과 결함이 손상되기 전에 조기에 파악할 수 있음을 의미합니다. 또한 테스터는 제품 설계를 돕고 해결할 시간이있을 때 유용성 문제를 포착 할 수있는 권한이 있다고 생각합니다.
코드 검사 또는 페어 프로그래밍과 같은 다른 형태의 동료 검토.
Fagan 검사와 같은 구조화 된 코드 검토 는 최소한 단위 테스트 만큼 효과적이고 효율적일 수 있으며 경우에 따라 단위 테스트보다 나은 것으로 입증되었습니다. 검사는 소프트웨어 수명주기 초기에 코드 이외의 아티팩트와 함께 사용할 수도 있습니다.
Karl Wiegers의 Software의 Peer Reviews는 이 주제에 관한 훌륭한 책입니다.
여기에 많은 좋은 답변이 있지만 몇 가지 추가하고 싶었습니다. 실제로 요구 사항을 이해해야합니다. 사용자가 요구 사항이 X를 의미한다고 생각하고 프로그래머가 Y를 의미한다고 생각했을 때 많은 버그를 보았습니다. 열악하거나 모호한 요구 사항에 대한 설명을 위해 다시 푸시하십시오. 나는 우리 모두가 뛰어 들고 코딩하는 것을 좋아하지만 이해를 보장하는 데 더 많은 시간을 할애할수록 재 작업과 버그 수정이 줄어 듭니다.
지원하는 비즈니스에 대해 알아보십시오. 요구 사항에 누락되거나 추가 설명이 필요한 사항이있는 경우가 종종 있습니다. 명시된대로 작업 Y를 수행하면 기존 기능 Z가 중단됩니다.
데이터베이스 구조를 이해하십시오. 많은 버그는 구문 적으로 올바른 쿼리의 결과이지만 잘못된 결과를 반환합니다. 결과가 재미있을 때 인식하는 방법을 배웁니다. 복잡한보고 쿼리를 작성하는 경우 항상 기술 전문가가 내 결과를 검토 할 준비가되기 전에 내 결과를 검토하도록하여 필자가 놓친 데이터에서 무언가를 보게됩니다. 그런 다음 자신이 파악한 내용을 메모하고 다음에 비슷한 것을 할 때 기억하십시오.
사용 코드 검사 도구 같은 ReSharper에서 또는 같은 IDE를 하게 IntelliJ IDEA 많은 복사 및 붙여 넣기 예를 들어 있다고 변수 지적에 의해 버그와 다른 사람을 "에 기록됩니다,하지만 읽어 본 적이"에 대해 경고한다. 많은 시간을 절약했습니다.
놀랍게도, 다음 세 가지 중요한 점은 아직 언급되지 않았습니다.
어설 션을 자유롭게 사용하십시오. 항상 스스로에게 물어봐야 할 질문은 "내가 이것을 주장해야 하는가?"가 아닙니다. "어설 션을 잊어 버린 게 있나요?"
불변성을 선택하십시오. (최종 / 읽기 전용을 자유롭게 사용하십시오.) 변경이 적은 상태 일수록 문제가 더 적을 수 있습니다.
조기 최적화하지 마십시오. 많은 프로그래머들이 성능 문제에 대해주의를 기울여 성능이 문제가 될지 여부를 사전에 알지 않고도 불필요하게 코드를 복잡하게 만들고 설계를 개성있게 만들었습니다. 먼저, 성능을 무시하고 소프트웨어 제품을 학문적 인 방식으로 구축하십시오. 그런 다음 성능이 저하되는지 확인하십시오. (아마도 그렇지 않을 것입니다.) 성능 문제가있는 경우 전체 코드베이스를 조정하고 해킹하는 대신 제품이 성능 요구 사항을 충족하도록 멋지고 공식적인 알고리즘 최적화를 제공 할 수있는 하나 또는 두 곳을 찾으십시오. 여기 저기 클락 사이클.