[클린코드] Ch 3-4

Chapter 3, 4

함수, 주석

인상깊은 구절

• 작은 함수가 좋다
  • 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서지 않을 것
• 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한번에 한 단계씩 낮아지도록: 내려가기 규칙
• switch문과 같이 작게 만들기 어려운 경우는 다형성을 이용항여 최대한 중복을 줄일 것
  • 중복을 줄이지 않은 경우, SRP(Single Response Principle), OCP(Open-Closed Principle) 등 기본적인 객체지향 원칙을 깨게 됨
  • 추상 팩토리 (Abstract Factory)에 숨겨두는 형식
    • Employee type에 따라 isPayday, calculatePay 등의 함수 작동이 매번 다르다면, 단순하게 매 메소드마다 switch문을 사용하는 방식을 생각할 수 있음
    • 하지만 해당 메소드들을 abstract method로 Employee abstract class 안에 둔 다음에, 이를 extends 하여 각 Employee type을 구현
      • 해당 class들에는 type에 따라 다르게 구현된 isPayday, calculatePay등의 함수 내용이 들어있음
    • EmployeeFactory를 만들어, employee type에 따라 해당 class의 생성자를 호출하게 하는 switch문 하나만 작성하면, 모든 메소드들에 대하여 switch문을 만들어야하는 불상사를 줄일 수 있음
• 가장 이상적인 함수 인수 갯수는 0개(무항), 4개 이상은 특별한 이유가 필요
  • 흠 그런데 요건 사실 공통화를 계속 하다보면 항의 갯수가 많아지기 마련인데 (사실 4개도 일반적으로 많이 사용), 그래도 줄일 수 있을만큼 최대한 줄여보자는게 main point같음
  • 사실 4개 이상 인자를 가진 함수가 많은걸..
  • 입력 인수를 변환하는 함수라면 변환 결과는 반환값으로 돌려줄 것!
    • void transform(StringBuffer out)보다 StringBuffer transform(StringBuffer in) 사용하기
    • 객체라서 method 내부에서 인자를 변경하면 method 종료 이후에도 변경된 객체로 수행이 되지만, 명시적으로 드러나지 않으니 (메소드 수행 이후에 객체의 변경 여부를 알 수 없음) 명시적으로 새로운 객체로 return해주는 것이 좋다
    • 또는 void transform(Report report)나 Report transform(Report report)로써 report를 변경시키는 것이 아니라, transform을 Report class 내부 method로 구현하여 void transform()으로 만들고, report.transform()과 같이 함수가 속한 객체 상태를 변경하는 방식이 제일 best
• 함수 param으로 bool값을 넘기지 말고 bool값에 따른 분기 이후를 함수로 만들 것
• 함수와 인수가 동사/명사 쌍을 이루도록 구성하기
  • 함수 이름에 인수 이름을 넣어 인수 순서를 기억할 필요가 없도록 하기
• try/catch 블록은 별도 함수로 뽑아내서 구현하기
  • 정상 동작과 오류 처리 동작의 분리!
• 코드를 부모 클래스로 몰아 반복 없애기
  • 구조적 프로그래밍, AOP(Aspect Oriented Programming), COP(Component Oriented Programming) 모두 중복 제거 전략
• 주석은 언제나 실패를 의미
  • 주석의 유지보수는 현실적으로 불가능
    갈길 잃은 주석 코드들이 곳곳에 보인다.. 특히 javadocs에 따른 param, returntype들을 제시해놓은 주석들은 실제 정보와 맞지 않기가 쉽상..
• 그나마 의미 있는 주석들
  • TC 등에서 의도를 설명하는 주석 ex) 경쟁 조건을 만들려 시도하는 부분
  • TC를 꺼야하는 이유를 설명하는 주석 ex) batch test 돌리는 경우 시간이 너무 오래 걸리므로 필요한 경우에만 사용하세요 등
  • TC의 경우 method 상단에 @Ignore("실행이 너무 오래걸림") 과 같이 제시하는 것이 much better
  • TODO 주석
    • 주기적으로 TODO 주석 점검하여 삭제가 필요
• 나쁜 주석
  • 수정 이력 기록: 우리는 이제 SVC가 있으니 쓰지 말것
  • 닫는 괄호에 어떤 걸 닫는지 표현: 그럴바에 함수를 짧게 만들 것
  • 코드 주석 처리: SVC 있으니까 용감하게 삭제할 것
    하지만 실상은.. SVC있어도 나혼자만 일하는게 아니기에 커밋이 너무 많아서 그 때의 커밋 기록을 찾는게 쉬운일이 아니라.. 주석 처리 해두지만 그러지 말고 git을 더 잘 다루도록 노력하자

추가 공부

• 구조적 프로그래밍, AOP(Aspect Oriented Programming), COP(Component Oriented Programming)

Comment

• 읽을수록 자바 기초 공부가 필요하다는 생각이 절실하게 든다
• 이펙티브 자바 책도 읽어봐야겠다 (어차피 주말에 할 거 없으니까..)