7 분 소요

시스템을 운영하다보면 자주 기존의 코드를 들여다보게 되는데, 작성한 사람에 따라서 형식이 모두 다르면 가시성도 좋지 않고, 실제로 코드의 흐름을 따라가는게 더 어렵다. 그래서 유지보수 할 때마다 통일된 형식으로 작성을 하려고 하는데, 제일 중요한 것은 처음부터 잘 맞춰서 작성하는 것이다.
몇 가지 원칙만 안다고 해서 깔끔한 코드를 작성할 수 있는 것은 아닌 것 같다. 항상 그 원칙을 기억하려고 하고, 실제로 코드를 작성할 때 적용해야 한다. 두 번째 클린코드를 읽는 것이라 원칙들을 알고 있었지만, 과거 내가 작성한 코드를 보면 여전히 개선해야할 점들이 많이 보인다.


📆TIL(Today I Learned) 날짜

2022.03.28


📑오늘 읽은 범위

5.형식 맞추기


✍🏻책에서 기억하고 싶은 내용

프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다. 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다. 팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다.

적절한 행 길이를 유지하라 : 일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다.

신문 기사처럼 작성하라 : 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다. 아래로 내려갈수록 의도를 세세하게 묘사한다. 마지막에는 가장 저차원 함수와 세부 내역이 나온다.

수직 거리 : 시스템이 무엇을 하는지 이해하고 싶은데, 이 조각 저 조작이 어디에 있는지 찾고 기억하느라 시간과 노력을 소모한다. 서로 밀접한 개념은 세로로 가까이 둬야 한다. (…) 연관성이란 한 개념을 이해하는 데 다른 개념이 중요한 정도다.

변수 선언 : 변수는 사용하는 위치에 최대한 가까이 선언한다.

인스턴스 변수 : 인스턴스 변수는 클래스 맨 처음에 선언한다.

종속 함수 : 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다.

개념적 유사성 : 어떤 코드는 서로 끌어당긴다. 개념적인 친화도가 높기 때문이다. 친화도가 높을수록 코드를 가까이 배치한다.

가로 정렬 : 정렬하지 않으면 오히려 중대한 결함을 찾기 쉽다. 정렬이 필요할 정도로 목록이 길다면 문제는 목록 길이지 정렬 부족이 아니다.

public class FitNesseExpediter implements ResponseSender {
  private    Socket           socket;
  private    InputStream      input;
  private    OutputStream     output;
  protected  long             requestParsingTimeLimit;
}

이렇게 쓸 필요가 없다. 아래와 같이 써도 전혀 상관없다.

public class FitNesseExpediter implements ResponseSender {
  private Socket socket;
  private InputStream input;
  private OutputStream output;
  protected long requestParsingTimeLimit;
}

팀 규칙 : 하지만 팀에 속한다면 자신이 선호해야 할 규칙은 바로 팀 규칙이다.


❓궁금한 내용, 잘 이해되지 않는 내용

  • ‘소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다.’, ‘서로 밀접한 개념은 세로로 가까이 둬야 한다.’ 두 개념이 상충될 때가 있다. 소스의 첫 부분은 고차원적인 내용작성하는데, 그와 관련된 세부적인 기능들을 가까이 둔다고 밀접하게 두면 고차원 → 저차원 순으로 진행하는 흐름이 깨진다. 이럴 때는 어떻게 해야 하는가?

댓글남기기