실용주의 프로그래머 서평

The Pragmatic Programmer 20주년 기념판

실용주의 프로그래머란 무엇인가? 실용주의 프로그래머는 어떻게 작업하는가, 코드에 어떻게 접근하는가?

깨진 창문

‘깨진 창문’을 고치지 않은 채로 내버려 두지 말라. 나쁜 설계, 잘못된 결정, 혹은 형편없는 코드 등이 몯 깨진 창문이다. 발견하자마자 바로 고쳐라. 적절히 고칠 시간이 없다면 일단 판자로 덮는 것만이라도 하라.

머리가 띵하고 맞은 기분이었다. 너무 적절한 비유다. 깨진 창문 실제로 너무 많이 겪고 있는 문제다. 피드백과 마찬가지로 깨진 창문 역시 바로 고쳐야한다. 다음에 고쳐야지 하고 넘어가면 에러로 돌아온다. 그때는 원인을 알고 어떻게 고쳐야할지도 알고 있었을지도 모른다. 하지만 에러로 돌아왔을 때는 바로 고칠때보다 배의 시간이 들 것이다.

소통하라

개발은 팀으로 하는 것이다. 소통해야한다. 개발자들끼리의 소통뿐이 아니다. 고객, 기획자 등등 모두와 소통해야한다. 단순히 이야기를 나눴다고해서 소통한 것이 아니다. 전달하고자 하는 것이 제대로 전달되었는지 중요하다. 또 중요한 것은 소통하는 법이다. 나는 a의 감정으로 b의 정보를 전달했는데 상대가 c의 감정으로 d의 정보를 받는다면? 실패한 소통이된다. 오해가 쌓이고 단절이 된다. 후에 난 분명 바나나를 달라고 말했는데 어째서 바닐라가 온거죠? 하게 되는 샘이다. 또 일방적인 소통은 소통이 아니다. 티키타카가 되야한다. 소통을 해야 더 좋은 결과물이 나온다. 또 문서화를 반드시 해야한다. 문서화를 개별의 일로 만들지 말자. 귀찮아서 안하게 된다. 개발은 신규개발보다 유지보수가 80%라고 생각한다. 내가 만든 코드를 유지보수 하기보다 다른 사람의 코드를 유지보수 하는게 훨씬 많다고 느낀다. 고로 코드를 읽기 좋게 잘짜고 문서화해야한다.

요구 사항의 구렁텅이

신입 개발자들이 자주 범하는 실수는 이런 요청 사항을 받았을 때 바로 해결책을 구현해 버리는 것이다.

이것이 우리가 하는 일이다. 간단해 보이는 무언가를 받으면 특이한 경우에 대해 캐물어서 사람들을 화나게 하는 것 말이다

아주 공감가는 구절이다. 나 또한 자주 겪는 일이어서 더 와닿았다. 고객에게 요구 사항이 왔을 때 대부분의 고객은 자신의 요구사항을 제대로 알지 못한다. 개발뿐만이 아니다. 모든 일에서 그렇다. 나는 알바를 여러가지를 많이 해봤는데 손님의 요구사항을 그대로 들어주었다가 낭패를 본 일이 꽤 있다. 손님을 진상 손님, 나를 진상 손님과 대적하는 알바로 만들지 않기 위해 손님이 놓치고 있는 부분을 인지해줘야했다. 모든 일은 그렇다. 고객의 요구사항에서 고객이 미처 생각하지 못한 부분들을 그 사람이 화날 때까지 물어서 확인을 해야 정확히 원하는 무언가를 알 수 있다. 안타까운것은 그럼에도 불구하고 요구사항은 변한다는 것이다. 하지만 중심(?)은 잡을 수 있다.

적절한 예인지는 모르겠지만 너무 유명한 ‘카라멜 마키아또에서 카라멜 빼주세요.’, ‘생과일주스 시럽과 얼음빼고 갈아주세요’ 등 (이런건 평범한 요구라고 생각한다…ㅎ) 그렇다면 물어야한다. ‘카라멜 마키아또가 너무 달아서 그러시면 시럽을 원래 2펌프 넣는데 1펌프만 넣어드릴까요? ‘ 라던지 두번째 질문은 왜?라고 생각할 수 있다. 손님은 생과일주스를 신나게 받아서 한입먹고 화가나서 오신다 ‘이거 왜이렇게 맛없고 미지근해!!!’ 차고 단거를 많이 넣으면 건강에 안좋으니 시럽과 얼음을 뺏지만 맛없는 것은 참을 수 없는 손님인거다. 그렇다면 알려줘야한다. ‘시럽을 빼면 다소 맛 밍밍할 수 있습니다. 차가운게 싫으시면 얼음을 반만 넣어드릴까요?’ 이런식으로 물으면 손님은 다신의 요구사항을 더 구체적으로 변경한다.

실제 업무에서도 마찬가지다. 요구사항을 캐묻고 해결책을 구현한 뒤에도 문서화를 통해 고객의 요구사항을 구체화 시켜야한다. 지속적인 피드백을 받아야한다.

후기

개발자 생활 지침서같다. 책을 읽고 서평을 작성하면서 제일 기억에 남는 것은 무엇일까? 생각했을때 현재 내가 겪고 있는 문제들과 관련있는 토픽들이었다. 시간이 지난 후에 읽으면 다른 토픽들이 또 기억에 남을 것이다.