서술적인 이름을 사용하라
많은 개발자들이 자기 마음대로 줄임말을 사용하고 있다.
카드코드를 어떤 회사에서는 CC라 사용하고있고, 어떤 회사에서는 취소를 CC로 사용하고있다.
나는 규약된 데이터 카탈로그, 스키마가 있는게 아닌 이상 줄임말을 지양하고 있다.
길고 서술적인 이름이 짧고 어려운 이름과 긴 주석보다 좋다.
나는 여러 단어를 사용해 함수 기능을 잘 표현할 수 있는 서술적인 이름을 채택한다.
서술적인 이름을 사용하면 머릿속에서도 설계가 뚜렷해져 코드를 개선하기 쉬워진다.
대신 앞서 설명한것 처럼 일관성이 있어야 한다. 같은 동사, 명사, 문구를 사용하도록 하자.
거래는 Transaction이 될 수 있고 Trade가 될 수 있고, 조회는 select, search, inquiry 등등 다양한 표기가 올 수 있기에 일관성을 유지하자.
함수 인수
함수에서 이상적인 인수의 개수는 0개이다.
다음은 1개, 2개이다. 3개 이상은 피하는 편이 좋다.
4개 부터는 특별한 이유가 필요하지만 사용하지 말자.
인수는 개념을 이해하기 어렵게 만든다.
Request와 Response의 객체를 매 함수마다 인수로 넘기고 있다면, 사용자는 매번 그 인수를 해석해야한다.
다른 객체가 등장하기라도 하면 더 한 눈에 들어오지 않는다.
코드를 읽을 때는 inludeSetUpPageInto(new PageContent) 보다 includeSetupPage()가 이해하기 더 쉽다.
함수와 인수의 추상화 수이 다르기에, 코드를 읽는 사람이 현 시점에서 별로 중요하지도 않는 StringBuffer 등의 세부사항을 알아야 하기 때문이다.
테스트 관점에서 보면 인수는 더 어려워진다. 갖가지 인수 조합으로 함수를 검증하는 테스트 케이스를 작성해야 하는것 보다 인수가 없는 테스트 케이스가 더 간단하다.
함수는 가능한 입력인수와 출력인수가 매핑이 되도록 하여야 한다.
setUpPage.render(pageData)는 이해하기 아주 쉽다. pageData를 render한다는 뜻이다.
*플래그 인수
플래그 인수는 추하다. 함수로 bool 값을 넘기는 관례는 어디서든 쉽게 찾아볼 수 있는데, 이렇게 사용하지말자
함수가 한번에 여러 일을 처리하고 있다고 대놓고 공표하는 셈이다.
(플래그가 참이면 이걸 하고, 거짓이면 저걸 한다는 말)
오류코드보다 예외를 사용해라
로직에서 실패시 오류코드를 반환하는 것 보다 예외처리를 하는 편이 더 깔끔하다.
try, catch 를 별도 공통 함수로 만들어 모든 오류를 처리할 수 있도록 하자.
객체지향 프로그래밍은 코드를 부모 클래스로 몰아 중복을 없앤다.
구조적 프로그래밍 (AOP, COP) 이들은 모두 중복제거 전략으로 볼 수 있다.
이를 활용하여 리팩터링해가자. 훨씬 가볍고 읽기좋은 소스를 볼 수 있다.
나는 이 과정을 좋아한다.