『Becoming a Better Programmer』요약하며
이 글은 훌륭한 프로그래머 되는 법 『Becoming a Better Programmer』(피트 구들리프 지음) 을 제 나름대로 정리한 내용입니다. 큰 내용은 책에서 모티브를 얻었으나 제 생각을 많이 반영해서 재구성하였습니다.
디버깅이 소프트웨어 버그를 없애는 과정이라면, 프로그래밍은 분명 버그를 만드는 과정이다.
- 에르허르 데이크스트라, 컴퓨터 과학자
당신이 위대한 프로그램을 만들고 있는가? 어쩌면 당신은 웅장한 버그를 만들고 있을지도 모른다.
뛰어난 프로그래머는 뛰어난 수비수이다. 상대의 모든 공격에 대비한다. 비정상적인 상황까지 커버한다. 갑자기 메모리가 부족하게 된다면? 갑자기 용량이 부족해진다면? 서버에 많은 사람이 몰리게 된다면? 갑자기 아마존과 구글이 망하고, 클라우드 서버가 정지된다면??
여러 비정상적인 일은 언제나 나타난다. 지진이 일어나 전력이 끊겨 IDC의 데이터가 날아갈 수 있다. 사람들이 미친듯이 들어와서, 때아닌 디도스 공격이 펼쳐지기도 한다. 악의적인 해커가 허술한 틈새를 노리고 있을지 모른다. 회사의 보안 담당자가 비밀번호를 password123으로 했을지도 모른다.
몇몇의 주석은 마치 그림판을 보는 것 같다. 개발자로써 당신의 예술성을 보여주고자 하는 마음은 이해하지만 주석으로 표현하는 것은 좋지 않다.
/************************************************************
*************************************************************
*** 경고 : 요기는 며칠있다가 제가 고칠거니까 건드리지 맙시다 *****
*************************************************************
************************************************************/
눈길을 끌기 위해 아스키 아트를 하지 말자. 긴 설명문을 적지 말자.
좋은 코드는 긴 설명문이 필요없다. 코드의 의미가 명확히 드러나지 않을 때 주석은 길어질 수 밖에 없다. 명심하자. 가장 좋은 코드는 주석을 달 필요도 없는 코드이다.
각 팀마다 코드 스타일은 다를 수 있다. 그러나 혼자만 다르면 문제다. 공백을 스페이스로 할 것인지, 탭으로 할 것인지. 2칸인지 4칸인지. 혼자만 다르면 서로 피곤해진다. 칸이 다르면 코드를 잘못 이해할 확률이 비약적으로 높아지고, 다시 칸을 맞추다 팀이 붕괴될 수 있다.
남이 쓴 코드는 언제나 똥통이다. 그러나 모든 똥통엔 원인이 있다. 우리가 할 일은 도대체 왜 이런 사태가 생긴건지 알아야한다. 원인을 모르면 코드는 똥통 그대로의 모습으로 발전할 것이며, 더욱 더 크고 거대한 똥통이 될 것이기 때문이다.
모든 프로그래머가 아무 생각없이 코드를 쓰지 않는다. 코드를 적은 사람은 그게 최선이라고 생각했고, 그 안에는 적어도 논리가 존재한다. 우리가 할 일은 그 논리를 알아야하고, 과거 버전에선 어떤 논리로 진행했는지 알아야 한다. 이를 모른다면 막상 만들어놓고, 과거의 똥통을 답습하는 안타까운 상황을 맞이할 수 있다.
당신이 천재라고 가정해보자. 당신은 매우 복잡한 기능을 기발한 알고리즘으로 구현했다. 완벽하게 기능을 구현하며 함축적이고, 아름답고, 감동적이기까지한 이 코드는 대부분의 동료들이 이해하기 어려운 수준이다. 동료 프로그래머들은 아름다운 구조를 무너뜨릴까봐 건드리기도 두렵다. 이런 코드를 쓰면 당신의 일자리는 코드가 사라질 때까지 보장되는 장점이 있다.
반면 어떤 코드는 재밌는 만화같다. 구조는 간단하고, 기능은 명확하다. 이해하기 쉽고, 기능과 기능은 분리되어있다. 코드는 더 길지라도 어렵지 않다.
코드 시인은 프로그래머의 로망이다. 그러나 우리는 팀 대결을 하고 있다. 팀원이 알아들을 수 없는 말은 의미없다. 혼자만 이해하는 코드는 혼자만 유지보수할 수 있다. 버그를 해결할 사람이 1명 뿐인 개발팀은 제대로 굴러갈 수 없다. 팀과 소통하는 코드를 쓰자.
대부분의 버그는 몇몇의 한정적인 알고리즘에서 발생한다. 그렇지 않다고? 그 프로그램은 글렀다. 대부분의 정상적인 프로그램은 버그들이 숨어있는 장소가 정해져있다. 우리는 이 코드를 급습하기 보단 침착할 필요가 있다. 주먹구구식으로 때려잡으려하다간 새로운 빈틈으로 쏙 들어가는 버그를 볼 수 있을 것이다.
먼저 상대를 인정하고, 프로세스를 명확히 이해해보자. 각각의 프로세스 중에서 분명 냄새나는 부분이 있을 것이다. 이제 그 코드를 가두자. 한 번에 모든 버그를 잡을 순 없다. 하나하나 구역별로 단위 테스트를 진행하자. 단위 테스트를 하면서 견고한 논리를 발견해야 한다. 버그가 나타나는 원인을 명확히 알게 되면, 그때서야 우리는 제대로 버그를 고칠 능력이 생긴 것이다.
프로그래밍의 세계는 정글과 같다. 누가 이길지 모른다. 데스크탑, 모바일, 태블릿, IoT 등 영역은 점점 넓어지고 쓰이는 기술은 끝이 없다. 아무리 뛰어난 프로그래머라도 모든 언어와 모든 프레임워크를 이해하지 못한다. 또한 이미 만들어진 뛰어난 라이브러리, 플러그인, 오픈소스 등을 모조리 이해한 프로그래머는 없다. 그렇기 때문에 성장을 하고자 한다면 성장할 수 있는 부분이 무한에 가깝다 할 수 있다.
뛰어난 프로그래머는 다음의 질문에 쉽게 답할 수 있을 것이다.
현재 무엇을 배우고 있는가?
5년 후를 위해서 무엇을 배우고 있는가?
당신은 겸손한 프로그래머인가?
개발도중 문제를 발견했을 때 가장 먼저 하는 일이 구글 검색인가?
남이 짠 코드를 이해하기 전에 복사 붙여넣기 하는가?
우리에겐 뇌가 있다. 그리고 생각할 수 있다. 그러나 놀랍게도 많은 프로그래머는 생각하는 일을 힘들어한다. 이미 많은 문제들이 스택오버플로우에 풀려져있기에 그대로 가져다가 쓴다. 조금 수정해서 쓴다. 그러다가 문제가 발생하면? 다시 검색해본다.
이 루프에 빠져있다면 결코 성장할 수 없다. 늘어나는건 프로그래밍이 아닌 검색 실력일 것이다. 남이 쓴 코드는 근본적으로 남이 쓴 코드다. 내가 쓸 코드는 내가 생각해서 써야한다.
악마가 유혹한다. "이걸 만들어봐!" "이건 어때?" 개발자들은 생각보다 대단하다. 몇몇의 기능은 며칠이면 뚝딱 만들 수도 있다. 그러나 그게 꼭 좋을까?
한 프로덕트 매니저는 자신이 하는 일이 무엇인지 이렇게 대답했다.
제 일은 괜찮은 아이디어를 쓰레기통으로 보내는 일입니다.
좋은 소프트웨어는 괜찮은 아이디어가 아닌 최고의 아이디어가 필요하다. 만들다보면 쉬운 아이디어는 계속 나타나기 마련이고, 모든 프로젝트는 진행되면서 온갖 아이디어들이 충돌하고, 변신하고, 승리하는 것을 반복한다. 그럴 때 우리는 최고의 아이디어에 집중해야한다. 괜찮은건 깔리고 깔렸다. 당신의 시간을 이왕이면 최고의 아이디어에 사용해라.
우린 오래 앉아 있어야 한다. 누가 지식 노동자라고 했는가? 매일 하는 끝없는 타이핑으로 손가락 운동을 하며, 하루 8시간 이상 앉아있으면서 허리, 등, 척추를 동시에 공격받는다. 안타깝게도 몇몇의 분들은 오랜 시간 앉은 자세로 인해 끔찍한 항문 질환까지 겪는다.
당신이 위대한 코드를 쓰는 전지전능한 풀스택 개발자여도, 몸이 이러면 코드를 쓸 수 없다.
다음의 규칙을 진리처럼 받아들이고, 모니터 옆에 붙여두자.
- 1시간 이상 앉아있었나? 잠깐만 일어나자.
- 무시하고 앉아있었나? 잠깐만 몸을 풀어주자.
- 하루종일 일만했나? 제발 몸을 풀고, 당신을 사랑해주자.
규칙적으로 스트레칭해야한다. 적극적으로 몸을 풀어주지 않으면 점점 굳어지는 근육과 처지는 뱃살만 보게 된다. 너무 오래 앉아있으면 안됀다. 당신의 항문과, 당신의 허리, 당신의 등, 당신의 눈, 기타 많은 신체 기관들은 생각보다 강하지 않다.
프로그래밍은 오래 앉아있는 대결이 아니다. 서서봐도 되고, 서서 노트에 적어보는 것도 좋다. 서서 생각해도 된다. 서서 검색해도 된다. 몸을 쭉쭉 펴주고, 눈을 잠깐 감아주는건 죄가 아니다. 물론 상사가 먹잇감을 찾아 게으름뱅이를 찾아다닐 땐 최대한 공격적으로 키보드를 두드리며, 한 마리 치타가 된것처럼 모니터를 보자. 그때가 아니라면 당신은 충분히 당신을 사랑해주어야 한다.