[3주차] Clean_Code_5-6장_이준렬

[lee-JunR]

Q1

---

5장의 '코딩 형식과 팀 규칙' 부분을 읽으며 생각난 질문이 있습니다!

부끄럽지만 저는 이전에 프로젝트의 코딩 컨벤션에 대한 회의를 할때, "네이버 (또는) 구글의 코딩 컨벤션 포멧터를 사용합시다"라는 결정을 하고
아 코딩컨벤션을 지키는 나는야 멋진 개발자 😊
라는 뽕에 취했었습니다.

그러나 5장을 읽고 나서, 그냥 IDE에 해당 포멧터를 정해 적용하고 cmd + option + L 단축키로 처리했던 저의 행동이 반쪽짜리 컨벤션 규칙 설정이었다는 것을 깨달았습니다!

즉, 프로젝트를 시작할 때 IDE에서 제공하는 코딩 스타일외에 따로 정해야될 코딩 컨벤션 규칙에는 어떤 것들이 있을까요?

제 생각에는, 사용자 정보가 담긴 변수를 'users'라고 할지, 'userList'라고 할지 결정하는 것이 하나의 예가 될 수 있을 것 같습니다!

[GaHee99]

개인적으로 아래 것들이 '최소로' 지켜야할 코딩 컨벤션 같아요

1. CRUD에 대한 함수 코딩컨벤션 지키기
   (굉장히 혼동스러웠음)
   update일 API경우, update___() or edit___()등 굉장히 많더라구요,
   그래서 저는 협헙할 때 CRUD함수에 대한 코딩컨벤션을 지키고 하는 편이에요!

메소드명 통일

create ,delete ,update , get
이런식으로, 컨벤션을 지키려고 했던 것 같아요!

2. 단어에 대한 코딩 컨벤션 지키기,
   서버의 경우, 거의 테이블 명으로 개념들이 정해지지만,, 진짜 애매한?것들이 있더라구요,
   지금 생각나는 예로는
   스크랩 기능의 경우,
   (bookmark, scrap)등 다양하더라구요,~
   이런 부분을 지키려고 합니다..

3. dto 명명 형식
   api 하나만들 때 다양한 정보를 갖고 있는 api경우, 이름 짓기가 진짜 만만치 않은 것 같아요,

최근에 진행했던 api중에는,
게시글 상세보기 - 댓글, 대댓글 등
다양한 정보가 포함됐었습니다. 하나의 response안에 다양한 객체를 통해서 데이터를 전달하다보니, 자연스럽게 DTO class도 많아졌는데요..!
이 부분도 1번과 비슷하게 CRUD관련하여 DTO파일명을 컨벤션에 맞게 잘 작성하고, 또한 VO인지 DTO인지도 (response계층도)도 정하면 좋을 것 같다고 생각했습니다.!

• API 일부 예시 (물론 이 response가 최적의 response인지는 확실치 않은 것 같아요 하하~)

4. 폴더링 컨벤션
   서버 프로젝트를 진행하다보니, 외부api나 common으로 선언할 부분 등 진짜 애매하게?~ (클래스파일)을 넣어야 할지 고민인 지점들이 생기는 것 같아요, 한번 정해진 폴더는 물론 폴더 위치를 바꿀 수 있긴 하지만 동료 팀원들도 해당 폴더를 넣었을 때 '당연히 여기에 있겠지?' 생각이 들만한 폴더로 클래스를 이동해야 하기 때문에..
   이 부분은 정말로 팀적인 합의가 필요하다고 생각했습니다 ㅋㅋㅋ 저는 그래서 pr올릴 때 항상 폴더위치 어떻냐고 여쭤보는 편이에요!

• 폴더링 예시,, 정말 x100000 정답이 아닙니다.

등등,, 위에는 최소한의 영역이고 협업하다보면 무수히 많은 것 같슴다..

---

변수명에 자료구조를 표기하지 않는편이 좋다고 클린코드 앞장에서 읽은 것 같아요 ㅋㅋ
하하 그래서,, 저는 요즘에 자료구조는 규칙에 포함하지 않고 있긴합니다.!

[find11570]

저와 같은 경우에는 먼저 ESLint, Prettier를 사용하여 환경을 맞춰줬습니다.
상수는 영문 대문자, 스네이크 표기법을 사용하여 표기하였습니다.
변수와 함수 모두 카멜 케이스를 사용하였고, 컴포넌트 이름인 경우에는 파스칼 케이스를 사용하여 네이밍 하였습니다.
가희님이 말씀하신대로 CRUD의 함수 네이밍과 자주 사용되는 함수에 대한 네이밍 규칙도 정했습니다.
이건 front 에만 있을 것 같은데, 저는 함수를 사용할 때 형식이 통일되지 않는 것이 지저분해보여서 화살표 함수로 통일하여 사용하였습니다.
https://myung-ho.tistory.com/100 이 분이 작성하신 것과 거의 동일하였고 그 이외에는 프로젝트 별 데이터나 네이밍 규칙, 가이드에 따라 추가 적용하여 구현 개발을 하였던 것 같습니다. 맞출게 너무 많은 것 같아요.. 그래서 중간에 합류하게 되면 기존 코드를 제일 많이 참고합니다.. << 좋던 안좋던,,, ㅜ

[chuseok]

Q1

좋지 않은 예제이긴 한데
클래스에 변수가 많아서 들여쓰기를

private String optime    = "어쩌구";
private String opmanCode = "저쩌구";

이렇게 사용하기로 규칙을 정하고 시작했던 경험이 있습니다.
팀에서 정한 규칙이여서 사용하긴 했지만 사용하기 불편하다고 느꼈는데 책을 읽고나서야 잘못 됐다는걸 알고 반성했네요..!

그리고
errorCode는 GlobalExceptionHandler에서 정의해서 사용하자 와 같이 규칙을 정하고
한 명이 틀을 만들어서 올리면 사용하는 형식으로 진행했습니다!

@Getter
@AllArgsConstructor
public enum ErrorCode {
    INTERNAL_SERVER_ERROR(501, "SERVER-001", "서버가 요청을 처리할 수 없는 경우"),
    TEST_ERROR(501, "SERVER-001", "서버가 요청을 처리할 수 없는 경우"),
    WORK_NOT_FOUND(404, "SERVER-002", "존재하지 않는 작업입니다."),
    ALREADY_SAVED_WORK(409, "SERVER-005", "이미 사용중인 공정입니다."),
    ...

또한 팀 규칙 중에서 제가 가장 중요하게 생각하는 것은 위에 가희님이 말씀해주신 것 처럼 폴더 패키지명을 정해놓고 시작하는 것이 개인적으로 좋다고 생각합니다. (개인적인 생각이니 참고만 해주세요,,)