upload with deployPosts.sh

_posts/2023-11-14-[Book]CleanCode9.md

@@ -0,0 +1,118 @@
+---
+title: "[Book] Clean Code - 8주차 (15 ~ 17장)"
+date: 2023-11-14 22:52:55 +0900
+categories: [Backend, Books, Clean Code]
+tags: [clean code, book]
+#use_math: true
+---
+
+# JUnit 들여다보기 + SerialDate 리팩터링
+
+JUnit 프레임워크는 유명한 자바 프레임워크이다. 그만큼 도움되는 코드와 생각해보고 고칠 수 있는 코드들도 존재한다.  
+또한, SerialDate 클래스는 JCommon 라이브러리에 존재하는 클래스로 날짜를 표현하는 자바 클래스이다.  
+15, 16장은 모두 JUnit과 SerialDate의 코드들을 보면서 클린 코드에 대해 점검하는 시간을 가지고 있다. 하지만, 이들을 글로 옮겨 적기에는 부적절해서 생략하며 직접 읽어보는 편이 더 도움이 되리라 생각한다.  
+<br>
+
+# 냄새와 휴리스틱
+
+지금까지 클린 코드란 어떠한 것들이었는지, 휴리스틱과 냄새에 관한 이야기들을 모두 모아서 정리 해보자.  
+<br>
+
+### Comment (주석)
+
+1. 부적절한 정보 : 다른 시스템을 위한 정보는 주석으로 적절하지 않다.
+2. 쓸모 없는 주석
+3. 중복된 주석
+4. 성의 없는 주석
+5. 주석 처리된 코드  
+<br>
+
+### Environment (환경)
+
+1. 여러 단계로 빌드해야 한다. : 하나의 빌드 과정으로 간단히 빌드할 수 있어야 한다.
+2. 여러 단계로 테스트해야 한다. : 하나의 버튼, 하나의 명령으로 테스트가 간단히 진행되어야 한다.  
+<br>
+
+### Function (함수)
+
+1. 너무 많은 인수
+2. 출력 인수 : 인수가 함수의 결과를 나타내서는 안된다.
+3. 플래그 인수 : 플래그 인수의 존재는 함수의 기능이 너무 많다는 의미를 가진다.
+4. 죽은 함수 : 호출되지 않는 함수는 제거하라.  
+<br>
+
+### General (일반)
+
+1. 한 소스 파일에 여러 언어 사용 : 자제하는 것이 좋다.
+2. 당연한 동작을 구현하지 않는다. : 다른 개발자가 당연하게 여길 만한 동작과 기능을 제공해야 한다.
+3. 경계를 올바로 처리하지 않는다. : 시간을 들여 경계 조건을 찾고 테스트하자.
+4. 안전 절차 무시 : 컴파일러 경고와 같은 안전 절차를 지켜라.
+5. 중복 발생
+6. 추상화 수준이 올바르지 못하다.
+7. 기초 클래스가 파생 클래스에 의존한다. : 기초 클래스는 파생 클래스를 모르는 상태가 일반적이다.
+8. 과도한 정보 : 캡슐화를 비롯하여 외부에 많은 정보가 보이지 않도록 하라.
+9. 죽은 코드 : 작동할 수 없는, 작동하지 않는 코드를 제거하라.
+10. 수직 분리 : 연관된 내용은 가까운 코드 범위안에 작성하라.
+11. 일관성 부족
+12. 잡동사니 : 쓸모없는 코드를 제거하라.
+13. 인위적 결함 : 관계없는 상수, 변수, 함수, 클래스들은 서로 분리하라.
+14. 기능 욕심 : 다른 클래스의 기능을 침범, 의존하지 않도록 작성하라.
+15. 선택자 인수 : 인수를 통한 동작 제어(boolean 등)는 자제하라.
+16. 모호한 의도
+17. 잘못 지운 책임 : 코드는 사용자의 기대에 맞게, 책임(기능)에 맞게 동작해야한다.
+18. 부적절한 static 함수
+19. 서술적 변수 : 읽기 쉬운 코드를 만들어준다.
+20. 이름과 기능이 일치하는 함수
+21. 알고리즘을 이해하라.
+22. 논리적 의존성은 물리적으로 드러내라.
+23. If/Else, Switch/Case보다 다형성을 사용하라. : 다형성을 우선적으로 고려하라.
+24. 표준 표기법을 따르라.
+25. 매직 숫자는 명명된 상수로 교체하라. : 숫자만으로 의미를 이해할 수 있는 경우를 제외하면 상수로 뜻을 표현하는 것이 좋다.
+26. 정확하라.
+27. 관례보다 구조를 사용하라.
+28. 조건을 캡슐화하라.
+29. 부정 조건은 피하라.
+30. 함수는 한 가지만 해야한다.
+31. 숨겨진 시간적인 결함
+32. 일관성을 유지하라.
+33. 경계 조건을 캡슐화하라.
+34. 함수는 추상화 수준을 한 단계만 내려가야 한다.
+35. 설정 정보는 최상위 단계에 둬라.
+36. 추이적 탐색을 피하라. : 하나의 모듈은 주변 모듈을 모를수록 좋다.  
+<br>
+
+### JAVA (자바)
+
+1. 긴 import 목록을 피하고 와일드카드를 사용하라. : 와일드카드를 사용한 import는 사용의 모호함과 충돌 가능성이 존재하지만, 문제가 발생할 확률이 적고 IDE의 기능들을 사용함으로써 와일드카드 사용을 더 추천한다고 한다.
+2. 상수는 상속하지 않는다.
+3. 상수 대 Enum : `public static final int`와 같은 옛날 방식 대신 Enum을 사용하자.  
+<br>
+
+### Naming (이름)
+
+1. 서술적인 이름을 사용하라.
+2. 적절한 추상화 수준에서 이름을 선택하라.
+3. 가능하다면 표준 명명법을 사용하라.
+4. 명확한 이름
+5. 긴 범위는 긴 이름을 사용하라.
+6. 인코딩을 피하라. : 과거 개발 환경에서 정보를 표현하기 위해 사용했던 접두어들은 이제 필요하지 않다.
+7. 이름으로 부수 효과를 설명하라.  
+<br>
+
+### Test (테스트)
+
+1. 불충분한 테스트
+2. 커버리지 도구를 사용하라.
+3. 사소한 테스트를 건너뛰지 마라.
+4. 무시한 테스트는 모호함을 뜻한다.
+5. 경계 조건을 테스트하라.
+6. 버그 주변은 철저히 테스트하라.
+7. 실패 패턴을 살펴라.
+8. 테스트 커버리지 패턴을 살펴라.
+9. 테스트는 빨라야 한다.  
+<br>
+
+## 결론
+
+많다면 많고, 적다면 적은 목록들이다. 이러한 디테일 하나하나가 모여서 클린 코드가 되며, 일부 규칙만을 따른다고 해서 클린 코드가 될 수 없다.  
+사소한 가치들이 모여서 습관, 전문가 정신, 장인 정신을 만들며 소프트웨어 장인으로 향할 수 있는 길이 될 것이다.