Clean Code

Clean Code

1. 깨끗한 코드를 유지해야하는 이유?

• 개발하면서 최적화 된 코드를 작성해라 (=코드 개선을 미루지마라. 나중은 절대 오지 않는다.) -> 깨진 유리창의 법칙
• 나쁜 코드는 점진적으로 생산성을 하락시키게 한다.
• 코드는 읽기:쓰기 비율이 10:1
• 클린 코드를 구분할 줄 아는 것과 작성할 줄 아는 것은 다르다.
• 보이스카우트 규칙 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라 = 체크아웃 할 때보다 좀 더 깨긋한 ㅋ코드를 체크인 한다면 코드는 절대 나빠지지 않는다.

2. 의미있는 이름

• 의도를 분명히 밝힌 이름을 사용하라. int d -> int appCratedDate.
• 그릇된 정보를 피하라. accountList -> accounts or accountGroup(리스트의 List인지 계정의 집합인지 헷갈릴 수 있음)
  • 유사한 개념은 유사한 표기법을 사용하고, 흡사한 이름을 사용 하지마라.
• 숫자 대신 Constant로 정의해서 사용하자.

3. 함수

• 작게 만들어라.(20줄을 넘기지 마라.)
• 한가지만 해라.
• 다형성을 이용해라. switch문은 abstract FactoryPattern 을 이용하라.
• 함수 인수를 최소화하라.
• 명령과 조회를 분리하라. (한가지만 해라와 같은 문맥)
  • ex) boolean set(String ...) 과 같이하여 if(set(string)) 을 활용하려 할 때,
  • if(set(string))의 이중해석 가능여부가 있다. setString이 되어있는지 확인 or setString을 시도하였을 때 실패한건지 확인
• 오류코드보단 예외를 사용해라. try/catch 를 사용하여 가독성 향상시킬 것
• 반복을 제거해라.

4. 주석

• 좋은 주석
  1) 법적인 주석
  2) 정보를 제공하는 주석 (정규표현식으로 쓰인 값의 경우)
  3) 구현의도를 설명하는 주석 ()
  4) 의미를 명료하게 밝히는 주석 (표준 라이브러리를 사용해서 가독성이 떨어지게 되는 경우)
  5) 결과를 경고하는 주석 (테스트 실행시간이 오래걸린다고 경고)
  6) TODO 주석
  7) 중요성을 강조하는 주석
• 나쁜 주석
  1) 주절거리는 주석
  2) 코드랑 내용이 중복되는 주석 오해할 여지가 있는 주석
  3) 의무적으로 다는 주석 (비공개 코드에 대한 Javadocs)
  4) 있으나 마나 한 주석
  5) 닫는 괄호에 다는 주석
  6) 이력, 저자를 표시하는 주석 << Git 에 다 나온다.
  7) 함수나 변수로 표현할 수 있는 주석
  8) 전역 정보를 제공하는 주석
  9) 주석으로 처리한 코드 << 형상관리 시스템으로 필요 없음
  10) 위치를 표시하는 주석
  11) 모호한 주석

5. 형식 맞추기

• 한가지 규칙에 합의하고 모든 팀원은 규칙을 따라 일관적인 스타일을 유지해야 한다.
• 세로 형식 맞추기
  • High Level -> Low Level 순서로 작성
    • 가장 아래에 저차원 함수와 세부내역을 둠.
  • 빈 행으로 분리하라
  • 비슷한 동작을 수행하는 함수들은 가까이 배치
• 가로 형식 맞추기
  • 최대 120자라고 생각하자.

6. 오류 처리

• 깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다. 오류 처리코드로 인해 프로그램 코드를 이해하기 어려워진다면, CleanCode가 아니다.
• 오류 코드보다 예외를 사용하라.
• try-catch-finally 부터 작성하라.
  • TDD 방식으로, Exception 날 경우를 미리 UnitTest 작성 후, Exception 범위를 좁힌다.
• Exception 에 충분히 의미를 부여하라.
• 호출자를 고려해 Exception 클래스를 정의하라.
  • 외부라이브러리를 많이 사용하는 경우, Exception이 많아 지저분해질 수 있다. 이 때, 외부라이브러리 포팅하는 함수를 따로 만들어라.
• 정상흐름을 정의하라.
• null을 반환하지 마라
• null을 전달하지 마라.

7. 경계

• 오픈소스, 패키지 구매, 다른 팀의 컴포넌트와 같은 외부 코드들을 사용하게 된다. 이 때, 우리 코드와 외부 코드의 경계를 깔끔하게 하자.
• 제공자: 더 많은 환경에서 돌아가도록 적용성을 넓히고 싶다.
• 사용자: 자신의 요구사항에 집중하는 인터페이스를 원한다.
• 외부라이브러리의 경계가 애매하다면, 캡슐화하여 사용하라.
• 외부 라이브러리 사용법을 문서를 참고해 익히는 것도 중요하지만, 간단한 테스트 케이스를 작성하면서 익히도록 하자.(?) 이미하는듯
• 경계에서는 많은 변경이 발생할 수 있으므로, 비용을 최소화 하도록 구성하자.
• 경계에 위치하는 코드를 깔끔하게 분리해야, 내부에서 외부코드에 대해 알 필요가 없어진다.

8. 클래스

• 캡슐화가 중요하다.
• 클래스도 작게(Single Responsibility Principle), 하나의 클래스는 하나의 책임만 갖도록 하자.
• 응집도가 높게 유지하도록 여러개의 클래스로 분리하자.
• 변경하기 쉬운 클래스를 만들자. (OCP: 확장에 open, 수정에 close, DIP(Dependency Inversion) 추상화 클래스에 의존)