디버깅에 너무 많은 시간을 소비


24

어제 저는 약 6 주 동안 작업 한 웹 프로젝트의 v1.0 릴리스를 시작했습니다. 나는 정확한 시간을 기록하지 않았지만 내 경험에 따르면 프로그래밍하는 데 소요되는 시간 중 절반은 디버깅에 소비되었다고 추정합니다. 나는 디버깅에 약 15-20 시간이 걸리는 것으로 추정합니다. 새 코드를 작성하거나 프로젝트를 일찍 완료하는 데 더 나은 시간을 보냈습니다. 또한 5 주 안에 대학에서 신입생이되는 데 특히 도움이되지 않습니다.

문제는 디버깅하는 데 시간이 많이 걸리는 것입니다. 디버깅에 소비 한 모든 시간은 프로젝트를 개발하는 동안 꽤 바보 같은 실수를 저질렀다는 것을 깨닫게 해주었습니다.

앞으로 이런 일이 발생하지 않도록하려면 어떻게해야합니까? 디버깅 시간의 50 %를 사용하고 싶지 않고 10 %의 디버깅과 나머지는 새 코드 작성에 소비하고 싶습니다. 이 목표를 달성하는 데 도움이되는 몇 가지 기술은 무엇입니까?


22
내가 신입생이었을 때 나는 느리게 코더였다. 20 년만 줘
Job

27
그래, 행운을 빌어 "디버깅이 버그를 제거하는 프로세스 인 경우 프로그래밍은 버그를 처리하는 프로세스 여야합니다." -Edsger Dijkstra
Matt

7
그 실수로부터 무엇을 배웠습니까? 그럴 경우 다음에 만들지 않아도되므로 디버깅 시간이 줄어 듭니다.
Craig T

5
이것을 "경험"이라고하며 다음 프로젝트 에서 도움이 될 것 입니다.

4
1940 년대 후반에 Maurice Wilkes는 다음과 같이 썼습니다. "프로그래밍을 시작하자마자 우리는 생각했던대로 프로그램을 얻는 것이 쉽지 않다는 것을 알게되었습니다. 디버깅은 발견되어야했습니다. '계단의 각도에서 망설이는'EDSAC 방과 펀칭 장비 사이의 나의 여정은 저의 남은 인생의 많은 부분이 내 자신의 프로그램에서 오류를 발견하는 데 소비 될 것이라는 강력한 힘으로 실현되었습니다. "
트레버 파월

답변:


35

소프트웨어 엔지니어링의 성배를 요구하고 있으며 아직이 질문에 대한 "답변"을 가진 사람은 없습니다.

중요한 것은 수행중인 오류 유형을 추적 한 다음 이러한 오류를 분석하여 공통 추세가 있는지 확인하는 것입니다. 근본 원인 분석은 이러한 유형의 내부 검사에 대한 공식적인 이름이며 이에 관한 웹에는 많은 자료가 있습니다.

전문가들은 버그 추적 시스템을 사용하여 (1) 수정해야 할 사항을 알 수있을뿐 아니라 (2) 사후 수정해야 할 사항을 분석 할 수 있습니다. 당신은 그렇게 정식 일 필요는 없습니다. 노트북에 탈리 만 두는 것이 좋습니다.

설계 단계 결함

대부분의 오류가 문제 설명에 대한 오해에서 비롯된 것임을 발견하거나 계속해서 문제를 해결하기 위해 따라야 할 잘못된 알고리즘이나 경로를 선택한 경우 설계 단계에 문제가 있습니다.

프로젝트를 시작할 때 더 많은 시간이 걸리고 수행해야 할 작업과 수행 방법을 정확하게 작성하는 것이 좋습니다. 이 작업을주의 깊게 검토하고 원래 문제를 다시 검토하여 실제로 올바른 방식으로 문제를 해결하고 있는지 확인하십시오. 시작시 1 시간 또는 3 시간이 더 걸리면 많은 시간을 절약 할 수 있습니다.

