같은 건 없다. 도전해야 한다.

6장. 경로 탐색하기

코드 속에서 방향을 가늠하게 해주는 단서들을 찾아야 한다.

결국 코드에 답이 있나니, 코드를 보아야한다. 문서가 있을 수도 있지만, 현황 업데이트가 안되어있을 가능성이 매우 높다. 마음을 비우고 코드를 보자. 당신은 개발자다!

맡게 된 서비스의 주요 API들을 호출해보고, 해당 API의 코드를 보면서 눈으로 디버깅 해보면 매우 좋다. 이때 디버거는 사용하지 않는다. 바로 본인이 디버거이다. 따라가보면서 코드의 수준도 파악하고 프로젝트의 구조를 파악해야한다. 유닛 테스트가 있다면 유닛 테스트도 같이 보자. 성공 케이스, 실패 케이스에 대해 파악할수 있기 때문에 큰 도움이 된다.

건전한 빌드는 하나의 단계만으로 수행되며,

꿈에 그리던 입사를 했다. 이제 신나게 개발해봐야지! 했는데, 빌드부터 안될수 있다. 쭈그리처럼 옆에 선임 개발자에게 가서 '이거 어떻게 해야해요...?' 물어봐야한다. 그러면 선임은 놀랍게도... /Users/GOIN_WATER/project 를 바라보는 변수를 수정하고 있을 수도 있다. (이런데 윈도우 PC를 지급받았다면 도망치자, 반대의 경우도.) 이런 흑역사들이 어딘가에 문서로 남아 있을리는 오산이다. 경기도 오산도 집값이 많이 올랐다. 정신을 차리고 살아야한다. 이런건 과감하게 고쳐보자. 선임들이 정말 좋아할 것이다. 그렇다고 너무 과감하게 도커(docker)까지 도입하면 싫어할 수 있으니, 차근차근 단계적으로 나아가 보자. (도커를 도입하지 않을 이유가 없어도 싫어할 수 있다. 도커로 빌드하기 위해 당신을 뽑은 것이 아니기 때문이다. 다른 업무를 하기 위해서 뽑은 것이기에, 딴짓한다고 싫어할 수 있다. 모든 개발자들이 이 글을 읽고 있는 당신과 동일하다고 생각하지 말자.)

코드를 배우는 가장 좋은 방법은 수정해보는 것이다. 그런 다음 실수를 통해 배우라.

아이러니하게도 가장 큰 깨달음을 얻는 건 에러나 장애를 발생시켰을 때이다. 이런 실수들은 잘 잊을 수도 없다. n^2번의 쿼리로 장애를 내봐야, 다시는 그렇게 작성하지 않는다. 실수를 하지 않는 것이 가장 좋겠지만, 우린 신이 아니다. 간혹 실수를 허용하지 않는다고 말하는 개발자가 있다면, 코드를 살펴보라. 정말 완벽할 수도 있지만, 거의 대부분이 하던대로만 할 것이다. 이런 사람은 업무는 잘하지만, 기술적으로 배울 건 없다. 이런 사람에겐 업무하는 법만 배우면 된다.(주어가 개발자에서 사람으로 바뀌었음에 주목하자.)

중요하지 않은 것처럼 보이는 잡다한 버그를 수정하는 일도 거부하지 말자. 사소해보이는 버그도 쌓이고 쌓이게 되면 치명적일 수 있다. 해결할수 있는 사람이 없어서 방치되고 있었을 수도 있다. 테스트 작성 및 수정도 귀찮아하지 말자. 시스템의 규모가 커질수록 테스트의 필요성은 익스포넨셜로 증가한다.

경험이 쌓일수록 고통은 줄어들고 이득은 커진다.

코드 작성도 삶과 똑같다.