신입사원일 때 한 선배에게 빌드할 때 Warning 메시지가 많이 뜨는데 고쳐야 되지 않냐고 물은 적이 있다. 돌아온 대답은 그럼 네가 한 번 고쳐봐라는 말이었다. 문맥상으로는 본인은 다른 일도 많고 동작하는 데에 별 문제도 없으니 시간이 많은 신입 너가 한 번 고쳐봐란 뜻이었다. 그런데 그는 과연 컴파일러가 친절히 시간을 들여가며 화면에 뱉어 준 경고를 무시할 정도로 바빴는지, 과연 그 경고 메시지들은 무시할 정도로 사소했는 지는 지금까지도 의문이다.

  당신이 훌륭한 SW엔지니어가 되고 싶다면 "청소하는 습관"을 몸에 익혀라. 여기서 말하는 청소는 단순히 책상 위를 깨끗이 정돈하고 먼지를 닦아내라는 뜻이 아니다. 실력 있는 개발자도 책상 위가 지저분한 사람들이 많다. 어제 야근 중에 먹고 반쯤 남겨놓은 커피는 1회용 종이컵에 그대로 담겨 있고 테스트 장비들은 배배 꼬여 있는 전선과 함께 여기저기 널브러져 있다. 구석에는 먼지가 뭉쳐서 굴러다니는데 당사자는 걸레질은 언제 했는지 기억도 하질 못한다. 사실 책상의 청결도와 업무능력 간의 상관관계는 크지 않다. 위에서 언급한 엉망인 책상의 소유자가 업무에는 뛰어는 역량을 발휘하는 것을 많이 보았다. 그렇다고 책상 위를 일부러 지저분하게 하란 소리가 아니다. 마치 책상 위가 어지러운 게 일하는 것처럼 보인다고 여기는 사람들이 있는데 절대 멋있어 보이지 않는다. 집중력만 흐트러뜨릴 뿐이다. 그리고 주위 사람에게 자신의 역량을 보여주기 전에 선입견만 심어 준다. "저 녀석은 자기 책상처럼 평소 업무처리도 깔끔하지 않을 거야."

  주변을 깨끗이 정리한다고 모두 개발의 고수는 아니지만, 고수들은 모두 주위는 지저분하더라도 [각주:1]코드베이스는 깔끔하게 유지한다. 혼자서 진행하는 프로젝트라면, 아니 혼자서 진행하는 프로젝트라도 다음과 같은 짓은 하지 마라. 너무 당연한 내용을 이야기 하는 게 남우세스러울 정도다. 하지만 당연한 것을 당연하다는 듯이 실천하지 않는 사람이 많으니 이제 개발자로서 새 출발하는 당신은 마음에 깊이 새기고 실천해라. 상대방에 대한 '배려'가 조금이라도 있다면 지켜질 것들이다.