코딩 오류

디자인이 견고하지만 코딩하는 언어와 끊임없이 싸우고 있다면 코드를 분석하고 조기에 경고하고 종종 실수를 저지르는 몇 가지 도구를 사용하십시오.

C로 프로그래밍하는 경우 모든 컴파일러 경고를 켜고와 같은 의미 검사기 lint를 사용하고 valgrind일반적인 동적 메모리 관련 문제를 포착 하는 것과 같은 도구를 사용하십시오 .

펄을 프로그래밍하는 경우에 설정 strict하고 warnings그것이 말하는 무엇을주의.

어떤 언어를 사용하든 디버깅 단계에 도달하기 전에 일반적인 실수를 잡는 데 도움이되는 많은 도구가있을 수 있습니다.

통합 단계 결함

훌륭한 모듈화 사례에 따라 코드를 개발할 때는 별도의 조각을 함께 붙여야합니다. 예를 들어, 코드의 다른 섹션은 사용자 입력, 데이터베이스 상호 작용, 데이터 표시, 알고리즘 / 논리와 관련이있을 수 있으며 각 섹션은 서로 독립적으로 구축됩니다 (즉, 해당 섹션에 집중하는 경향이 있음) 다른 모든 것들과의 통합에 대해 걱정하기보다는).

여기에 TDD (Test Drived Development)가 매우 유용합니다. 코드의 각 모듈에는 설계된 방식에 따라 작동하는지 확인하는 테스트가있을 수 있습니다. 이러한 테스트는 프로세스 초기에 작성되거나 매우 빠르므로 정직하게 유지하기 위해 "도우미"를 가질 수 있습니다. 모든 것이 함께 작동하기 시작하고, 이것이 구현되거나 다른 하위 시스템과 상호 작용하는 방식을 변경해야한다는 것을 알게되면 테스트를 다시 수행하여 수행 한 작업이 수행되었는지 확인할 수 있습니다. 그것은 모두 함께 작동하여 코드의 정확성을 깨뜨리지 않습니다.

등등...

소프트웨어 엔지니어링과 실용적인 코딩 기술에 관한 책을 집어 들고 개발을 혼란스럽고 신뢰성있게 만드는 다양한 방법을 배우게됩니다. 또한 딱딱한 노크 스쿨에서 학위를 취득하면 평범한 오래된 경험을 통해 몸매가 좋아질 것입니다.

거의 모든 것이 마무리되는 것은 약간의 시간과 선행 작업이 나중에 개발 / 릴리스 프로세스에서 큰 배당금을 지불한다는 것입니다.

경력 초기에 이러한 문제를 발견했다는 사실은 미래에 잘 어울리므로 행운을 빕니다.


1
이것은 엄청나게 대답하지만 엄청나게 다른 질문에 대한 IMHO입니다. OP는 무언가를 쓰는 데 6 주가 걸렸으며 디버깅에 많은 시간을 소비했다고 말합니다. 우리는 아직 그의 제품의 품질, 유지 보수성, 확장성에 대해 아무것도 모른다. 우리가 TDD, 좋은 디자인, 버그 추적을 가정한다면, 결함을 줄이면서 코드 (디버그해야하는 테스트 코드 포함)를 작성하는 방법에 대한 의문이 여전히 남아 있습니다. 경고를 설정하고 보푸라기 등을 사용하는 것이 좋습니다. 하드 노크 학교에서 더 많은 사람들이 있습니까? :-)
Guy Sirton

1
@Guy-예. OP의 질문은 약간 모호했습니다. 그래서 근본 원인 분석에 중점을 두었습니다. 무엇이 잘못되었는지 알기 전에는 무엇이 잘못되었는지 알 수 없습니다. 내가 문제 영역에 대한 설문 조사를 한 이유는 그가 많은 잠재적 인 함정을 알고 싶어했고 프로세스의 각 단계마다 자체 검사가 필요하기 때문입니다. 내가 아는 바에 따르면, 그는 다음 Tony Hoare가 될 수 있지만 맹인 코끼리의 타이핑 기술을 가진 사람 일 수 있습니다.
unpythonic

