Java/클린 코딩 (with OOP)

[JAVA] 자바 클린 코딩 하기 - 객체지향이기위해 지켜야하는 것들

민돌v 2022. 6. 1. 23:41

 

첫 회사에 들어와, 온보딩을 하면서 가장 많이 배우고, 아직도 어려운게 

깨끗하게 코딩하고, 협업을 위해 규칙있게 코딩하는 방법이다

 

즉, 클린코딩,, 말로만하고, 글로만 읽는 클린코딩이 아니라

내 코드에 직접 적용하려니 헷갈리는게 이만저만이 아니었다.


 

그래서! 알아가고 있는 것을 기록하기위한 포스팅이다! (계속계속 추가할 예정)

 

 


목 록

1. 자바 네이밍 규칙

  • + 메소드 명은 직관적이게
  • + 메소드 명은, 그 메소드를 가지는 객체의 기준으로 작성 (ex - Member.createMember() X 👉 Member.create() )
  • 객체를 기준으로 더 직관적이게 작성

2. 주석 사용은 지양

3. 정적변수, 동적변수 - 재할당 하지 않는 것은 final 처리 (상수 변환)

4. 정규표현식은 나이스? 

5. Integer(Wrapper Class) 보다 int -> 유효성 구분지어 검사

6. 객체 책임은 단일로 - 값 객체 

7. 기차충돌은 지양하자  - 디미터의 법칙(캡슐화가 깨진다, 호출하는 쪽에서, 나만 알도록 - 호출하는 쪽에서,, 최대한 내가 뭘 가지고 있는지 모르게 (getter 도 이래서 지양) ) 

8. 인터페이스를 상속받는 컬렉션들 ex) hashmap, hashset -> 직접 호출말고, 인터페이스로 호출

(인터페이스에 구현체를 집어넣자)

HashSet<Integer> list = new HashSet<>();

//이렇게
Set<Integer> list = new HashSet<>();

 

9. else는 사용하지 않는다. / 불필요한 if 도 x (바로 return)

10. null 을 처리하는 방법 - equals, objects.isNull

11. 정적 팩토리 메소드 패턴의 사용

12. 추상클래스와 팩토리 패턴을 사용해야할 때
 
13. 매개변수는 적을수록 좋다.
 
14. 삭제로직은 신중하게(없어도되는 도메인에는, 악용되지 않도록 만들지를 말자!) - 삭제시에는 soft delete
 
15. 비지니스 도메인 설계 생각하기
  • 중요한 값은 request받아도, server단에서 체크

16. 엔티티는 순수성을 가지게 해라 (최대한 외부의 정보를 알지 못하게 / DTO는 Entity를 알아도 되지만, Entity는 DTO를 모르게)

17. 테스트시 getter 보다는 equals( ) 로 객체 자체를 비교

18. 공통부분 중복 제거 시, 어떤게 상황에 맞는지, 왜 써야하는지 생각해보자 (추상 클래스 상속 vs 인터페이스 vs 유틸클래스)

  • 내가 아닌, 내 코드를 수정할 다른사람을 위해 필요한 기능과 권한만을 부여 
  • "기능을 모두 가지고 있어서 가능할 수 있는거와, 필요한 기능을 불러와서 사용하는 것은 다르다"

19. 메소드의 void는 최대한 지양 

  • 다른 메소드에 너무 많은 권한을 주게되면 명시적인 단위 테스트가 힘들어지고, 메소드가 점점 거대해진다.
  • 중복되거나, 작은 메소드로 추출할 수 있는 메소드는 추출하고, 하나의 상태값을 계속 핸들링한다면, 클래스로 분리하자

20. DB에서 데이터를 조회할 떄, id 값보다 변하지 않는 값으로 조회하자

  • id 값은, DB를 변경하거나, 극단적인 마이그레이션을 할 때, 변경될 여지가 있다고 한다.
  • 최대한 변하지 않는, 유니크한 값이 있다면 그걸로 조회하자!

21. 데이터베이스 테이블 인덱스를 잘 걸자!

  • 인덱스는 CUD의 성능을 어느정도 포기하고, READ의 성능을 대폭 올리겠다는 의미
  • 즉, 어떤 상황에 인덱스를 걸어야하나를 고민할 땐, READ가 많이 되는지 CUD가 많이 되는지도 중요한 포인트
  • 테이블 컬럼에 인덱스가 걸려있지 않다면 order by 시 , 전부 불러온 다음 인덱스를 주고 다시 정렬한다. (full scan 후 인덱스 테이블 자체 생성 -> 정렬)
  • 인덱스가 걸려있다면, order by로 불러올 때, 처음 조회 시 정렬된 상태로 조회
  • 인덱스가 잘못 걸려있다면(ex 정방향 인덱스 -> 역방향 인덱스 조회) 인덱스를 재구성하기 때문에 인덱스를 사용하는 의미가 많이 퇴색된다.
  •  Group by 도 가상의 테이블을 만들어서, join 하는 것이기에, 인덱스의 성능을 저하시키는 요소이다
  • 인덱스의 자원 소모 비교 👉 정렬 >>>>> 수정  (정렬할 때, 데이터베이스의 자원 소모가 극심하다고 한다)
  • 그리고 보통 수정보다 정렬(조회)가 훨씬 빈번하게 일어나기에,,, 정렬하는 조건에는 대부분 인덱스를 걸어준다고 한다.

22. 기차충돌은 지양하자  - 디미터의 법칙(캡슐화가 깨진다, 호출하는 쪽에서, 나만 알도록 - 호출하는 쪽에서,, 최대한 내가 뭘 가지고 있는지 모르게 (getter 도 이래서 지양) ) 


 

 

 

 

 

 

코드에서 나는 악취 - 사진출처 :&nbsp;https://targetcoders.com/%EC%BD%94%EB%93%9C%EC%8A%A4%EB%A9%9C-%EA%B2%BD%EA%B3%84/

 

참고

자바 네이밍 컨벤션 : https://m.blog.naver.com/reona7140/221306141987