작게 만들어라!
함수는 작을 수록 좋다. 20라인도 긴 편이며, 짧은 함수로도 멋진 프로그램을 구현가능하다.
if 문 / else 문 / while 문 등에서 들여쓰기가 2단이상으로 중첩구조가 생겨야 하면 함수를 분리하는게 좋다.
한 가지만 해라!
하나의 함수는 한 가지 일만을 해야 하며, '한 가지'만 하는지 판단하는 방법으로는 함수 내의 일부 로직을 의미 있는 다른 이름으로 추출할 수 있다면, 그 함수는 여러 작업을 하는 셈이다.
함수 당 추상화 수준은 하나로!
함수 내 모든 문장들의 추상화 수준은 동일해야 한다. 한 함수에서 호출되는 내부 함수는 추상화 수준이 한 단계 낮은 함수가 나오는 식이다. 이것을 내려거기 규칙이라 부를 수 있다.
Switch문
switch문이나 if ~ else 문을 이용하는 부분은 비슷한 로직이 반복될 우려가 있으며, 케이스가 추가될 때마다 수정되어야 한다. Abstract Factory 패턴을 활용해서 추상 클래스로 만들어 두고 자식 클래스로 구현하도록 하자.
서술적인 이름을 사용하라!
함수의 이름은 짧고 어려운 이름보다는 길고 서술적인 이름이 좋다. 이름은 일관성을 유지하면서 어떤 기능이 있을지 쉽게 예측되는 이름으로 설명되어야 한다.
함수 인수
함수 인수는 적을 수록 좋다. 2개이하로 사용하고 4개이상은 특별한 사유가 없는한 사용하지 마라.
여러 함수에서 인자로 넘겨야 할 경우에는 클래스내에 인스턴스 변수로 두는 것을 검토하라. 입력 인수를 변경하는 것은 코드를 다시 살펴보게 만들므로 자제하라.
writeField(outputStream, name)와 두가지 개념을 인수로 넘기기 보다는 outpubStream을 클래스 변수로 만들어서 인수로 넘기지 않거나, outputStream.writeField(name)와 같이 쓰는 방법, FieldWrite라는 새 클래스를 만들어 write메소드를 구현하는게 낫다. 함수와 인수는 동사/명사 쌍을 이뤄서 의도를 표현하면 좋다. ~~을 ~~ 한다.
부수 효과를 일으키지 마라!
checkPassword라는 함수안에서 Session을 초기화하는 로직이 들어있으면 안된다. 함수명과 같이 패스워드 체크기능만 있어야 한다. 인수로 들어간 값을 변경하는 것은 피하고 다른 방법을 찾아본다.
명령과 조회를 분리하라!
객체 상태를 변경하는 것과 객체 정보를 반환하는 것을 하나의 함수안에 있으면 혼란을 초래한다. 특히 if문안에 하나의 함수에서 두가지를 하면 상태만 체크하는 것으로 잘못 읽힐 수 있다.
오류 코드보다 예외를 사용하라!
오류처리를 if ~ else ~ 형태로 처리하기보다는 try ~ catch 형태로 처리하고, try ~ catch 부분은 별도 함수로 뽑아내서 다른 함수와 분리하자
반복하지 마라!
중복은 소프트웨어에서 모든 악의 근원이다.
구조적 프로그래밍
구조적 프로그래밍에서는 루프안에서 break, continue문을 사용하지 않도록 하고, goto도 못쓰게 하는 원칙을 세웠었다. 하지만 함수가 충분히 작다면 루프안에서의 return, break, continue는 괜찮다.
함수를 어떻게 짜죠?
처음부터 나이스한 구조로 개발은 불가능하다. 처음에는 길고 복잡하며, 들여쓰기나 중복 루프도 많게 짜여진다. 이름도 즉흥적이고 중복된 코드도 존재한다. 이렇게 서트른 코드로 단위 테스트 케이스를 만든 후 코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한다. 클래스를 쪼개기도 한다. 그러나 이 과정에서 단위테스트는 항상 통과해야 한다.
결론
master 프로그래머는 시스템을 구현할 프로그램이 아니라 풀어갈 이야기로 여긴다.