37

쓰기 단위 테스트

코드에 대한 단위 테스트를 작성하면 아키텍처에 대해 생각하게되고 코드를 작고 신중하게 제어되고 테스트 가능한 부분으로 작성하도록 장려합니다. 이를 통해 디버깅 노력이 크게 줄어들고 수행하는 적은 양의 디버깅이 작고 엄격하게 집중된 코드 조각으로 제한됩니다.

또한 작성하는 테스트는 코드를 "덮습니다". 기존 테스트 중 하나 이상이 실패하기 때문에 코드 변경으로 인해 문제가 발생하는시기를 알 수 있습니다. 이는 디버깅 작업의 전반적인 복잡성을 줄이고 코드 작동에 대한 자신감을 높입니다.

물론, 이제는 디버깅에 소비 한 시간이 테스트를 작성하는 데 소비됩니다. 그러나 한 번만 작성하면되며, 작성한 후 필요한만큼 실행할 수 있습니다.


단위 테스트의 경우 +1-개발 프로세스 초기에 버그가 더 저렴하고 쉽게 해결됩니다.
Paul R

26

광범위한 의미에서 디버깅을위한 50 %가 그렇게 나쁘지는 않습니다. 사람들은 일반적으로 실제 코드를 작성하는 것보다 설계, 테스트, 버그 수정, 리팩토링 및 단위 테스트 작성에 훨씬 더 많은 시간을 소비합니다. 그것은 일의 일부입니다.

솔직히 말해서, 유지 보수 프로그래밍에서는 훨씬 더 나쁩니다. 정확히 잘못 된 것을 파악하는 데 1 시간을 보내고 코드를 수정하는 코드를 작성하는 데 5 분이 걸리고 전체를 테스트하는 데 30 분이 걸렸습니다. 이는 5 % 이상의 코딩과 거의 95 %의 비 코딩입니다.

그래도 디버깅 시간을 줄이기 위해 할 수있는 몇 가지가 있습니다.

  • 디버깅 가능한 코드를 작성하십시오 . 즉, 올바른 오류 처리 (생각해 놓은 생각 포함), 코드를 쉽게 따라 잡을 수 있도록 구성, 어설트, 추적 등 디버거의 삶을 더 편하게 할 수있는 모든 것을 의미합니다. 복잡한 선을 피하십시오. 둘 이상의 작업을 수행하는 행을 분할하여 개별적으로 단계별로 진행해야합니다.
  • 테스트 가능한 코드를 작성하십시오 . 코드를 간단한 함수 (또는 선택한 언어가 지원하는 다른 것)로 나눕니다. 단위 테스트에서는 포착하기 어렵 기 때문에 부작용을 피하십시오. 독립적으로 실행할 수 있도록 기능을 설계하십시오. 다목적 기능을 피하십시오. 엣지 케이스를 피하십시오. 당신의 기능이 무엇을해야하는지 문서화하십시오.
  • 테스트를 작성하십시오 . 단위 테스트가 있다는 것은 함수의 입력 중 적어도 일부에 대해 함수가 작동한다는 것을 의미합니다. 또한 변경 사항이 아무런 영향을 미치지 않는지 확인하기 위해 온 전성 검사가 있음을 의미합니다. 코드 범위 및 입력 범위의 개념과 단위 테스트의 한계를 이해해야합니다.
  • '워크 벤치'를 설정하십시오 . 이 작업을 정확히 수행하는 방법은 해당 언어에 따라 다릅니다. Python 또는 Haskell과 같은 일부 언어에는 대화식 인터프리터가 제공되며 기존 코드를로드하여 재생할 수 있습니다. 버그를 찾아 격리하는 데 매우 유용한 도구 인 최소한의 노력으로 원하는 컨텍스트에서 함수를 호출 할 수 있기 때문에 완벽합니다. 다른 언어에는 이러한 고급 기능이 없으므로 대화식 테스트 프로그램을 거의 작성하지 않아도됩니다.
  • 읽을 수있는 코드를 작성하십시오 . 의도를 최대한 명확하게 표현하기 위해 코드를 작성하는 습관을들이십시오. 완벽하지 않은 모든 것을 문서화하십시오.
  • 간단한 코드를 작성하십시오 . 자신의 두뇌가 전체 코드베이스를 이해하는 데 어려움을 겪는다면 간단하지 않으며 다른 사람이 완전히 이해할 수 없을 것입니다. 코드를 이해하지 않으면 코드를 효과적으로 디버깅 할 수 없습니다.
  • '삭제'버튼을 누르십시오 . 지금 필요하지 않은 코드는 휴지통에 속합니다. 나중에 필요할 경우 소스 제어에서이를 소생 시키십시오 (경험에 따르면 이는 매우 드 rare니다). 더 많은 코드를 폐기할수록 디버깅 표면이 더 작아집니다.
  • 자주 그리고 자주 리팩토링하십시오 . 리팩토링이 없으면 새 기능을 추가하는 동안 코드를 디버깅 가능한 상태로 유지할 수 없습니다.

