3장. 함수
작게 만들어라
- 중첩구조가 생길만큼 함수가 커져서는 안된다.
- 그래야 함수를 읽고 이해하기 쉬워진다.
한 가지만 해라!
- 함수는 한 가지를 잘해야 한다.
- 한 가지의 의미는 추상화 수준이 하나라는 의미이다.
- 함수 내에서 의미있는 이름으로 다른 함수를 추출해낼 수 있다면 한가지 일을 하는 것이 아니다.
- 다양한 분기처리를 하는 switch문은 각 분기에 맞는 객체를 생성할 때만 허용한다.
서술적인 이름을 사용하라!
- 이름이 길어도 좋다. 길고 서술적인 이름이 주석보다 좋다.
- 서술적인 이름을 사용하면 설계가 용이해져 코드를 개선하기 쉬워진다.
함수 인수
- 인수의 개수가 늘어날 수록 테스트하기 까다로워진다.
- 이항함수는 단항함수보다 이해하기 어렵다.
- 인수가 2개 이상 필요하다면 일부를 클래스변수로 변환할 가능성이 있는지 체크하라
부수효과를 제공하지 말라
- 함수 이름에 맞는 기능만 제공해라
- 부수효과로 인해 특정 조건에서만 함수를 호출해야 하는 제약조건이 생긴다.
- 만약 부수효과가 필요하다면 이름에 명시하라
오류코드보다 예외를 사용하라
- 오류코드를 사용하면 중첩문이 많아진다.
- 예외를 사용하면 오류 처리 코드가 비즈니스 로직에서 분리가 되어 깔끔해진다.
- try ~ catch문은 코드 구조에 혼란을 주므로 따로 분리하는 것이 좋다.
함수짜는 법
- 처음에는 길고 복잡하지만 코드를 다듬고, 이름을 바꾸고, 중복을 제거하고, 클래스를 쪼갠다.
- 리펙토링 중에도 항상 단위테스트는 통과해야 한다.
4장. 주석
- 주석은 필요악이다. 코드는 변화하고 진화하는 반면 주석을 유지하고 보수하기란 현실적으로 불가능하기 때문이다.
- 부정확한 주석은 아예 없는 주석보다 훨씬 나쁘다.
- 코드만이 자기가 하는 일을 진실되게 말하기 때문에 주석을 가능한 줄이도록 최대한 노력해야 한다.
주석은 나쁜 코드를 보완하지 못한다.
- 나쁜 코드를 설명하기 위해 주석을 달 시간동안 나쁜 코드를 개선할 방법에 대해서 고민해라
- 몇초만 생각하면 코드로 의도를 충분히 표현할 수 있다.
좋은 주석
[의미를 명료하게 밝히는 주석]
- 인수나 반환값이 표준 라이브러리나 변경하지 못하는 코드에 속할 경우 주석을 통해 명료하게 의도를 밝히는 것이 더 좋다.
[결과를 경고하는 주석]
- 다른 프로그래머에게 결과를 경고할 목적으로 주석을 사용한다.
[TODO 주석]
- 앞으로 해야할 일을 TODO 주석으로 남겨놓으면 편하다.
나쁜 주석
[같은 이야기를 반복하는 주석]
- 주석이 같은 코드 내용을 그대로 중복한다.
[있으나 마나 한 주석]
- 너무 당연한 사실을 언급하며 새로운 정보를 제공하지 못하는 주석
[주석처리 해놓은 코드]
- 소스코드 관리 시스템이 우리를 대신해서 기억해주므로 주석으로 처리할 필요가 없다.
Backend Developer