시작하며

• 객체지향 원칙 
  • 하나의 Method에서는 한 단계의 들여쓰기만 한다. 
  • else 예약어를 쓰지 않는다. 
  • 모든 원시값과 문자열을 포장한다.
  • 한줄에 점을 하나만 찍는다. 
  • 줄여쓰지 않는다. (축약 금지)
  • 모든 엔티티를 작게 유지한다.
  • 3개 이상의 인스턴스 변수를 가진 클래스는 지양한다.
  • 1급 콜렉션을 사용한다.
  • getter/setter/property를 쓰지 않는다.

- 지금 내가 플젝하고 있는 코드는 지키지 않고 있다.. 상당히.. 이렇게 지키면서 가능할까 싶을 정도로 

  그나마 API 위주의 코틀린 플젝은 지키고 있는 것같은데 메인 프로젝트는 엄청나게 거리가 멀다. 근데 동시에 그렇기 때문에 지금 우리 메인 프로젝트가 리팩토링을 하기엔 한동안 개선 작업 없이 전부 붙어야 가능할 것이라고 생각하고 있나보다. (실제로 리팩토링 자체가 그 정도 공수가 들어가는게 맞는 듯)

 

 

- 첫번째 과제에서의 지켜야할 원칙은 첫번째와 두번째이다. 하나의 method에서 1단계만 유지하고 else는 쓰지말것 
  (else를 쓰지마라고 하는 것은 모든 케이스가 여기에 빨려들어가서 리팩토링할 때 묶여서 그런듯)
  + 그리고 추가로 하나의 Method 라인 수가 15라인이 넘지 않아야 한단다.. 세상에.. 

 

• Method 가이드 라인
  • 작게 만들어라 (15라인 넘어가지 않게)
  • 한 가지만 해라 (이름 값 해라 같음 한 가지 기능에만 집중)
  • 함수 당 추상화 수준은 하나로 (함수 내 모든 문장이 동일한 추상화 수준에 있어야 한다는 말)
  • 서술적인 이름을 사용하라. (변수명은 길어도 괜찮대 대신 일관성은 있어야 하고 함축적이면 안 됨)
  • 함수에서 인수의 갯수는 0개가 가장 좋으며 3개는 피하는 편이 좋으며 4개 이상은 특별한 이유 아니면 사용해선 안 된다. 
    (인수가 2~3개 필요한 경우엔 인수를 통해 독자적인 클래스를 생성하여 사용할 수 있는지 검토한다.)
    Ex) testFunction(double x, double y, double radius) ==> testFunction(Point center, double radius)
  • 명령과 조회를 분리하라 : 개체 상태를 변경하거나 개체 정보를 반환하거나 둘 중 하나만 하게 하자 
  • 오류 코드보다 예외를 사용하라 : 이 때 예외 처리하는 것고 하나의 작업에 속하여 오류를 처리하는 함수는 오류만 처리하는 것이 맞다. try{}catch(){} 는 따로! 
  • 코드 중복은 당연히 만들지 말자
• Code convetion 
  • 가로 120행 맞추자 (이거 맞춰야 하는 거였나봐
  • )