분석

원문: Lessons From 9 More Years of Tricky Bugs2002년부터 저는 제가 마주친 모든 까다로운 버그를 추적해왔습니다. 9년 전, 그때까지의 버그에서 얻은 교훈을 담아 블로그 글을 작성했습니다. 그 이후로 기록해온 버그들을 이번에 전부 다시 돌아봤습니다. 첫 번째 회고에서 정리했던 교훈들을 실제로 잘 실천해왔는지 확인하고 싶었고, 그사이 어떤 유형의 버그들을 마주쳤는지도 살펴보고 싶었습니다. 이전과 마찬가지로 교훈을 코딩, 테스팅, 디버깅의 카테고리로 나눠 정리했습니다.코딩1. 빈 케이스. 다섯 개의 버그가 빈 줄, 빈 파일, 공백, 또는 값이 0인 경우와 관련이 있었습니다. 예를 들어, 공백 한 칸(0이 아닌)이 있는 줄은 비어있는 것으로 건너뛰어야 했지만 그렇지 않았습니다..

02 알고리즘 분석 (04 ~ 05) 04 알고리즘 시간 복잡도 분석 4.1 도입 두 알고리즘의 속도를 비교하는 가장 직관적인 방법은 각각을 프로그램으로 구현한 뒤 같은 입력에 대해 두 프로그램의 수행 시간을 측정하는 것이다. 하지만 프로그램의 실행 시간은 알고리즘의 속도를 일반적으로 이야기하는 기준이 되기에는 부적합하다. 가장 큰 이유는 프로그램의 수행 시간은 사용한 프로그래밍 언어, 하드웨어는 물론이고 운영체제, 컴파일러까지 수 많은 요소에 의해 바뀔 수 있기 때문이다. 두 번째 이유는 실제 수행 시간이 다양한 입력에 대한 실행 시간을 반영하지 못하기 때문이다. 알고리즘의 수행 시간을 지배하는 것은 반복문이다. 입력의 크기가 작을 때는 반복외의 다른 부분들이 갖는 비중이 클 수가 있지만, 입력의 크기..