클린코드 스터디 회고 - 001

3 분 소요

클린코드 리뷰 - 001

21년 11월 3일부터 22년 1월 19일까지 클린코드 북스터디를 진행하였다.

4명의 동료들과 서로 의지하며 마무리한 정말 값진 경험이었다.

클린코드는 소프트웨어 설계원칙, TDD 등을 다시금 상기시켜주는 고마운 책이다.

나는 클린코드를 타인이 이해하기 쉬운 코드 라고 한마디로 정의해본다.

나쁜 코드와 깨끗한 코드

나쁜 코드로 인해 치르는 대가는 엄청나다.

시간이 갈수록 개발속도를 떨어뜨리고 코드를 유지하기 어렵게 만든다.

이런 경우 보통 생산성을 복원하기 위해 새로운 프로젝트를 만들어 새로운 설계에서 시작하려고 한다.

하지만 새 프로젝트에 투입된 인력들은 의욕은 넘치지만 경험이 많지않고, 그러다보니 일정을 맞추기 위해서 설계에 반하는 또다른 나쁜 코드로 만들어지게 된다.

따라서 생산성을 유지하는 방법은 늘 최대한 깨끗한 코드를 유지하는 습관이다.

깨끗한 코드는 읽기 쉬운 코드이다. 코드를 읽는 시간이 코드를 짜는 시간에 비해 10배나 많기 때문이다.

체크아웃할 때보다 조금 더 깨끗한 코드를 체크인하도록 노력해야 할 것이다.

이름을 어떻게 지을까?

함수, 변수는 항상 의도가 명확한 이름으로 지어져야 한다.

왜냐면 그래야 변수가 어떻게 생성되는지 찾지 않고도 변수의 값을 유추할 수 있으며, 함수의 내용을 읽어보는 노력 없이도 함수의 결과를 유추해볼 수 있기 때문이다.

일반적으로 클래스, 변수명은 명사구, 메서드명에는 동사구가 적합하다.

업무 도메인이나 맥락을 충분히 고려하여 이름을 짓는 것이 좋다.

함수는 어떻게 만들면 좋을까?

함수는 최대한 간결하게 만들어야 한다.

딱 한가지만 하는 함수가 좋다.

프로그램은 하위 함수들의 모음이라고 생각한다면 프로그램을 실행하면서 호출되는 모든 함수들이 완료되면 프로그램의 목적이 달성될 것이다.

그 함수들은 또 하위의 모든 함수들이 완료되면 목적이 달성될 것이다.

이렇게 함수를 만들 때는 큰 개념을 세분화해가면서 추상화의 단계를 고려해가며 만드는 것이 좋다.

함수 또한 이름이 중요하고 충분히 고민하여 서술적인 이름을 사용해야 한다.

함수의 인자(파라미터)가 적을수록 클린코드에 가깝다.

인자가 많아지면 읽는 사람은 그것의 의미를 해석하기가 어려워진다.

조회성 함수와 명령성 함수를 분리하는 것은 좋은 기준이다.

함수 수행중 오류가 발생하면 오류코드를 리턴하는 것은 호출하는 함수에 오류처리에 대한 부담을 준다.

차라리 try/catch 로 받게 한다음 오류처리를 위한 함수에 위임하는 것이 좋다.

중복된 코드는 리팩터링을 통해 제거해라.

좋은 함수를 만드는 방법

  1. 처음에는 일단 길고 복잡하게 만들어라
  2. 그리고 단위 테스트 케이스를 만들어라
  3. 단위 테스트 케이스를 통과시키면서 함수를 정제해라

소스코드에 주석은 어찌하나?

왠만하면 달지마라.

그냥 소스코드에 주석으로 달고싶은 내용을 녹여내라.

법적인 주석, 의도를 설명하는 주석, TODO 주석은 사용해도 괜찮다.

소스코드의 형식

읽기 좋은 클린코드를 위해서는 코드형식이 잘맞아야 한다. 그래야 의사소통이 편하다.

요즘은 lint 에 의해 강제되기도 한다.

소스는 고차원에서 저차원으로 내려가면서 짜여져야 한다.

개념적으로 비슷한 코드는 가깝게 배치하라.

표같은 정렬은 하지말고, 자연스럽게 좌측부터 써라.

들여쓰기, 중괄호 등에 대한 것들은 팀의 규칙을 따르는 편이 좋다.

클래스에 대해

때로는 모르는게 약이다.

클래스는 구현을 감추고 추상화를 통해 인터페이스로 제공하는게 좋다.

추상화를 할 때는 클래스의 자료를 표현할 방법을 고민해봐야 한다.

Square, Rectangle, Geometry 예시를 보면 절차지향적인 프로그래밍은 클래스간의 관계가 모호하게 보인다.

반면 Shape, Square, Reactangle 예시는 각 클래스간의 관계가 명확하게 보인다.

그래서 객체지향적 프로그램이 더 복잡한 환경에 적합할 것으로 보인다.

디미터의 법칙은 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다.

객체는 동작만을 공개하고 데이터는 숨긴다.

자료구조는 자료를 노출한다.

시스템을 구현할 때 새로운 자료 타입을 추가하는 경우를 고려한다면 객체와 객체직향적인 코드가 더 적합하다.

새로운 동작을 추가하는 경우가 있다면 자료 구조와 절차적인 코드가 더 적합할 수 있다.

참고