11. 클린코드를 작성하라

가이드라인

• 목표 : 클린코드를 작성한다.

• 실천 : 개발 이후 코드 악취를 남기지 않는다.

• 효과 : 클린 코드는 곧 유지보수 가능한 코드라서 유지보수성이 개선된다.

스스로 프로라고 자부한다면 클린 코드는 필수다.

-로버트 C.마틴

1. 흔적을 남기지 마라

• 보이스카웃 규칙 : 처음 발견했을 때보다 더 깨끗하게 청소하라

• 코드도 마찬가지로 더 깔끔하고 유지보수하기 좋은 코드로 만들어야 한다

2. 적용가이드

코드 악취 예방을 위한 7대 보이스카웃 규칙

1. 단위 수준의 코드 악취를 남기지 말라

2. 나쁜 주석을 남기지 말라

3. 주석 안에 코드를 남기지 말라

4. 죽은 코드를 남기지 말라

5. 긴 식별자 이름을 남기지 말라

6. 매직 상수를 남기지 말라

7. 제대로 처리 안한 예외를 남기지 말라

2.1. 단위 수준의 코드 악취를 남기지 말라

• 2장 긴단위, 3장 복잡한 단위, 5장 인터페이스가 큰 단위 악취에 관한 가이드 라인

• 이 중 하나라도 어길 이유는 없다. 무조건 지키자

• 리팩토링은 제때 해야함. 제때 라는 가급적 빠른 시간내에 , 적어도 버전 관리 시스템에 커밋을 하기전에...

• 단위 크기, 복잡도, 파라미터 등

2.2. 나쁜 주석을 남기지 말라

• 주석이 타당한 경우 or 주석이 쓸모 있는 경우는 지극히 제한적

• 코드에서 주석을 빼라!

• 단위를 작게 분리하여 메서드화 시키도록 노력하기

2.3. 주석 안에 코드를 남기지 말라

• 버전관리 시스템을 활용

• 변경전 코드를 주석처리 하는 행위 금지

• 쓸데 없는 주석은 산만하게 할 뿐 아니라 가독성도 해친

2.4. 죽은코드를 남기지 말라

• 전혀 실행되지 않거나 실행 결과가 사실상 죽은거나 다름없는 코드

• 쓸데 없는 주석도 이에 해당함

2.5. 긴 식별자 이름을 남기지 말라

• 의미 있는 이름 짓기

• 공식적인 명명규칙, 도메인에 특정한용어를 약식으로 표현 등

• 지나치게 긴 식별자는 지양

2.6. 매직상수를 남기지 말라

• 의미가 불명확한 숫자나 리터럴 값

• 코드라인이 늘어나더라도 필드로 빼서 사용 or enum 활용

2.7. 제대로 처리 안 한 예외를 남기지 말라

• 언제나 예외를 잡아라

  • 시스템 오류 -> 로그로 남기기

  • 예외는 꼭 잡기, catch 블록을 비워두는건 좋지 않은 습관 -> 어떻게 해서 예외가 발생했는지 아무런 정보도 남기지 않기 때문

• 구체적인 예외를 잡아라

  • 예외를 따라 특정한 이벤트로 거슬러 올라가려면 구체적인 예외를 잡아야함

  • 일반적인 예외만으로는 어떤 상태에 해당하는 정보나 실패를 유발한 이벤트를 추적할 정보가 불충분함

  • Throwable, Exception, RuntimeException 을 직접 붙잡지 말기

• 구체적인 예외는 최종 사용자에게 보여주기 전에 일반적인 메시지로 옮겨라

  • 최종사용자에게 구구절절 긴 메시지를 흘릴 필요는 없다

  • 시스템 내부 로직이나 내용을 쓸데없이 노출시키면 보안상 좋지 않음