Post

Clean Code ~Ch.5

Posted
clean code text image
clean code text image
By 11 min read

이번 장부터 내가 기억해두고 싶은 내용이지만 생각을 적기에는 조금 애매한 문장들도 적어두려고 한다.

Chapter.5

팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다.

몇 번의 (토이)프로젝트를 진행하고 느낀 점이다. 요즘에는 크게 틀을 벗어난 코드를 작성하는 사람이 많이 없는 것 같다. 내가 나이가 들어가며 주위에 개발에 진심인 사람들이 많이 남아서 그런 것인지, 개발 유튜브나 인강 등 관련 영상 및 부트캠프나 SNS등 정보가 많아져서 그런 것인지는 모르겠다. 하지만 확실한건 요즘은 정말 신기한 모습의 코드를 작성하는 사람이 많이 줄어든 것 같다.

하지만 자기마다의 기준은 있다. 그리고 이 기준은 생각보다 고집하게 된다. 프로젝트를 시작하기 전 사람들끼리 컨벤션을 정한 적이 몇 번 있다.

처음에는 정말 큰 틀만 정했다. 카멜케이스, 폴더 및 파일의 분류 같은 것 말이다. 하지만 그 프로젝트를 진행하면서 이는 틀렸다는 것을 확실히 알았다. 파일마다 정말 다른 모양의 코드를 보며 나는 정말 어지러움을 느꼈다. (지금은 다른 이유로 그룹을 나왔다.) 그 후에 다음부터는 꼭 컨벤션을 세세하게 정해서 진행하리라 마음을 먹었다.


코드 형식은 중요하다!

밥 아저씨도 정말 많이 느끼셨나보다. 책을 읽으며 내가 공감하는 부분이 많이 있을수록 그래도 내가 올바른 길을 가고 있구나를 느낀다. 물론 실력은 아니겠지만…

500줄을 넘지 않고 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다는 사실이다.

가끔 키보드와 물아일체가 돼 코드를 작성할 때가 있다. 이때는 약간 무슨 Zone에 들어간 것 마냥 신들린 듯이 코딩을 이어간다. 문제는 이를 벗어났을 때 뒷수습이다. 아직 실력이 많이 부족해 클린 코드를 짜지 못 할 때가 더 많다. 결국 리팩토링을 해서 코드를 깔끔하게 다듬어야하는데… 내가 이 책을 읽기 시작한 이유?

사람만큼 생각이 유연한 동물도 없지만 사람만큼 생각이 딱딱한 동물도 없다. 리팩토링을 해야하는 경우도 한 번 코드를 작성해두면 기존에 작성해둔 해결법밖에 생각나지 않아서 더 깔끔한 로직으로 수정이나 코드 분리를 하기가 힘들다. 물론 내가 아직 리팩토링 책도 안 읽어보기도 했고 방법 및 기술도 모르고 무엇보다 리팩토링 하는 숙련도가 모자란 것도 있다.

쓰다보니 문장의 주제와 많이 벗어났다. 핵심은 긴 코드를 잘게 나누는 연습을 많이 해야겠다.

결국은 미로 같은 코드 때문에 혼란만 가중된 경험이 있는가?

정말 많이 겪은 일이다. 하늘고래를 만들면서 정말 최선의 노력을 해 클래스를 설계하고 코드를 분리했다. 하지만 여기서 또 한 번 엎어진 이유가 나온다.

클린 코드를 알기 전에 내 나름의 생각대로 코드를 나눴고 결국 규칙도 확실치 않은 채 어지러진 방이 되어버렸다. 나는 미니멀리즘을 꿈꿨는데 낫띵리즘이 되어버렸다. 결국 코드를 다시 엎었고 너무 잘게 나누지 않는 최소한의 기능 선에서 함수를 분리했고 이 편이 나는 조금 더 개발하기 좋았다.

하지만 이 챕터를 읽으며 알았다. 나는 코드를 나누지 못 했다. 이 글을 쓰면서 어떻게 더 나눌 수 있을지 생각이 날 정도로 부족했다. 이 책을 제대로 읽기 전에 앞장만 잠깐 읽고 클린 코드를 적용해본다는 것은 정말 오만한.. 아니 거만한 생각이었다. 아래에도 다시 적겠지만 나는 이 챕터를 읽으며 정말 많은 부족함을 알았고 더욱 이 책을 공부하고 싶은 마음이 들었다.

변수는 사용하는 위치에 최대한 가까이 선언한다. > 잘 알려진 위치에 인스턴스 변수를 모은다는 사실이 중요하다.

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

미로같은 코드와 더불어 한번 더 깨달음을 얻은 문단이다. 전에 코드를 나눴을 때는 기능별로 섹션을 나누고자 했다. 조금 더 자세히 설명하자면 아래와 같이 구분을 했다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

def low_level_1:
  ...

def low_level_2:
  ...

def low_level_3:
  ...

def high_level_1():
  ...

def high_level_2():
  ...

함수의 수준으로 섹션을 나누어 관리했다. 이러다보니 코드를 위에서 아래로 읽지 못 하고 위 아래로 왔다갔다하는 미로같은 코드가 탄생했다.

친화도가 높을수록 코드를 가까이 배치한다. > 개인적으로는 120자 정도로 행 길이를 제한한다.

파이썬 개발자로써 정말 마음에 드는 문장이다. PEP에서 제시된 파이썬 글자 제한은 너무 짧다…! 79자라니! 진짜 적어도 120자는 되어야한다고 생각한다.

여담으로 왜 79자인지도 알게 됐다. 천공카드에서 유래했다.

코드 형식을 자동으로 맞춰주는 도구는 대다수가 연산자 우선순위를 고려하지 못하므로, 수식에 똑같은 간격을 적용한다. 따라서 위와 같이 공백을 넣어줘도 나중에 도구에서 없애는 경우가 흔하다.

이 챕터를 읽으며 웬만한 컨벤션은 잘 지키고 있다고 생각했지만 연산자를 공백으로 우선순위를 구분하는 것은 좋은 방법인 것 같다. 기존에는 괄호를 이용해 구분을 했는데 괄호와 같이 사용하면 더욱 효과적으로 구분할 수 있을 것 같다.

아래 코드처럼 선언부가 길다면 클래스를 쪼개야 한다는 의미다.

한번 더더 깨달은 문단이다… 내 코드는 꽤 인스턴스 변수가 많았고 결국 이는 클래스를 분리해서 나눌 수 있음을 의미하는 것 같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public class FitNessExpediter implements ResponseSender
{
  private Socket socket;
  private InputStream input;
  private OutputStream output;
  private Request request;
  private Response response;
  private FitNessContext context;
  protected long requestParsingTimeLimit;
  private long requestProgress;
  private long requestParsingDeadline;
  private boolean hasError;

  public FitNessExpediter(Socket s, FitNessContext context) throws Exception
  {
    this.context = context;
    socket = s;
    input = s.getInputStream();
    output = s.getOutputStream();
    requestParsingTimeLimit = 10000;
  }
}

전반적으로 이 챕터를 가장 재밌게 읽었다. 사실 매 챕터가 진행될수록 더욱 몰입하게 되는 것 같다. 그리고 끝까지 완료해본 내 개인프로젝트가 몇 개 있어서 거기서 얻은 경험이 정말 이 책을 읽을 때 공감하면서 읽게 되는 것 같다.

얼른 일정이 조금 정리되고 자리잡히면 하늘고래를 더욱 손 봐주고 싶다(?)

Book, Clean Code
clean_code java
This post is licensed under CC BY 4.0 by the author.

Trending Tags

java clean_code spring