SmalltalkBestPracticePatterns:7.1

From 흡혈양파의 번역工房
Revision as of 09:24, 29 July 2013 by Onionmixer (talk | contribs) (부호 수정)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
7.1 포맷팅

코드 포맷팅만큼 열기를 생성하지만 빛을 발하지 못하는 주제는 없다. 모두들 자신만의 스타일을 갖고 있으며 다른 스타일을 도입하려는 시도를 했다간 맹렬한 저항에 직면하고 만다. 그럼 필자는 왜 굳이 이런 위험한 일에 손을 대려는 걸까?


첫 번째 이유는 "그것이 존재하기 때문"이다. 꼼꼼하고 예외가 난무하고 감정이 격발하는 주제에 패턴들이 얼마나 잘 적용되는지 확인하기 위해 그러한 패턴들을 한계까지 밀어붙이고 싶다. 이러한 패턴들을 작성하기까진 수개월이 걸렸다. 새롭고 특별한 case가 나타날 때마다 패턴을 수정하거나, 새 패턴을 추가하거나, 기존 패턴에 따라 코드의 포맷팅을 실행했다. 머지않아 패턴을 변경해야 하는 case는 더 이상 찾을 수 없었다. 무엇보다 스몰토크의 모든 포맷팅을 열 개의 패턴으로 정리할 수 있어 기뻤다.


두 번째 이유는 "그것이 중요하기 때문"이다. 이러한 패턴을 따라 코드를 포맷팅할 필요는 굳이 없지만 어떤 일관된 규칙 집합을 따라 포맷팅하게 되면 팀의 상호작용이 원활해진다. 모두가 동일한 방식으로 포맷팅한다면 누군가 코드를 "정리(clean up)"하는 동안 검토와 코드의 전송이 지연되는 일은 절대로 없다. 포맷팅을 올바르게 하면 코드의 구조에 대한 많은 정보를 즉시 전달할 수 있다.


세 번째 이유는 포맷팅에 관한 논의를 발전시키기 위함이다. 규칙을 패턴으로 표시하면 나의 목표와 상충관계를 명시적으로 나타낸다. 다른 스타일이 있다면 이러한 패턴들을 예제로 사용하여 자신만의 규칙을 패턴으로서 묘사할 수 있다. 그리고 나면 각 패턴 집합이 어떤 문제를 해결하고 간과하는지 명시적으로 비교할 수 있게 된다.


이러한 패턴들의 우선순위는 다음과 같다:

  1. 메서드의 전체적인 구조를 한 눈에 봐도 알 수 있게 만들기 위함이다. 특히 복잡한 메시지와 블록은 독자의 눈에 금방 띈다.
  2. 수직 공간을 지키기 위함이다. 브라우저 텍스트 구획에 들어맞는 메서드를 읽는 것과 스크롤을 해야만 하는 메서드를 읽는 것 사이에는 큰 차이가 있다. 메서드를 수직적으로 압축하여 유지하면 작은 브라우저가 가능하면서 스크롤할 필요 없이 메서드를 읽을 수 있게 해준다. 이는 창 관리 오버헤드를 감소시키고 화면에 다른 프로그래밍 도구를 수용할 공간적 여유를 제공한다.
  3. 쉽게 기억하기 위함이다. 포맷팅에 50-100개의 규칙이 있는 스타일 가이드를 본 적이 있다. 포맷팅이 중요하긴 하지만 그 정도의 지력을 가져선 안 된다.


여기 실린 포맷팅 패턴이 오히려 재앙이 되는 스몰토크 코딩 스타일도 많다. 긴 메서드, 또는 복합 표현식을 사용하는 메서드는 이런 방식으로 포맷팅할 경우 모양새가 끔찍하다. 하지만 당신이 컴퓨터가 아닌 독자를 위해 작성하는 속성들을 비롯해 Composed Method(구성 메서드)와 Explaining Temporary Variable(설명하는 임시 변수)을 철저하게 사용하면 포맷팅은 간단하고 읽기 쉬운 코드를 생성하는 데에 일조할 것이다.


Notes