코딩에 대한 나의 원칙 세우기 : crud 메서드 naming

어제 두 명의 개발자 친구들과 밥먹고 커피를 마시며 즐거운 시간을 보냈다.

한 친구가 회사의 과제 전형이 있어서 과제를 한 후 제출한 코드를 다른 친구가 보고 리뷰를 해주었다.

그 코드를 보고 리뷰를 해주는데, 같이 있는 나도 덩달아 배울 수 있었다.

일단은 어제 들은 얘기를 통해서 배우게 된 것은 다음과 같다.

• 배드 코드 vs 계층의 오염인 상황에서는 계층의 오염이 더 나쁘다.
  • 생각해보니깐 왜인지 안 물어봤다...;;
• 서비스 계층에서 값 검증을 했으면, 엔티티에서 값 검증을 할 필요는 굳이다.
  • 예를 들어 어떤 값을 조회할 때 클라이언트로부터 id를 받는다고 가정하자.
    • 컨트롤러 Request에 애너테이션으로 @Postive를 줄 것이다.
    • 그리고 해당 값이 양수로 검증된 후에 서비스 계층으로 올 것인데.. 이미 id가 양수인 것이 검증된 후에 서비스 계층으로 왔음에도 불구하고 서비스 계층에서 0 인지 음수인지에 대한 검증을 할 필요는 없다는 것이다.
  • 사실 검증 자체는 좋은 것이지만, 검증의 범위를 계속 늘리게 된다면, 리뷰해주는 친구가 말하기를 "극단적으로는 JDK 까지도 검증해야 된다"라고 했다.
  • 따라서 이미 검증에 대한 코드는 과감하게 그 코드에 맡기고, 다른 곳에 집중하는 것이 좋다.
• 자신만의 코딩 원칙이 있어야 한다.
  • 요즘 GPT의 활용이 늘다보니 코드를 그대로 쓰는 경우가 대다수이다... 아마 과제를 진행하던 친구도 그랬던 거 같다.
  • 그러다보니 늘 코드를 볼 때마다 다른 프로젝트마다 한 사람이 아니라, 다른 사람이 코드를 작성하는 것 같다는 느낌을 받았다고 한다.
  • 물론 GPT를 사용하는 것은 생산성 면에서 굉장히 뛰어나다. 그러나 코딩은 결국 그 사람의 원칙과 생각대로 하는 것이 맞는 거 같다고 생각한다고 하더라...
  • 그래서 코딩할 때 고민을 많이 해보고 자기 자신의 생각을 딱 정하고 가는 것을 해보라고 권장했다.

지금 생각나는 부분을 정리한 건 위와 같다.

어제 만난 분들이 서로 연락을 자주 하던 친구들이라, 각자의 사정을 디테일하게는 몰라도 어느 정도는 공유하면서 지내고 있다..

그래서 리뷰를 해주는 친구가 나에게 말하기를 "쌩수형 코딩 많이 해보셔야 합니다.."고 말했다...

사실 요즘 코딩을 많이 안 했다...

물론 API에 대한 코드를 작성하고, DB에 커넥션 맺고 엔티티 만들고, 참조맺고(아.. 맞다 나 요즘 참조 안 맺는다..)
그건 솔직히 쉽다...
Controller 만들고 DTO만들고 서비스 만들고 뭐 하고, 뭐 하고....
Test짜고..

코딩은 쉽다..
근데 좋은 코드를 작성하는 건 장담 못하는게 아니라, 그냥 아직 그런 레벨이 아니다...

모두가 다 그렇진 않지만, 막 개발을 시작하신 분들..아니 사실 내가...
CRUD에 대한 메서드명을 작성할 때, 어떨 때는 create 어떨 때는 save, 어떨 때는 add 를 쓰는 분이 아마 있을 것이다.

사실 이게 기분 따라 다르다..
처음엔 save로 작성했다가 맘에 안 들어서 create로 바꿀 때도 있고, 막 그렇다.

그리고 만약에 도메인이 두 개다.
예를 들어 상품과 주문이라고 치면
상품쪽에서는 createProduct 라고 했는데, 주문에서는 saveOrder라고 하면서 일관성이 없는 코드를 작성할 때도 있었다.

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 생각해보니 어이가 없어서.. 웃음이 난다..ㅋㅋㅋㅋㅋㅋ

여하튼 그와 관련해서 어제 리뷰해주던 친구가 해주던 말이 "자기 자신의 규칙을 정하고 가는 것이 좋다."라고 했다.

"이래서 컨벤션이 중요하구나.." 란 생각을 하기도 했다.
혹여 다음에 프로젝트를 하게 된다면 코드 컨벤션을 정하고 프로젝트를 진행해보고 싶다.

매번 내가 꼴리는 대로 했었다.
또한..리더가 있는 프로젝트를 하고 싶다..;;;

여하튼 그런 빌미로 나는 CRUD에 대한 나의 생각을 정해서 다음과 같이 정했다.

---

• register
  • CRUD의 C에 해당
  • ex)
    • registerUser / registerProduct / registerCartRequest(요청 DTO)
• modify
  • CRUD의 U에 해당
  • ex)
    • modifyUser / modifyProduct / modifyCartRequest(요청 DTO)
• retreive
  • CRUD의 R에 해당
  • ex)
    • retreiveUsers / retreiveUser
• remove
  • CRUD의 D에 해당
  • ex)
    • removeUser / removeProduct / removeCart

---

물론 프로젝트나 비즈니스에 따라 얼마든지 달라질 수도 있다고 생각하는 부분이지만,

왜 저렇게 작성하려고 하는지에 대한 내 생각은

물론 create, update, delete, get 등도 있고, 매핑에 대한 것으로 post, patch가 있을 수도 있지만,

일단은 RDB의 명령어와는 겹치지 않게 하고 싶었다.
그래서 위 4 가지를 정했고,

retreive 는 조회인데, 어제 얘기했던 친구는 불러온다는 의미로 그렇게 쓰는지는 모르겠지만, load로 한다고 했다.

그렇게 할까 하다가.. 그냥 막연히 따라하는 거 같아서 retreive로 했는데,
물론 찾다, 조회하다를 가진 영단어가 많긴한다.
그런데 디테일하게 보면 조금씩 그 의미가 다르다..

출근길에 막 생각하다가 영단어를 찾았는데, retreive는 찾다가 있으면 가져오고, 없으면 안 가져온다는 의미로 쓰인다는 글을 봤었다.
그래서 "아! 이거다!" 하고 이렇게 해야겠다고 생각을 하게 되었다.

조회할 때는 없을 수도 있고, 있으면 가져오는 게 딱 코드의 로직과 겹친다고 생각되었다.
그래서 retreive로 사용하기로 규칙을 정했다.

그래서 이를 일관성 있게 가져가고자 포스팅으로 정리를 해놓는다.

어제 만난 친구는 규칙을 지키기 위해 포스트잇에 적어놓고 모니터 옆에 붙여놨다고 하더라...
집요하게 대단한 친구라 자랑스럽다..

여하튼 이만 끝을 맺는다.