1
또한 문제가 발생할 경우 세상은 예상과 다르게 행동 할 수 있습니다. 이로 인해 매우 미묘한 버그가 발생할 수 있습니다.

2
+1. 디버깅 노력에 50 % 만 소비하는 것은 특히 낮지 만 특히 확립 된 코드베이스에서는 그렇지 않다고 말하고 싶습니다. 버그가 할당 된 경우 코드의 관련 부분을 거의 완전히 다시 작성해야하지 않는 한 (불확실한 경우) 잘못 된 부분을 파악한 다음 수정 프로그램을 테스트하는 데 총 시간의 일부보다 훨씬 더 많은 시간을 소비 할 수 있습니다. 수정 자체는 종종 빠르며 종종 한 줄 또는 몇 줄의 변경된 코드에 해당합니다.
CVn

@ ThorbjørnRavnAndersen 지옥, 특히 OP 언급과 같은 웹 프로젝트의 경우. 우리는 이번 주 직장에서 문자 인코딩 으로 즐거운 시간을 보내고 있습니다.
Izkata

5

더 많은 계획

디버깅에 많은 시간을 할애하는 것이 불가피합니다 .10 %는 야심 찬 목표입니다. 디버깅 및 개발에 소요되는 시간을 줄이는 가장 좋은 방법 중 하나는 계획 단계에서 더 많은 시간을 보내는 것입니다.

이것은 다이어그램에서 계획 패드의 의사 코드까지 다양합니다. 어느 쪽이든 개발 중에 실수를 저지르는 계획을 세우는 데 더 많은 시간을 할애 할 수 있습니다.


1
이것이 디버깅 시간을 줄이기 위해하는 일이므로 +1입니다. 새로운 프로젝트를 시작할 때, 나는 주석으로 할 모든 것을 기록한 다음, 주석을 코드로 대체한다
CamelBlues

나는 코멘트와 똑같이하고, 내가 그만 둔 곳을 잊지 않도록합니다. 그러나 나는 종이와 그 의존성에 클래스 다이어그램을 그리는 것을 좋아합니다. 이것은 내가 당시에 무슨 생각을했는지에 대한 좋은 통찰력을줍니다.
Bryan Harrington

5

보다 신중하게 작업

이것은 "한 번 두 번 측정"과 동등한 소프트웨어입니다.

  • 산만하거나 피곤하다고 느끼면 코딩하지 마십시오.
  • 깨끗하고 우아한 해결책이되도록 문제에 대해 충분히 생각하십시오. 간단한 솔루션에는 문제가 거의 없습니다.
  • 작업에 모든주의를 기울이십시오. 초점.
  • 코딩 후 코드를 빨리 읽고 실수를 찾아보십시오. 자기 코드 검토.
  • 코딩과 테스트 사이에 너무 오래 기다리지 마십시오. 즉각적인 피드백은 개선에 중요합니다.
  • 일반적으로 오류가 발생하는 일을 피하십시오. 코드 냄새를 읽어보십시오 .
  • 작업에 적합한 도구를 선택하십시오.

