일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 프로그래머스 레벨 2
- TCP
- 알고리즘
- 자바스크립트
- 문자열
- javascript
- 타입 챌린지
- 백준
- 쉬운 문제
- type challenge
- HTTP 완벽 가이드
- 타입스크립트
- 소켓
- 레벨 1
- dp
- BFS
- ip
- Nestjs
- 프로그래머스
- 크롤링
- socket
- HTTP
- 가천대
- Node.js
- Algorithm
- 그래프
- typescript
- Crawling
- 수학
- dfs
- Today
- Total
kakasoo
컨벤션을 어떻게 정하는가 / 팀을 돌아보며 본문
대학교 세미나를 진행하면서, 뒤풀이에서 질문을 받았다.
"카카수님은 변수 명이라던가, 컨벤션은 어떻게 정하나요?"
당연히 팀끼리 정하면 될 일이지만, 그런 답을 듣고 싶어서 질문한 것은 아닐 것이다.
나도 팀끼리, 그리고 회사에서도, 컨벤션을 정하고 작업한 적은 있지만 그게 잘 지켜진 적은 그다지 없었다.
사실 100번은 지켜도 1번 지켜지지 않은 게 있으면, 나중 가서 고치기도 심란하니 놔두게 되는 게 컨벤션 아닌가.
또 처음에는 열심히 하더라도, 점차 코드가 길어지면 컨벤션의 양도 늘어나게 되고,
그러다보면 컨벤션이 작업을 따라가는 게 아니라, 작업을 하기 위해 컨벤션을 봐야 하는 문제가 생긴다.
ex. "이것과 관련된 컨벤션이 어디 있더라?"
이미 만들어진 코드를 따라 하기
- 라이브러리와 프레임워크의 코드 따라 하기
그래서 내가 생각하기에, 최고의 컨벤션은 이미 만들어진 코드를 따라하는 것이다.
this.userRepository.find();
this.userRepository.createQueryBuilder('user').getMany();
TypeORM을 예로 들면,
이 두 코드는 각각 Repository와 QueryBuilder라는 패턴에서 사용 가능한 메서드, find와 get 함수들이다.
각각의 패턴에서는 데이터를 가져올 때는 반드시 이 단어들을 사용한다.
Repository의 메서드는 find, findOne, findOneOrFail, findByIds 등 find를 사용하고
QueryBuilder에서는 getOne, getMany, getRawOne, getRawMany, 이렇게 get을 사용해서 표현한다.
내가 생각한 최고의 컨벤션은, 컨벤션을 정하지 않고, 이미 있는 것을 따라 가는 것이다.
예컨대 커스텀해서 새로운 메서드를 만들 때,
그게 어느 정도 단계에서 추상화되는지에 따라 find나 get 중 하나를 선택하면 된다.
그래서 최종적으로 팀원들이,
"어? 이거, 라이브러리의 method인 줄 알았는데 카카수님이 만든 거였네?"
라고 착각하게 만드는 수준이 되는 것이, 내가 생각하는 가장 이상적인 컨벤션이다.
이게 왜 Nest.js 카테고리의 글이냐고 묻는다면, 이유는 우리 회사가 Nest.js를 사용하기 때문이다.
'프로그래밍 > NestJS' 카테고리의 다른 글
CannotExecuteNotConnectedError & medata was not found (0) | 2022.06.14 |
---|---|
Repository 최대한 예쁘게 써보기 ( 검색, 정렬, 필터링 ) (2) | 2022.06.11 |
node.js의 heap out of memory error (0) | 2022.06.07 |
cannot read properties of undefined ( reading 'launcher') (0) | 2022.06.07 |
nestjs/typeorm 0.3.x 적용 / Custom Repository가 안 된다고? (4) | 2022.06.02 |