"남들 읽기 좋게 짜라" 그 한마디에 시작된 나의 클린 코드

나는 5년간 중소기업에서 선배 없이 개발을 해왔다.

내 유일한 윗사람이었던 팀장은 개발과 관련된 이야기를 나랑 나눈 적이 거의 없다.

내가 기억하는 개발과 관련된 조언은 딱 두 가지였다.

 

1. 잘되는 코드를 함부로 건드리지 마라

2. 남들이 읽기 좋게 코드를 써라

 

이 두 가지는 내가 회사생활을 하는 동안 지키기 위해 노력했고, 구체적인 실천방안을 마련하기 위해 많이 노력했었다.

내 후임으로 들어왔던 동료들에게도 강조했던 내용이기도 하고...

물론 잘되는 코드를 함부로 건드리지 말라는 좀 다시 생각해 봐야겠지만, 남들이 읽기 좋게 코드를 쓰라는 것은 정말 중요한 것 같다.

 

커밋메시지를 대충 쓰거나 코드 분석을 제대로 안 하고 중복되는 변수나 함수들을 만들어 쓰는 것은 이해를 하고 넘어갔다.

이런 부분은 내가 리팩터링 하거나 같이 코드리뷰를 하는 동안 찾아서 수정할 수 있었으니까.

 

그런데 코드리뷰를 하거나 리팩토링을 포기하게 만드는 코드들에 대해서는 상당히 많은 지적을 했었다.

반복되는 코드를 하드코딩한다든지, 이해가 되지 않는 변수명이나 함수명을 사용한다든지...

이런 부분들이 있을 때, 코드리뷰를 하다가 꽤 스트레스를 많이 받았던 것 같다.

 

당시 다른 팀의 책임님이 추천해 주셨던 Clean Code를 읽고, 많은 도움을 받았던 것이 생각난다.

이후, 나는 아래의 원칙들 정도는 지켜가기 위해 노력했던 것 같다.

---

1. 이해하기 어려운 변수명, 함수명

String please = "abcde";
if(checkStr.equals(please)) {
	...
}

 

내가 회사에 다닐 때도, 프리랜서를 하는 지금도... 가끔 보이는 위와 같은 코드...

이해는 하는데... 그래도 변수나 함수명은 이해할 수 있게 지어야 한다.

나도 제발 되길 바라는 마음에 테스트 변수명이나 함수명을 짓기도 했었지만, 나중에 그 코드를 다시 보면 제발 소리가 나온다.

왜 이렇게 코드를 작성했는지도 이해가 안 가는데, 변수명까지 저 모양이면 답도 안 나온다.

 

 

2. 지나친 하드코딩

List<String> list = new LinkedList<>();
list.add(String.valueOf(0));
list.add(String.valueOf(1));
list.add(String.valueOf(2));
list.add(String.valueOf(3));
list.add(String.valueOf(4));
list.add(String.valueOf(5));
list.add(String.valueOf(6));
list.add(String.valueOf(7));

return list;

 

for문만 써도 짧게 줄일 수 있는 코드를 위와 같이 하나하나 삽입하는 코드들도 상당히 많이 눈에 띈다.

특히 웹에서 메뉴를 넣을 때나 select/option, table에 값을 넣을 때 등등...

가끔 하드코딩하는 것이 가독성에 더 좋은 경우도 분명히 있다.

하지만 나는 대부분의 경우 모듈화를 시키고 반복문으로 처리하는 게 더 보기 좋더라...

 

 

3. 여러 가지 역할을 수행하는 함수 - 함수 분리

@GetMapping("/{id}")
public ResponseEntity<?> getList(@PathVariable(name="id") String id) {
    // id 값 체크
    ...
    // 사용자 권한 체크
    ...
    // 사용자별 서비스 분기
    ...
    // 응답값 생성
    ...
    return ResponseEntity.ok(list);
}

 

개발을 하다 보면 단일 책임 원칙을 지키는 것은 쉽지 않다.

운영 중에 발생하는 요구사항들을 하나씩 반영하다 보면 조건이 길어지기 마련이고, 그런 경우 함수의 내용이 길어지는 경우가 많다.

하지만 그런 코드를 정리하지 않고 계속 쌓아가다 보면, 위의... 인 부분들이 100줄 이상이 되는 경우도 많아진다.

이런 경우, 파일 숫자가 조금 많아지더라도 각 부분을 다른 클래스나 private 함수로 만들어서 체크하는 것이 좋다고 생각한다.

@GetMapping("/{id}")
public ResponseEntity<?> getList(@PathVariable(name="id") String id) {
    // id 값 체크
    this.nullCheck(id);
    // 사용자 권한 체크, 전담하는 클래스 생성
    UserAuthority userAuthority = AuthorityValidation.check("getList");
    // 사용자별 서비스 분기, 응답값 생성
    List list = ListService.getList(userAuthority, id);
    return ResponseEntity.ok(list);
}

private void nullCheck(String id) {
    if(id == null || id.isEmpty()) throw new RuntimeException("필수 값이 없습니다.);
    ...
}

 

 

 

4. 보기 좋게 코드를 배치하기 

VSCode를 이용해서 개발하는 경우 prettier를 사용하기 때문에 대부분의 경우 가독성 높게 코드가 작성된다.

그런데 java 등 prettier 적용을 안 하고 개발하는 경우, 개발자가 스스로 읽기 좋게 코드를 배치해야 한다.

예전에 myBatis로 개발된 시스템 중, mapper에 있는 sql문을 한 줄로 작성한 코드를 본 적이 있다.

지금 생각해도 무슨 생각으로 그렇게 작성한 건지 궁금하다.

스크롤이 옆으로 끝없이 가는 것을 보면, 유지보수하는 사람들에게 욕먹고 장수하려고 그렇게 작성한 것이라는 생각이 든다.

 

 

---

나는 나름대로 위의 원칙들을 지키기 위해 노력해 왔지만, 가끔 예전에 작성한 코드들을 보면 아쉬운 부분이 많이 눈에 띈다.

지금도 마찬가지일 것이다.

그런 부분들은 팀에서 지적받고 고칠 수 있었으면 참 좋았을 텐데, 그런 게 없었던 것이 지금 아쉬움으로 많이 남는다.

내가 지원하고 싶은 업체들에 입사한 사람들은 같은 기간 동안 훌륭한 리뷰 문화 안에서 자연스레 학습할 수 있었던 부분들이니까...

내가 더 노력하는 수 밖에는 없지만, 이런 부분들이 가장 아쉬운 부분이다.