형식 맞추기
목적
: 무엇보다 먼저 한자기를 분명히 짚고 넘어가자. 코드 형식은 중요하다 ! 너무 중요해서 무시하기 어렵다. 너무나도 중요하므로 융통성 없이 맹목적으로 따르면 안된다. 코드 형식은 의사소통의 일환이다. 의사 소통은 전문 개발자의 일차적인 의무다.
적절한 행 길이를 유지하라
: 소스 코드는 얼마나 길어야 적당할까 ? FitNesse 프로젝트에서 평균 코드의 길이는 65 줄, 전체의 1/3이 40줄에서 100줄 사이이고, 가장 길 코드가 400줄 가장 짧은 키드가 6줄이다.
신문 기사처럼 작성하라
:아주 좋은 신문 기사를 떠올려보라. 독자는 위에서 아래로 가사를 읽는다. 최상단에 기사를 몇 마디로 요약하는 표제가 나온다. 독자는 표제를 보고서 기사를 읽을지 말지 결정한다. 첫 문단은 전체 기사 내용을 요약한다. 세세한 사실은 숨기고 커다란 그림을 보여준다. 쭉 읽으며 내려가면 세세한 사실이 조금씩 드러난다.
소스파일도 비슷하다. 이름은 간단하면서도 설명이 가능하게 짓는다. 이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단할 정도로 신경써서 짓는다. 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다. 아래로 내려갈수록 의도를 세세하게 묘사한다. 마지막에는 가장 저차원함수와 세부 내역이 나온다.
개념은 빈 행으로 분리하라
: 거의 모든 코드는 왼쪽에서 오른쪽으로 그리고 위에서 아래로 읽힌다. 각 행은 수식이나 절을 나타내고 일련의 행 묶음은 완경된 생각 하나를 표현한다. 생각사이는 빈 행을 넣어 분리해야 마땅하다.
세로 밀집도
: 줄바꿈이 개념을 분리한다면 세로 밀집도는 연관성을 의미힌다. 즉, 서로 밀접한 코드 행은 세로로 가까이 놓여야 한다는 뜻이다.
수직 거리
: 함수 연관 관계와 동박 방식을 이해하려고 이 함수에서 저 함수로 오가며 소스파일을 위 아래로 뒤지는 등 뺑뻉이를 돌았으나 결국은 미로 같은 코드 때문에 혼란만 가중된 경럼이 있는가 ? 함수나 변수가 정의된 코드를 찾으려 상속 관계를 중중이 거슬러 올라간 경럼이 있는가 ? 결코 달갑지 않은 경럽이다. 시스템이 무엇을 하는지 이해하고 싶은데, 이 조각 저 조각이 어디에 있는지 찾고 기억하느라 시간과 노력을 소모한다.
-
변수 선언
: 변수는 사용하는 위치에 최대한 가까이 선언한다. 우리가 만든 함수는 매우 짧으므로 지역 변수는 각 함수 맨 처음에 선언한다. -
인스텀스 변수
: 반면 인스턴스 변수는 클래스 맨 처음에 선언한다. 변수 간에 세로로 거리를 두지 않는다. 잘 설계한 클래스는 클래스의 많은 메서드가 인스턴스 변수를 사용하기 때문이다.
인스턴스 변수를 선언하는 위치는 아직도 논쟁이 분분하다. 일반적으로 C++에서는 모든 인스턴스 변수를 클래스 마지막에 선언한다는 소위 가위 규칙을 적용한다. 하지만 자바에서는 보통 클래스 맨 처음에 인스턴스 변수를 보은다는 사실이 중요하낟. 변수를 어디서 찾을지 모두가 알고 있어야한다. -
종속 함수
: 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다. 또한 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치한다. -
개념적 유사성
: 어떤 코드는 서로를 끌어당긴다. 개념적인 친화도가 높기 때문이다. 친화도가 높을수록 코드를 가까이 배치한다. 친화도가 높은 요인은 여러가지이다. 앞서 보았듯이, 한 함수가 다른 함수를 호출해 생기는 직접적인 종속성이 한 예이다. 또한 변수와 그 변수를 사용하는 함수도 예이고, 하지만 그 외에도 친화도를 높이는 요인이 있다. 비슷한 동작을 수행하는 일군의 함구사 좋은 예다.
가로 형식 맞추기
: 한 행은 가로로 얼마나 길어야 적당할까 ? 이 질문에 답하려면 먼저 일반적인 프로그램에서 행 길이를 살펴보자. 앞서와 마찬가지로, 여기서도 프로젝트 7개를 조사했다. 결과는 놀랍도록 규칙적이다. 특히 45자 근처가 그렇다. 20자에서 60자 사이는 모든 값이 총 행수으 ㅣ1% 정도다. 그러니까 20자에서 60자 사이인 행이 총 생 수의 40%에 달한다는 말이다. 10자 미만은 30% 정도로 보인다.
팀 규칙
: 팀 규칙이라는 제목은 말 자난이다. 프로그래머라면 각자 선호하는 규칙이 있다. 하지만 팀에 속한다면 자신이 선호해야 할 규칙은 바로 팀 규칙이다. 팀은 한가지 규칙에 합의해야한다. 그리고 모든 팀원은 그 규칙을 따라야한다.
객체와 자료구조
자료/객체 비대칭
: 객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다. 자료 구조는 자료를 그래로 공개하며 별다른 함수는 제공하지 않는다. 문단을 처음부터 다시 읽어보길 바란다.
디미터 법칙
: 디미터 법칙은 잘 알려진 휴리스틱으로 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다. 객체는 자료를 숨기고 함수를 공개한다. 즉 객체는 조회 함수로 내구 구조를 공개하면 안된다는 의미다. 그러면 내부 구조를 노출하는 셈이니까
잡종 구조
: 이런 혼란으로 말이암아 때떄로 절반은 객체, 절반은 자료 구조인 잡종 구조가 나온다. 잡종 구조는 중요한 기능을 수행하는 함수동 있고, 공개 변수나 공개 조회/설정 함수도 있다. 공개 조회/설정 함수는 비공개 변수를 그대로 노출한다. 덕택에 다른 함수가 절차적인 프로그래밍의 자료 구조 접근 방식 처럼 비공개 변수를 사용하고픈 유혹에 빠지기 십상이다.
자료 전달 객체
: 자료 구조체의 전형적인 형태는 공개 변수만 있고 함수가 없는 클래스다. 이런 자료 구조체를 떄로는 자료 전달 객체(DTO)라 한다. DTO 는 굉장히 유용한 구조체다. 특히 데이터베이스 와 통신하거나 소켓에서 받은 메시지의 구문을 분석할 떄 유용하다.
결론
: 객체는 동작을 공개하고 자료를 숨긴다. 그래서 기존 동작을 변경하지 않으면서 새 객체 타입을 추가하기 쉬운 반면, 기존 객체에 새 동작을 추가하기는 어렵다. 자료 구조는 별다른 동작 없이 자료를 노출한다. 그래서 기존 자료 구조에 새 동작을 추가하기는 쉬우나, 기존 함수에 새 자료 구조를 추가하기는 어렵다. 시스템을 구현할 때, 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합하다. 다른 경우로 새로운 동작을 추가하는 유연성이 필요하면 자료 구조와 절차적인 코드가 더 적합하다. 우수한 소프트웨어 개발자는 편견없이 이 사실을 이해해 직면한 문제에 최적인 해결책을 선택한다.
