Clean Code를 위해 지켜야 하는 몇 가지 사항들

1. 변하는 부분에 대해서 깊게 생각해보기.

항상 변하는 부분이 문제인데, 변할 가능성이 높은 부분은 찾아서 추상화를 하면 문제가 해결된다. 좋은 설계 패턴을 익혀서 차후 코딩 패턴을 분석하는 데에 문제가 없도록 하자.

​

2. 주석에 대해서 생각해보기

주석을 달 때에 신중해야 한다, 주석 자체가 나쁜 설계임을 시인하는 걸 수도 있다.

​

3. 소프트웨어의 응집성이 높아야 한다.

​

4. 항상 같이 등장하는 코드들이 있으면 Data class를 만들어 사용하는 것이 효과적이다.

​

5. 매개변수가 긴 경우가 있는가? 함수 내부에서만 쓰이는 것들은 함수에서만 쓰이는 거니까, 꼭 필요한 부분만 매개변수로 넘기도록 하자.

​

6. 객체로부터 특정 값을 얻은 후에, 이 값들을 다른 메서드에 전달하고 있다면, 객체 자체를 넘겨주고 사용하고자 하는 메서드 안에서 해결하는 것이 더 효과적이다.

​

7. 하나의 클래스가 변경되어야 할 이유가 한 개가 아니고, 많다면 그건 올바르게 설계된 클래스가 아니다.

​

8. 만약 A Class를 만들었는데 자꾸만 B Class를 참조하며 개발하고 있다면 문제가 좀 있다. 또한 A Class <-> B Class 의존관계가 심하다면 이것 역시 문제가 있는 설계이다.

​

9. Method chaining 이 무조건 나쁘다기보다, 많이 Chaining 하게 되면 가독성이 떨어진다.

​

10. 전화번호를 예로 들면, "010-1234-1234" 무조건 Spring으로만 원시 타입에 의존하지 말고, PhoneNumber Class를 따로 만들자.

​

11. 반복되는 동일 형태의 switch 문을 사용하지 말고, 다형성을 이용해서 개발해보자.

​

12. 미래에 필요한 기능을 미리 만들지 말자.

​

13. 상속할 때, 필요 없는 메서드를 상속해야 하는 경우를 주의하여 개발하자.

​

14. null을 넘기지 말고, null을 반환하지 말자. optional을 쓰자.

​

15. FLAG 인자를 가급적 피해야 한다. 예를 들어, 여기서 이야기하는 FLAG 인자란, FLAG를 Boolean 타입의 파라미터로 넘겨서 true만 이러한 로직을 실행하도록, false 면 이러한 로직을 실행하도록 하게끔 작성하는 로직이 없도록 해야 한다.

​

16. 함수의 목적이 명확해야 한다.

​

17. a 객체. foo(b 객체) 이러한 경우 a만 바뀌어야 한다. b를 바뀌게 설계한다면 그건 잘못된 것이다.

​

18. 관련 있는 함수들은 가깝게 잘 모아두자.

​

19. 모든 것을 객체지향 적으로 모델링 하지 말자.

​

20. 낮은 결합성을 지향하자. 서로서로 의존하는 클래스들의 수를 최소화하자. DIP를 기억하자.

​

21. 객체 생성이 필요 없는 경우 abstract로 정의하자.