반응형
『Clean Code(클린 코드) 애자일 소프트웨어 장인 정신 - 로버트 C. 마틴』 을 읽고 요약한 내용입니다.
뚜껑을 열었을 때 독자들이 코드가 깔끔하고, 일관적이며, 꼼꼼하다고 감탄하면 좋겠다. 질서 정연하다고 탄복하면 좋겠다. 전문가가 짰다는 인상을 심어주면 좋겠다. 그 대신에 숭 취한 뱃 사람 한 무리가 짜놓은 듯 어수선해 보인다면 독자들는 프로젝트의 다른 축면도 똑같이 무성의한 태도로 처리했으리라 생각할 것이다.
- 형식을 맞추는 목적
- 코드 형식은 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무다.
- 적정한 행 길이를 유지하라
- 반드시 지킬 엄격한 규칙은 아니지만 바람직한 규칙으로 삼으면 좋겠다. 일반적으로 큰 파일보다 작은 파일이 이해하기쉽다.
- 신문 기사처럼 작성하라
- 소스 파일도 신문기사와 비슷하게 작성한다. 이름은 간단하면서도 설명이 가능하게 짓는다. 이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단할 정도로 신경써서 짓는다. 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다. 아래로 내려갈수록 의도를 세세하게 묘사한다. 마지막에는 가장 저차원 함수와 세부내역이 나온다.
- 개념은 빈 행으로 분리하라
- 거의 모든 코드는 왼쪽에서 오른쪽으로 그리고 위에서 아래로 읽힌다. 각 행은 수식이나 절을 나타내고, 일련의 행 묶음은 완결된 생각 하나를 표현한다. 생각사이는 빈 행을 넣어 분리해야 마땅하다.
- 세로 밀집도
- 줄바꿈이 개념을 분리한다면 세로 밀집도는 연관성을 의미한다. 즉, 서로 밀접한 코드 행은 세로오 가까이 놓여야 한다는 뜻이다.
- 수직 거리
- 서로 밀접한 개념은 세로로 가까이 둬야 한다. 물론 두 개념이 서로 다른 파일에 속한다면 고칙이 통하지 않는다. 하지만타당한 근거가 없다면 서로 밀접한 개념은 한 파일에 속해야 마땅하다. 이게 바로 protected 변수를 피해야 하는 이유중 하나이다.
- 연관성이 깊은 두 개념이 멀리 떨어져 있으면 코드를 읽는 사람이 소스 파일과 클래스를 여기저기 뒤지게 된다.
- 변수선언
- 변수는 사용하는 위치에 최대한 가까이 선언한다.
- 인스턴스 변수
- 인스턴스 변수는 클래스의 맨 처음에 선언한다.
- 종속 함수
- 한 함수가 다른 함후를 호출하나면 두 함수는 세로로 가까이 배치한다.
- 개념적 유사성
- 어떤 코드는 서로 끌어당긴다. 개념적인 친화도가 높기 때문이다. 친화도가 높을수록 코드를 가까이 배치한다.
- 세로 순서
- 일반적으로 함수 호출 종속성은 아래 방향으로 유지한다. 다시 말해, 호출되는 함수를 호출하는 함수보다 나중에 배치한다. 그러면 소스 코드 모듈이 고차원에서 저차원으로 자연스럽게 내려간다.
- 신문 기사와 마찬가지로 가장 중요한 개념을 가장 먼저 표현한다.
- 가로 형식 맞추기
- 가로 공백과 밀집도
- 가로로는 공백을 사용해 밀접한 개념과 느슨한 개념을 표현한다.
- 가로 정렬
- 선언문과 할당문을 별도로 정렬하지 말자. 정렬하지 않으면 오히려 중대한 결함을 찾기 쉽다.
- 들여쓰기
- 소스 파일은 윤곽도 outline와 계층이 비슷하다. 파일 전체에 적용되는 정보가 있고, 파일 내 개별 클래스에 적용되는 정보가 있고, 클래스 내 각 메서드에 적용되는 정보가 있고, 블록 내 블록에 재귀적으로 적용되는 정보가 있다. 계층에서 각수준은 이름을 선언하는 범위이자 선언문과 실행문을 해석하는 범위다.
- 이렇듯 범위 scope 로 이뤄진 계층을 표현하기위해 우리는 코드를 들여쓴다. 들여쓰는 정도는 계층에서 코드가 자리잡은 수준에 비례한다.
- 들여쓰기 무시하기
- 때로는 들여쓰기를 무시하고 싶은 유혹이 따르더라도 무시하지 말도록하자.
- 가짜 범위
- 때로는 빈 while 문이나 for문을 접하는데 피하는 것이 좋지만 불가피할때는 빈 블록을 올바로 들여쓰고 괄호로 감싸도록 하자
- 팀 규칙
- 팀은 한 가지 규칙에 합의해야 한다. 그래야 소프트웨어가 일관적인 스타일을 보인다.
- 좋은 소프트웨어 시스템은 읽기 쉬운 문서로 이뤄진다는 사실을 기억하자. 스타일은 일관적이고 매끄러워야한다. 한 소스 파일에서 봤던 형식이 다른 소스 파일에도 쓰이리라는 신뢰감을 독자에게 줘야 한다. 온갖 스타일을 뒤섞어 소스 코드를 필요 이상으로 복잡하게 만드는 실수는 반드시 피한다
맨 처음 실무에 투입되었을때가 생각났다. 일본이었기 때문에 手順書(일종의 설명서)를 받아서 그대로 개발환경을 구축해야했다. 그중 하나가 IDE에 코드 스타일을 지정하는 것이었다. 사내 파일서버에서 내가 배정받은 프로젝트의 코드스타일 파일을 다운받아 설정해야했다. 솔직히말하면 좀 부끄럽지만 그 당시에는 왜 코드 스타일마저 지정해줘야하는지 이해를 못했던것 같다. 지금이야 당연하지만 그때 당시에는 실무에대해 하나도 몰랐기에 그랬다고 생각한다.
그때 이후로 몇개의 프로젝트를 거치며 코드스타일을 지정안하는 프로젝트도 경험해보니 규모가 큰 프로젝트는 지정하는게 편할 수 있다는 생각을 하게됐었다. 작은 프로젝트라도 사람마다 작성하는 스타일이 다르니 미리 규율을 정하고 통일하는 과정은 꼭 필요하다.
반응형