실용주의 프로그래머

생각

‘어?’ 금지.

*‘그럴 리가 없는데’*로 시작하면 여러분은 두말할 필요 없이 틀렸다. 왜냐하면 명백히 그 일은 일어났기 때문이다. 실제 문제는 여러분 눈앞에 있던 것에서 몇 단계 떨어져있고 또 다른 여러가지와 연관되어 있을 확률이 다분하다. 겉으로 드러난 특정한 증상만 고치려고 하지말고, 항상 문제의 근본 원인을 찾으려고 노력하라

우리는 우연한 사건들을 디버깅하느라 시간을 낭비할 여유가 없다. 일단 정확하게 관찰해야한다. 외부 업체로부터 인입된 버그보고서는 정확도가 훨씬 더 떨어진다. 자세한 정보를 충분히 얻으려면 해당 버그를 보고한 사용자가 시연하는 것을 눈으로 직접 확인해야 할 수도 있다.처음에 받은 자료 이상을 얻기 위해서 버그를 보고한 사용자를 인터뷰할 필요도 있다. CS 응대시 유저에게 카톡으로 하나하나 물어봐야 하는 상황. 유저의 말을 믿지 말 것.

그놈의(damn) 오류 메시지 좀 읽어라

이진 분할(분할 정복)- 일주일 전에는 괜찮았던 코드에서 언제부터 있었는지 모를 버그가 나타났다. 정확하게 어떤 변경 사항 때문에 버그가 발생했는지 알아낼 수 있다면 좋지 않을까? 그렇다 이진 분할이 등장할 시간이다. 대기업에서 코딩테스트 문제로 Binrary Tree알고리즘을 내는 이유는 실무하는데 그 알고리즘 코딩능력이 필요해서가 아니라, 이런 방식으로 사고할 수 있는 사람을 원하기 때문이다.

고무 오리 문제의 원인을 찾는 매우 단순하지만 꽤 유용한 기법으로 그냥 누군가에게 문제를 설명하는 방법이 있다. 그것만으로도 여러분이 찾고 있던 문제가 화면 밖으로 뛰쳐나와 모습을 드러낸다. 간단해 보인다. 하지만 누군가에게 문제를 설명하게 되면 혼자 코드를 살펴볼 때는 당연히 여기고 지나갈 것을 명시적으로 이야기해야 한다. 이런 가정 몇 가지를 입 밖에 내면, 문제에 대한 새로운 통찰을 불현듯이 얻을 수도 있다. 만약 들어 줄 사람이 없다면 고무 오리나 곰 인형, 화분도 괜찮다.

OS나 컴파일러 혹은 외부 제품에 버그가 있을 수도 있다. 하지만 처음부터 그런 생각은 하지는 말라. 개발하고 있는 애플리케이션 코드에 버그가 존재할 가능성이 훨씬 더 크다. 설사 외부 제품에 문제가 있더라도 버그 리포트를 제출하기 전에 여러분의 코드에 문제가 없다는 것을 확인해야 하는 것은 마찬가지다.

신롸할만한 대기업의 써드파티를 연결한 내 서비스에 장애가 발생했을 때 ‘네이버 문자 발송 서버에 문제가 있는 것 같습니다.’ or ‘AWS가 일시적으로 오류를 일으킨 것 같습니다.’ … That’s no no.. 대부분 문제는 내부에 있으며 ‘AWS API가 동작을 안합니다’ 같은 말은 내부 코드를 수백번 테스트해보고 하늘이 두쪽나도 내 코드는 문제가 없다고 자신할 수 있을 때 할 수 있는 말이다.