그러나 결함을 완전히 제거 할 수있는 것은 아무것도 없습니다. 이것을 인생의 사실로 받아 들여야합니다. 결함에 대한이 사실 계획이 주어지면 (예 : 단위 테스트). 또한 "영원히 가져 가라"(일명 분석-마비)를 의미하는 것으로 간주하지 마십시오. 균형을 찾는 것입니다.


4

다른 답변은 이미 말하고 싶은 대부분의 내용을 다루었지만 여전히 어쨌든 내 (거의 정직한) 의견을주고 싶습니다.

기본적으로 사소한 소프트웨어 작업의 경우 유지 관리 및 디버깅에 많은 시간을 할애해야합니다. 성숙하고 생산적인 소프트웨어 시스템에서 작업하고 있고 유지 관리 및 디버깅에 80-90 % 미만의 시간을 소비하고 있다면 잘하고있는 것입니다!

"유지 관리"와 "디버깅"의 구분은 약간 주관적입니다. "버그"만 릴리스 된 후 발견 된 코드와 사용자가 이에 대해 불평 한 코드의 문제라고 생각하십니까? 또는 무언가를 추가하면 (자체 시험판 테스트 단계에서) 코드에 문제가있는 작은 모든 것이 있습니까? 사소한 소프트웨어 시스템 (사용 패턴에 따라 다름)에서 하나는 다른 것보다 훨씬 클 수 있습니다. 그러나 어쨌든 이것은 장난감 "Hello world"프로그램보다 더 큰 프로그래밍이 필요한 것입니다-많은 유지 보수 및 디버깅. 어떤 사람들은 심지어 " 첫 번째 코드 줄 이후의 모든 것이 '유지 관리 모드'로 예상되어야합니다.

TL; DR : 간단하지 않은 소프트웨어 시스템을 프로그래밍하는 것에 대해 약간 비현실적인 그림을 가지고있을 것 같습니다. 대부분의 노력은 미세 조정, 유지 관리, 리팩토링, 버그 수정 및 일반적으로 완전히 새로운 새로운 작업을 수행하는 것과는 달리 최소한 매우 일반적인 의미에서 "디버깅"(유지 관리)에 해당하는 작업을 수행하는 것입니다. 새로운 코드를 작성합니다.


2

수행중인 작업과 사용중인 기술에 대한 세부 정보가 없으면 특정 기술을 제공하기가 어렵습니다. 그러나 정말 훌륭한 코더조차도 테스트와 디버깅에 많은 시간을 소비합니다.

많은 버그없이 좋은 코드를 작성하는 것은 경험입니다. 실수를 한 다음 고치면 실수가 무엇인지, 실수를 대신하기 위해해야했던 일을 기억하며 다음에 같은 실수를하지 않습니다. 그리고 아직 대학에 있지 않고 실수를 줄이는 방법에 대해 진지하게 생각하기 시작했다면, 확실히 당신이 게임보다 앞서 있다고 말하고 싶습니다.


1
내가 실수로 배우지 않는 사람들 (또는 그들이 배운 것을 기억하려고 귀찮게하는)을보고 놀란다. 그리고 얼굴에 무언가 큰 일이 일어 났을 때, 그들은 다음 프로젝트에서 돌아 서서 똑같은 일을합니다.
HLGEM

2

연속 적분 (CI)이 답입니다.

지속적인 통합 = 구성 관리 시스템 (즉, Git, Mercurial, SVN 등) + CI 도구 + 단위 테스트 + 연기 테스트

이 공식을 통해 CI (Continuous Integration)에 대한 자세한 내용을 읽어보십시오. 다음은이 영역의 일부 리소스입니다.


