첫 회사에 들어와, 온보딩을 하면서 가장 많이 배우고, 아직도 어려운게
깨끗하게 코딩하고, 협업을 위해 규칙있게 코딩하는 방법이다
즉, 클린코딩,, 말로만하고, 글로만 읽는 클린코딩이 아니라
내 코드에 직접 적용하려니 헷갈리는게 이만저만이 아니었다.
그래서! 알아가고 있는 것을 기록하기위한 포스팅이다! (계속계속 추가할 예정)
목 록
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. 정적 팩토리 메소드 패턴의 사용
- 중요한 값은 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 도 이래서 지양) )
참고
자바 네이밍 컨벤션 : https://m.blog.naver.com/reona7140/221306141987
'Java > 클린 코딩 (with OOP)' 카테고리의 다른 글
5. JAVA 기본 타입 vs 참조 타입 (with 래퍼클래스를 사용해야할 때) ➡️ Integer(Wrapper Class) 보다 int(기본 타입) (0) | 2022.06.14 |
---|---|
4. 정규표현식이란, java 정규식 구성 및 가이드 + [JAVA에서 성능 높이기] (0) | 2022.06.11 |
2. 주석 사용 지양해야하는 이유 - 클린 코드 4장 (0) | 2022.06.07 |
1. 자바 네이밍 규칙 (java 네이밍 컨벤션) (5) | 2022.06.02 |
0. Google style convention 적용하기 (0) | 2022.06.01 |