좋은 책과 좋은 글은 한번 쓰여지고 여러번 읽힌다. 읽히고 나서 끝이 아니라 다른 글에서 다시 만나 다시금 생명력을 얻게 된다. 이렇게 좋은 글은 꾸준히 인용되어 그 삶을 계속 연장해나간다. "실용주의 프로그래머(The Pragmatic Programmer)"도 그런 종류의 책이다. 소프트웨어 엔지니어링 분야의 수 많은 책과 글들이 이 책을 인용하고 있다.
이 책의 부제는 'From Journeyman to Master(숙련공에서 마스터로)'다. 초보자에서 중급자를 넘어 마스터로 넘어가기까지는 굉장히 많은 경험과 노력이 필요하다. 소프트웨어 분야가 특히 그렇다. 새로운 언어와 프레임워크의 등장으로 누구나 쉽게 '코딩'을 할 수 있게 되었다. 이제 동작하는 코드는 누구나 만들 수 있다. 하지만 정말 잘 짜여진 코드를 작성하는 법은 마치 장인이 공예품을 만드는 것처럼 많은 경험과 노하우가 필요하다.
"실용주의 프로그래머"를 읽으며 오랜 경력을 자랑하는 소프트웨어 장인에게 가르침을 받는 듯한 느낌을 받았다. 이 책에는 최신 소프트웨어 트렌드나 언어, 개발 툴 같은 이야기는 없다. 하지만 그 모든 것들을 관통하는 소프트웨어 엔지니어링의 철학과 개발자가 가져야 할 자세 등을 다룬다. 개발자가 더 훌륭한 개발자가 되도록 안내해주는 탈무드 같은 책이다.
책을 다 읽고 기억에 남는 몇 가지를 정리해 보겠다.
1. DRY (Do not Repeat Yourself)
책의 도입부부터 마지막까지 중복의 해악에 대해서 끊임없이 강조하고 있다. "Do not Repeat Yourself". 줄여서 DRY 원칙은 소스코드나 개념 등을 여기저기 중복해서 가지고 있지 말라는 격언이다.
소스코드는 항상 변화한다. 실행되는 환경이 변할 수도 있고, 고객의 요구사항이 바뀔 수도 있다. 버그가 발견되어 버그 패치를 해야할 수도 있다. 그런데 버그가 있는 동일한 코드가 프로젝트 여기저기에 중복되어 존재한다고 하면, 중복된 코드 중에 버그패치를 누락할 가능성이 높아진다. 유지보수에 드는 비용이 높아지는 것이다. (프로그래머는 항상 중복된 코드가 어디어디에 위치해있는지 파악하고 있어야 한다.) 따라서 중복된 코드는 하나의 메소드로 묶어서 뽑아내고(Extract) 중복된 코드 대신 뽑아낸 메소드를 호출하도록 해야한다.
DRY 원칙은 비단 소스코드에 국한되지 않는다. 소스코드의 동작을 기술하는 문서 역시 같은 원리로 중복되면 안된다. 가장 좋은 방법은 Javadoc 문서처럼 소스코드에서 자동생성되도록 만들어 주는게 좋다. 팀 구성에서도 DRY 원칙은 좋지 않다. 즉, 팀의 서로 다른 구성원이 같은 작업을 하고 있는 경우, 리더는 같은 일이 다른 구성원에 의해서 중복 수행 되는 것을 보고 있어서는 안된다.
2. 직교성
소프트웨어를 구성하는 각 모듈드은 서로 직교해야한다. 즉, 하나의 모듈에서 발생한 변경사항이 다른 모듈로 전파되어 나가서는 안된다. 이는 모듈간 결합도를 최소한으로 하도록 소프트웨어를 설계해야한다는 의미다.
3. 툴의 힘
개발자는 공예품을 만드는 장인과 같다. 장인들은 작품을 만들기 전에 항상 도구를 정비한다. 오랜 기간동안 장인들이 사용해온 도구를 보면 장인의 손에 맞게 맞춤화가 되어 있다. ('생활의 달인' 같은 프로그램을 보면 장인들이 도구를 얼마나 중요하게 여기는지 알 수 있다. 그들에게 도구는 신체의 일부나 마찬가지다)
개발자들도 마찬가지로 프로그래밍에 사용하는 개발 도구들을 신체의 일부처럼 사용할 필요가 있다. 자주 사용하는 IDE의 플러그인은 잘 세팅되어 있는지, 단축키 설정은 손에 맞게 잘 되어 있는지 등등...
개발에 사용하는 여러가지 툴 중에 하나는 꼭 마스터하도록 하자.
4. 테스트
"우연에 맡기는 프로그래밍"이라는 말이 있다. "코드를 작성하다보니 어찌어찌 잘 돌아가는 것 같다...", "잘 돌아가니까 더 살펴보지 않아도 되겠지?". 왜 동작하는지 모르지만 잘 동작하는 것처럼 보이는 코드는 나중에 버그가 발견되었을 때, 왜 버그가 있는지 알 수 없다. 우연에 맡기는 프로그래밍을 하지말고 의도적으로 프로그래밍을 해라.
소프트웨어의 각 모듈들이 반드시 만족해야하는 동작들은 테스트 케이스로 쌓아놔야 한다. 잘 작성된 테스크 코드는 소스코드보다 더 좋은 자산이 될 수 있다. 모든 버그는 한번만 잡아야 한다. 잡았던 버그가 나중에 다시 등장하지 않도록 테스트 케이스라는 안정장치로 막아놔야 한다. 테스트 케이스가 꼼꼼하게 작성되어 있다면 코드를 유지보수하는데 좀 더 자신감있게 임할 수 있다.
소프트웨어에서 버그는 종양이다. 암 세포와 같은 버그는 발견 즉시 수정되어야 하며, 일찍 찾아서 제거할 수록 전체 프로젝트에 주는 위험도가 줄어든다. 늦게 발견하거나 발견해도 모른체해버리면 그 버그는 무럭무럭자라서 프로젝트 전체를 망치게 된다. 소스코드를 유지보수하면서 항상 테스트하고 버그가 발견되면 일찍 잡아야 한다.
5. 지식의 포트폴리오
개발자로 살면서 가장 힘든 것 중에 하나가 너무나도 빨리 변화하는 개발 트렌드다. 자고 일어나면 새로운 프레임워크가 등장하고 있다. 새로운 언어는 계속해서 쏟아져 나오고 있고, 기존에 사용하던 언어도 빠르게 기능들을 추가하고 있다. 조금이라도 게으르면 오래된 기술과 함께 나 자신도 잊혀져 아무도 찾지 않게 될 것 같다.
문제는 너무나도 많은 기술들이 빠르게 쏟아져 나온다는데 있다. "실용주의 프로그래머"에서는 '지식의 포트폴리오'라는 단어를 설명하고 있다. 마치 금융 포트폴리오처럼 기술의 포트폴리오를 구성해보는 것을 이야기하고 있다.
1) 주기적인 투자
- 주기적으로 새로운 기술 습득에 공을 들여야한다. 조금씩이라도 모이면 큰 자산이 될 수 있다.
2) 다각화
- 다양한 기술들을 알고 있어야 한다. 하나만 파지말고 다른 여러 기술들을 두루 알고 있는게 좋다. 모든 기술 역량을 하나의 기술에 올인을 하게 되면, 그 기술이 사라질 때 같이 사라지게 될지 모른다.
3) 리스크 관리
- 금융 상품처럼 기술도 리스크관리가 필요하다. 계란을 한 바구니에 담지마라. 투자처를 분산시켜서 리스크 관리를 하라는 말이다. 기술 포트폴리오에서도 마찬가지로 리스크 관리가 필요하다.
4) 싸게사서 비싸게 팔기
- 기술이 본격적인 궤도에 오르기 전에 미리 알아두면 좋다. 얼리 어답터들은 큰 이익을 얻을 수 있다. 항상 트렌딩 토픽에 귀를 열고 기다리자.
5) 검토 및 재조정
- 우리가 몸담고 있는 이 업계는 매우 빠르게 변화한다. 지난달부터 탐구하기 시작한 기술이 지금에는 완전 식어버릴 수도 있고, 한동안 사용하지 않았던 DB 기술을 다시 복습해야 할 수도 있다.
마치며..
한 챕터 한 챕터가 좋은 프로그래머를 가기 위한 길잡이가 되어 주는 아주 고마운 책이다. 개발자로 일하는 동안 책장에 두고 생각날 때마다 조언을 구해보고 싶은 책이다.
본 포스트에서 담은 내용은 이 책의 극히 일부분이다. 개발자로 일을 하는 사람이라면 꼭 한번씩 읽어보는 것을 추천한다.
댓글