1

실제로 디버깅을 줄이려면보다 깊이있게 계획하여 프런트로드 할 수 있습니다. 아직 대학에 가지 않았습니까? 중학교에서 늦게까지의 대학 수업에서 여러분의 어리 석음을 밝게 비출 수있는 소프트웨어 개발 라이프 사이클에 대한 세부 사항을 다룰 것입니다.

고용주에게 설명하려고 할 때 코드 유지 관리 및 기술 지원을 줄이는 가장 좋은 방법은 코드를 사전에 포괄적으로 계획하는 데 시간을 보내는 것입니다.


1

테스트 중심 개발 은 다음을 통해 디버깅 시간을 줄일 수 있습니다.

  • 작고 집중적 인 테스트가 많다는 것은 실패 할 경우 문제를 일으킬 수있는 적은 양의 코드 만 있다는 것을 의미합니다.
  • 작은 단계로 작업 (실패한 테스트를 작성하여 통과)하면 한 번에 하나의 작업에만 집중할 수 있습니다. 즉, 현재 테스트를 과거로 만듭니다.
  • 테스트 패스를 만든 후 리팩토링하면 코드를 명확하고 이해하기 쉽게 유지하여 문제가 발생할 경우 쉽게 따라갈 수 있습니다.

TDD를 사용하더라도 디버거를 사용해야 할 때가 있습니다. 이 경우 디버깅 세션을 일으킨 시나리오를 재현하기 위해 단위 테스트를 작성해야합니다. 이렇게하면 해당 문제가 다시 발생하면 테스트에 실패했을 때 신속하게 파악 될 수 있으며 테스트는 문제를 일으킨 코드 영역에 대한 마커 역할을하여 디버깅의 필요성을 줄입니다.


1

프로그래밍에서 디버그는 불가피하지만 여기서 핵심은 코드를 쉽게 디버깅 할 수 있습니까? 간단한 것을 디버깅하기 위해 몇 시간을 소비해야한다면 코드 아키텍처에 실제로 문제가 있어야합니다.

깨끗한 코드를 작성하고 코드 붙여 넣기 및 긴 메소드 작성 등과 같은 나쁜 습관을 제거하는 데 익숙해야합니다.

게다가, 때때로 코드를 리팩토링해야합니다. Martin Fowler의 저서 : 리팩토링 : 기존 코드의 디자인 개선 을 읽어 보시기 바랍니다 .


1

다른 사람들은 테스트 및 코드 검토에 대해 언급했습니다. 이것들은 매우 유용하지만 중요한 차이점이 있습니다. 테스트는 원래 코드를 작성하는 것과 매우 가깝게 수행되므로 특정 방식으로 작업을 수행 한 이유를 더 쉽게 기억할 수 있고 테스트에 실패했을 때 문제를 더 빨리 찾을 수 있습니다. 반면에 코드 검토는 나중에 조금 더 잘 수행됩니다. 완벽하게 기억하지 않고 코드를 살펴 봐야한다고 생각하지만 기억하지 않은 세부 사항을 무시하지 말아야합니다. 코드가 명확하지 않은 장소를 실현하려고합니다. 코드가 수행하는 작업을 파악하기 위해 약간의 추가 노력이 필요합니다. 문제 나 다른 코드 또는 새로운 기술과의 상호 작용에 대해 얻은 새로운 지식을 적용하려고합니다. 원래,

그러나이 모든 것은 여전히 ​​당신의 질문에 접합니다. 디버깅 시간을 줄이려면 먼저 디버깅해야하는 이유를 이해해야합니다. 문제를 이해하고 도구와 기술에 대한 불완전한 지식을 이해하고 "실제 데이터가 샘플 데이터와 일치하지 않습니다"라는 일반적인 유형의 문제는 모두 다른 방식으로 나타나고 피하기 위해 다른 기술과 유형의 연습이 필요합니다. 앞으로.

