Clean Code .Part5

이번장의 제목은 형식 맞추기로 협력에 관한 제목인 것이 느껴진다. 

 

프로젝트에 대한 코드를 열었을 때 코드가 깔끔하고, 일관적이며, 꼼꼼하길 기대한다. 무성의하게 짜 놓은 듯 어수선해 보인다면 우리는 다른 코드도 무성의한 태도로 처리했으리라 생각한다. 

 

이는 틀린 말이 아닌 것 같다. 좋은 코드에 대해 일가견이 있는 사람이 들어와 회사의 코드 형식을 보고 모듈에 대한 코드를 보았을 때 개발 팀에 대한 첫인상이 결정되는 것 같다. 

 

코드 형식을 맞추려는 목적은 의사소통을 위해서다. 오늘 구현한 코드는 다음에 변경될 가능성이 매우 높다. 원래 코드가 사라질지라도 개발자의 스타일과 규율은 사라지지 않는다. 

 

저자는 대형 프로젝트 7개 JUnit, FitNesse, testNG, tam, JDepend, Ant, Tomcat를 조사하여 대략적인 소스 코드의 길이를 통계 내었는데 결과적으로 500줄 미만 200줄 언저리로 평균적으로 구성되었다고 한다. 

이 정도의 분할된 파일들로도 커다란 시스템을 구축할 수 있음을 말한다. 

일반적으로 큰 파일보다는 작은 파일이 이해하기 쉽다.

 

사람의 눈은 왼쪽에서 오른쪽, 위에서 아래로 자연스럽게 흘러간다. 

이러한 코드에서 각 행들은 수식이나 절을 나타내고, 일련의 행 묶음은 하나의 생각을 표현한다. 

생각 사이는 빈 행을 넣어 분리해야 한다고 한다.

 

패키지 선언부, import문 각 함수 사이에는 빈 행이 들어간다. 빈 행은 새로운 개념을 시작한다는 시각 전인 단서로 코드를 읽다 보면 빈 행 바로 다음 줄에 눈길이 멈춘다.

빈 행의 사용은 정말로 가독성을 높여주는 효과가 있다. 

빈 행이 개념을 분리한다면 세로 밀집도는 연관성을 의미한다. 서로 밀접한 코드 행은 세로로 가까이 놓여있어야 한다. 

 

관행적으로 우리는 변수를 선언할 때 사용하는 위치에 최대한 가까이 선언한다. 

대개 지역 변수는 각 함수 맨 처음에 선언하고 루프를 제어하는 변수는 루프 내부, 드물게 블록 상단이나 루프 직전에 변수를 선언하는 경우도 존재한다. 

 

인스턴스 변수는 일반적으로 클래스 맨 처음에 사용한다. C++인 경우 모든 인스턴스 변수를 마지막에 선언하는 scissors rule을 적용한다. 우리는 변수 선언을 어디서 찾을지 모두가 알고 있어야 한다.

 

함수 내부에서 다른 함수를 호출하는 경우 두 함수는 세로로 가까이 배치하여야 한다. 또한 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치한다.

이러한 규칙에 익숙해진다면 방금 호출한 함수가 밑에 존재한다는 사실을 예측할 수 있다.

 

이러한 코드는 개념적으로 유사성이 비슷하다. 이러한 요인들은 여러 가지가 있다. 

함수에서 다른 함수를 호출하는 종속 함수이거나 비슷한 동작을 수행하는 일군의 함수들이 좋은 예시이다.

 

대개 오버로드를 사용해 여러 개의 함수를 정의할 때 인수가 가장 많은 함수 많을 정의하고 다른 오버 로드된 함수들은 인수가 많은 함수를 호출하여 사용한다.  서로가 서로를 호출하는 관계는 부차적인 요인이다.  개념적인 친화도가 높다면 가까이 배치해야 할 함수들인 것이다.

 

들여 쓰기를 통해 우리는 파일의 구조를 한눈에 들어오도록 만든다. 다만 가끔 간단한 if문 while문, 짧은 함수에서 들여 쓰기를 무시하고 싶은 유혹이 생긴다. 여러 행으로 개행하는 것이 아닌 한 줄로 처리하는 게 더 좋아 보이기 때문이다.

public class CommnetWidget extends TextWidget
{
 public static final String REGEXP = "^#...";
 
 public CommnetWidget( ParentWidget parent, String text){super(parent, text);}
 public String render() throws Exceptions {return "";}
    
}

 

다만 저자는 이러한 유혹에 빠질 때마다 원점으로 돌아가 들여 쓰기를 넣는다고 한다.

public class CommnetWidget extends TextWidget{
 public static final String REGEXP = "^#...";
 
 public CommnetWidget( ParentWidget parent, String text){
  super(parent, text);
 }
 
 public String render() throws Exceptions {
  return "";
 }
    
}

 

즉 한 행에 범위를 뭉뚱그린 코드를 피한다. 그리고 들여쓰기로 범위를 제대로 표현한 코드를 선호한다고 한다.

추가적으로 들여쓰기의 기준이 tab키인지 space바가 좋은지는 아직도 의문이다.

 

 

팀 규칙

 프로그래머는 각자 선호하는 규칙이 있다. 하지만 팀에 속한다면 자신이 선호해야 할 규칙은 바로 팀 규칙이다.

팀은 한 가지 규칙에 합의해야 한다. 그리고 모든 팀원은 그 규칙을 따라야 한다.

그래야 소프트웨어가 일관적인 스타일을 보인다. 개개인이 따로따로 맘대로 짜는 코드는 피해야 한다. 

 

저자는 소프트웨어를 구현하기 전 팀원들과 구현 스타일을 논의했다고 한다. 대략 10분 정도

어디에 괄호를 넣을지, 들여 쓰기 기준은 무엇인지, 클래스, 변수의 이름은 어떻게 지을지 

이를 통해 IDE 코드 형식 기를 설정한 후 사용했다고 한다. 저자가 선호하는 규칙은 아니지만 팀이 정한 규칙을 따랐다.

 

 

 

이번 장에서는 형식을 맞추기 위한 노력을 엿보았다. 

가독성에 초점을 두엇고 개인보다 팀을 위한 노력을 하라고 말하였다. 

 

만약에 이상적인 상황이 아니라면 어떻게 해야 할까? 

 

• 가독성이 떨어지는 형식을 팀에서 권한다면?
• 팀과 의사소통을 잘 할 수 없는 상황이라면?
• 정해진 팀 규칙을 지키지 않은 팀원이 존재한다면?
• 이러한 규칙없이 개발하는 팀에 합류한다면 그리고 내가 직위가 낮다면 제안할 수 있을까? 

 

이런 상황에서 최선책은 무엇일까? 

 가독성이라는 개념이 사실 팀의 능력에 따라 기준이 달라지기 때문에 개개인들이 평가하는 가독성이 다를 수 있다. 이는 코드를 통해 before와 after를 통해 다른 팀원들을 설득할 수 있을 수 있다.

 

의사소통이 잘 되지 않는 경우는 프로그래밍 실력의 차이가 존재할 수 있다. 페어 프로그래밍방식을 도입했다면 사수와 부사수를 통해 배우는 자세로 임하겠지만 동등한 입장인 경우에는 어떻게 해야 할까? "양보"

 

규칙이 없으면 자신 주변의 개발자의 형식을 은은하게 따라하는 것도 최선일 것이다. 자신이 제안할 수 있는 위치가 아니라면 말이다.