- 들여쓰기를 들쑥날쑥하게 해서 가독성을 떨어뜨리지 마라.
- 선언만 해 두고 쓰지 않는 변수, import(또는 include)가 있다면 바로 지워라.
- 나중에 사용할 지도 모른다고 넣어둔 테스트 코드는 당신의 노트에만 기록해라. 코드베이스는 메모장이 아니다.
- 마찬가지로 주석으로 막혀 있는 사용하지도 않는 코드 블록 역시 즉시 삭제해라.
- 사내 코딩 표준안을 지켜라. 지키기 어려우면 Editor의 formatter기능을 설정해서 편집할 때 자동으로 맞춰지게 하라.
- 중복코드는 만들지 마라. 중복코드를 만나면 그 자리에서 고쳐라.
- 코드는 1번 쓰고 100번 읽는다는 것을 명심해라. 지저분한 코드는 다시 읽을 때 방해만 될 뿐이다.

  가끔 위에서 언급한 지저분한 코드를 코드베이스에 머지하는 몰상식한 개발다들과 함께 일할 때가 있다. 코딩을 하면서 위의 것들을 지키지 않는 것은 마치 바둑의 기본도 배우지 않고 묘수풀이를 하는 것과 다르지 않다. 선과 선이 만나는 교차점에 착수를 해야지 돌 위에 돌을 놓는 격이다. 걸음마를 배우기 전에 육상 선수를 흉내 내는 사람이다. 기본 박자도 배우기 전에 스틱 돌리기만 연습하는 초보 드러머와 같다.

  지금 당장 사내에 정해진 Coding Rule(또는 Coding convention)이 존재하는 지 알아보라. 만약 있다면 자신의 코딩 스타일을 거기에 맞게 바꿔야 한다. 준비된 문서가 없다면 일반적으로 업계에서 통용되는 것을 찾아 익히도록 해라.[각주:2] 이 기회에 팀원들과 함께 만들고 공유하는 것도 좋다. 

  코드베이스를 더럽히지 않는 것도 중요하지만 만약 누군가 똥을 싸 놓았다면[각주:3] 보는 즉시 치워라. 한 개의 깨진 유리창이 건물 전체를 망가뜨린다는 것을 항상 기억해라.
  오랜 기간 수리하지 않고 방치된 창문 하나가 거주자들에게 버려진 느낌을 스며들게 한다. 당국자들이 그 건물에 별 관심이 없다는 느낌말이다. 그래서 다른 창문이 하나 더 깨진다. 사람들은 이제 어지르기 시작한다. 낙서(Graffiti)가 등장한다. 심각한 구조적 손상이 시작된다. 꽤 짧은 시간 안에 소유주가 그걸 고치려는 의지를 넘어설 정도로 건물이 손상되고, 결국 버려진 느낌은 현실이 되어 버린다. 
  '깨진 창문 이론'은 뉴욕과 다른 주요 도시 경찰들에게, 큰일을 막기 위해 조그만 것들을 엄중 단속해야겠다는 영감을 불어넣어 줬다. 정말 그렇게 된다. 깨진 창문, 낙서, 기타 작은 위반 행위를 잘 단속했더니 중범죄가 줄었다. 
  '깨진 창문'(나쁜 설계, 잘못된 결정, 혹은 형편없는 코드)을 고치지 않은 채로 내버려 두지 마라. 발견하자마자 바로 고쳐라. 적절히 고칠 시간이 충분치 않다면 판자로 덮는 것만이라도 하라. 불쾌한 코드를 주석처리 하거나, '아직 구현되지 않았음(Not Implemented)'이라는 메시지를 표시하거나, 가짜(dummy)데이터로 대치해 놓거나 하라. 더 이상의 손상을 예방하기 위해 어떤 조치든 취하고 현 상황을 잘 관리하고 있다는 것을 보여줘라
  깨끗하고 잘 기능하는 시스템들이 일단 창문이 깨지지 시작하면 급속도로 악화되는 것을 많이 보아 왔다. 소프트웨어의 부패에는 다른 요인들도 있지만 방치는 다른 어떤 요인보다도 부패를 더 가속시킨다.

- 실용주의 프로그래머, 앤드류 헌트, 데이비드 토머스, 인사이트, 35쪽

  도요타가 급성장했을 때 그 생산방식과 경영철학에 대한 연구가 활발히 이루어졌고 이를 SW에 접목시킨 사례[각주:4]도 있었다. 도요타의 5S 정신 중 "청소(Seiso)"는 자동차 업계에만 통용되는 게 아니다.


  1. 공용으로 관리하는 SW 소스코드. 매일 작성한 코드를 코드베이스에 머지해서 공유한다. (참조) http://en.wikipedia.org/wiki/Codebase [본문으로]
  2. 예를 들어 Java 클래스 이름은 대문자로 시작하고, 메소드 이름은 소문자로 시작하지만 단어마다 대문자로 붙여서 지어야 한다. [본문으로]
  3. 다른 사람이 만든 버그를 수정해야 하거나, 안해도 될 일을 해야 할 때 "똥을 치운다"라고 한다. [본문으로]
  4. 린 소프트웨어 개발의 적용. 메리 & 톰 포펜딕. 위키북스 [본문으로]
저작자 표시 비영리 변경 금지
신고