마지막으로 할 일은 경험입니다. 이것을 얻는 쉬운 방법은 없습니다, 당신은 시간을 넣어야합니다. 경험을 쌓으면 시작하기에 더 나은 코드를 작성하고 문제를 조기에 발견하며 문제의 원인에 대해 더 나은 직관을 개발할 수 있으므로 디버깅 시간이 줄어 듭니다. 그것을 유지하고 당신은 당신의 경력을 통해 꾸준히 성장할 것입니다.


0

위의 큰 답변이지만 아무도 직접 언급하지 않았습니다 (이것에 대해 가장 많이 암시했지만) :

읽기 읽기 읽기 읽기 및 구역에서 ...

많이 알수록 알 수 없습니다. 약간 진부하지만 여전히 기본적인 진실.

위의 팁을 따르고 분석적으로 버그를 문서화 한 후에는 버그를 분류 한 다음 관련 문헌을 읽으십시오.

디자인 결정 문제입니까? 디자인 패턴을 읽으십시오.

프레임 워크 나 언어에 대한 지식이 부족 했습니까? 그것에 뼈!

기타

(실시간) 개발자가 절대 벗어날 수없는 두 가지가 있습니다 : IT 분야에서 유일한 상수 인 변경과 RTFMing ...


0

단위 테스트 및 주장

가능하면 코드를 작은 조각으로 분리하여 개별적으로 테스트 할 수 있습니다. 그러나 이것이 항상 실용적이지는 않습니다. 일부 기능은 매우 복잡한 입력에 따라 다릅니다. 일부는 화면에 물건을 그리는 등 자동으로 쉽게 확인할 수없는 일을합니다. 때로는 비결정론 등이 관련됩니다.

좋은 단위 테스트를 작성할 수 없을 때 다음으로 가장 좋은 것은 주장입니다. 단위 테스트는 미리 결정된 입력에 대한 정답을 얻는 지 확인하지만 실제 입력에 대한 중간 단계의 온 전성을 검사합니다. 코드에 버그가있는 경우 모호한 오류 메시지의 문제에서 멀지 않고 문제의 근원에 가깝고 명확한 오류 메시지와 함께 빠르게 실패합니다. 또한 문서 가정을 주장하고 코드를 더 읽기 쉽게 만듭니다.


0

프로젝트를 시작할 때 몇 가지 대체 접근법을 식별합니까?

각각에 대해 장단점이있는 2 가지에서 4 가지의 서로 다른 접근 방식이 있습니까? 그런 다음 그들 중에서 합리적인 선택을합니까?

그렇다면 가장 중요한 것은 단순함 을 중요하게 생각합니까?

필자가 경험 한 바에 따르면, 필자의 경험에 따르면 코드 볼륨과 버그 수 (성능은 말할 것도없고)는 한 설계 방식과 다른 설계 방식간에 차이가있을 수 있습니다. 경험이 많은 사람들이하는 일은 필요 이상으로 코드를 작성하지 않고 작업을 수행하는 것입니다.

그들은 객체 지향 언어의 기능, 등등, 그러나 그들의 코드를 완벽하게 유능하고 모든 데이터 구조 알고리즘의 인식 외모 그렇지 않은 것처럼 , 그들은 그 일을 사용하기 때문에 드물게 문제가 않는 경우, 전혀 없거나 필요하지 않습니다.


0

버그를 고칠 때마다 같은 실수를 다시하지 않기를 원합니다. 이를 위해 다음을 수행 할 수 있습니다.

  • 다음 을 포함 하는 결함 기록 로그기록하십시오 .

    • 결함 유형
    • 결함이 주입 된 단계
    • 제거 된 단계
    • 시간을 고치다
    • 문제에 대한 설명과 수정
  • 작성하는 코드 스타일을 정규화하기 위해 스타일 가이드를 채택하십시오.

  • 안전한 코딩 규칙을 코드 검토 프로세스에 통합

  • 제어 흐름데이터 시각화

참고 문헌

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.