SmalltalkBestPracticePatterns:1.5

1.5 스타일

스타일

훌륭한 프로그래밍 스타일은 누구나 보면 알지만 정확히 말로 설명하기가 힘든 사항들 중 하나이다. 자본주의의 위선은-훌륭한 프로그래밍 스타일이 돈을 부른다ㅡ객관적으로 측정이 가능하지만 매일 적용하긴 힘들다.

프로젝트의 상태가 괜찮은지 확인하는 예측인자로 바람직한 것이 몇 가지 있다. 필자는 코드에 이러한 속성들을 포함시키려 노력한다.

• 꼭 한 번만 - 훌륭한 스타일을 1분 안에 설명해야 한다면, 필자는 다음의 간단한 규칙으로 일축하겠다: 훌륭한 스타일로 작성한 프로그램에선 모든 것이 한 번만 작성되어 있다. 이 규칙이 훌륭한 코드를 생성하는 데 큰 도움은 안 되겠지만 끝내주게 훌륭한 분석 도구인 것만은 확실하다. 다수의 메소드가 동일한 로직으로 된 경우, 다수의 객체가 동일한 메소드로 된 경우, 또는 다수의 시스템이 유사한 객체로 이루어진 경우엔 이 규칙으로 만족할 수 없음을 알고 있다. 따라서 두 번째 속성으로 이어진다:
• 매우 많은 작은 조각들 - 훌륭한 코드는 예외 없이 작은 메소드들과 작은 객체들을 포함한다. 시스템을 매우 작은 함수(function)와 상태 조각들로 팩토링(factoring) 할 때만 "꼭 한 번만" 규칙의 충족을 기대할 수 있다. 이 항목에서 개발자들, 특히 숙련된 개발자들의 반발이 거셀지는 모르지만 시스템을 작은 조각으로 나누는 것만큼 시스템에 도움이 되는 작업은 없다. 하지만 이러한 작업을 할 때는 항시 전체적인 그림을 효과적으로 전달하는지 확신해야 한다. 그렇지 않으면 모든 조각이 "Fettucine a la C" 만큼 형편없는 "Pasta a la Smalltalk" 음식이 되어버린다.
• 객체 대체하기 – 훌륭한 스타일은 쉽게 대체가 가능한 객체로 이어진다. 정말로 훌륭한 시스템은, 사용자가 “이걸 완전히 다른 방식으로 해보고 싶어요,”라고 말할 때마다 개발자가 “그럼 새로운 유형의 X를 만들어 플러그인하기만 하면 됩니다,”라고 말할 수 있는 시스템일 것이다. 기존의 객체를 수정할 필요 없이 새로운 객체만 추가함으로써 시스템을 확장할 수 있다면 유연하고 관리하기 수월한 시스템을 가진 것이다. 이는 수많은 작은 조각으로 구성되지 않으면 불가능하다.
• 객체 이동하기 – 훌륭한 스타일로 된 시스템의 또 다른 속성은 객체를 다른 컨텍스트로 쉽게 이동할 수 있다는 점이다. "이 시스템에서 이 객체는 저 시스템에서도 동일한 작업을 수행한다,"고 말할 수 있어야 한다. 경고-객체를 처음 이동시킬 경우 일반화가 잘 되지 않아 이상이 있음을 발견할 것이다. 이 단계에서 객체를 너무 일찍이 이동시키지 말라. 몇 가지 시스템을 먼저 구입해(ship)보라. 그리고 작은 다수의 조각들로 빌드된 시스템이 있다면 꽤 수월하게 필요한 수정과 일반화를 완료할 수 있을 것이다.
• 변화율 – 필자가 항시 사용하는 간단한 기준으로 변화율 확인이 있다. 필자는 Brad Cox가 오래 전에 한 말을 바탕으로 이 기준을 학습하게 되었다. 이후에 다음과 같이 일반화시켰다ㅡ두 가지 변화율을 합하지 말라. 서브클래스마다 변하는 메소드의 일부를 그렇지 않은 메소드와 합하지 말라. 값이 매 초마다 변하는 인스턴스 변수를 값이 한 달에 한 번씩 변하는 인스턴스 변수와 같은 객체에 넣지 말라. 요소가 매 초마다 추가, 제거되는 집합체(collection)에 한 달에 한 번씩 요소가 추가, 제거되는 요소를 넣지 말라. 하드웨어의 모든 조각을 변경해야 하는 객체의 코드와 운영체제마다 변경해야 하는 코드는 함께 두지 말라. 위와 같은 문제는 어떻게 피할 수 있을까? 그렇다. 작고 많은 조각! 그것이 답이다.