문제를 진단하기 위해 코드를 고쳤을 때 아무런 효과가 없다면 원했던 부분을 고친 게 아니다. 혹시 고친 파일이 아닌 다른 파일을 컴파일 하는건 아닌지? 컴파일을 제대로 해놓곤 다른 바이너리를 실행하는건 아닌지? 고친 코드가 프리프로세서 때문에 비활성화돼 있는건 아닌지? 브라우저가 개발 서버가 아닌 제품 서버에 접속하는 건 아닌지? 이런 함정은 너무 흔하고 햇갈려서 빠지기 쉽다. 항상 마음 한구석에 함정에 대한 가능성을 염두에 두는 것 외에는 다른 방도가 없다. 함정에 빠진 것을 알 수 있는 가장 쉬운 방법은 코드에 일부러 명확한 실패 코드를 추가하는 것이다. 명백한 에러 문법을 추가하거나 System.exit() 를 호출하는 방법도 있다. 이렇게 해도 컴파일이 잘 되고 프로그램도 죽지 않고 실행된다면 내..
코딩을 하다보면 같은 곳에 여러 버그가 발생하는 경우가 있습니다. 이 때 개발자는 문제들을 동시에 해결하고 싶은 유혹에 빠지게 됩니다. "이왕 하는김에 다 고치면 좋지 않나요?" 물론 너무너무너무 간단한 문제라던가 운 좋게 모든게 정상 동작할 수도 있습니다. (혹은 그렇게 보일수도) 하지만, 이는 매우 위험한 생각이며 시간 좀 아끼려다 야근각이 나오기 일수입니다. 어떤 버그를 잡으려고 실험하다 보면 다른 버그에 영향을 줄 수 있어 현재 정확히 어떤일이 벌어지고 있는지 알기 어려워집니다. 심지어 버그 하나에 원인이 여러개인 경우에는 스스로의 함정에 빠지기도 합니다. 개인적으로 아무리 경험이 쌓이고 능숙해져도 디버깅이란 이미 충분히 어렵고 고된 작업입니다. 쓸데없이 흙탕물을 만들지 말고 한 번에 한 문제 만..
- Total
- Today
- Yesterday
- 코드스멜
- 코드악취
- 지시의 언어
- AWS
- amazon aurora
- aws fargate
- https
- 그림으로 공부하는 IT 인프라 구조
- 매개변수화
- 그림으로 배우는 HTTP & Network
- 일 잘하는 사람은 단순하게 말합니다
- 리팩터링이란
- HTTP
- SSL
- Debug It! 실용주의 디버깅
- Debug
- 위임
- Refactoring
- 안심 첫 문장
- 박소연
- 조건부 로직
- 변경함수
- 리팩토링
- 일잘러
- 질의함수
- 제어플래그
- amazon vpc
- 디버깅
- 마틴파울러
- Debugging
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |