코드 리뷰 정리

이제 개발자로 밥 벌어먹은지 1년이 다 돼간다. 

아직 회사 master branch에 직접 수정할 수 있는 권한은 없기 때문에 사소한 수정이라도 PR을 올려야한다. 그 과정에서 자연스럽게 코드리뷰를 받게 되는데 그 내용들을 정리하려고 한다.

이 글을 보는분들은 나와같은 실수를 하지 않았으면 한다. 물론 이 글이 무조건 정답이 아니기 때문에 알아서 걸러서 참고 된다.

 

타입추론이 되는 변수는 타입을 작성하지 말자

let isLoading: boolean = false;

 

TS를 사용하는 입장에서 TS의 강력한 기능중에 자동으로 TS에서 타입추론을 해준다는 점이다. 

변수의 경우 초기값을 할당하는 경우 타입추론을 통해 타입이 지정되기 때문에 굳이 작성할 필요는 없다. 

 

이 경우 팀바팀이라고 생각한다. 타입을 작성하던 하지 않던 번들링 한 결과는 똑같아 성능에 차이는 없고 팀마다 다르게 적용하면 되는 부분같다.

 

변수 이름은 신경 써서 작성하자

https://frontend-minto.tistory.com/11

변수, 함수, 타입 이름 작성에 대한 고민

 

적절한 변수를 작성하는법에 대해서 내가 정리한 글이다. 

이 부분에서 많은 피드백과 적절한 이름을 짓기위해 시간을 많이 소모했었다. 

솔직히 시간이 많이 모자른 상황에서는 변수명을 짓기 위해 많은 시간을 소모할 수 없지만 나중에 팀적으로 봤을때 비용을 많이 줄여주고 조금 더 안정적인 서비스를 만들 수 있기 때문에 중요한 부분이다. 

 

좋은 변수명은 도메인에 대한 이해와 경험 그리고 평소에 제3자 입장에서 생각하면서 변수명을 짓는 습관이 제일 중요한거 같다.

 

모노레포에서 공통으로 사용하는 UI 컴포넌트의 경우 내부에 어떤 로직도 포함하지 않도록 만들자

 

여러 도메인을 하나의 레포에서 개발하는 모노레포 특성상 여러 도메인에서 공통으로 사용하는 UI 요소가 굉장히 많다. 

이런 경우 부모로부터 받은 값을 그대로 UI로 렌더링하도록 작성된 컴포넌트가 가장 사용하기에 부담이 없는 컴포넌트인거 같다. 

외부에 의존을 하고 다른 컴포넌트에게도 영향을 주는 컴포넌트의 경우 수정하기에도 부담스럽고 수정하려면 해당 컴포넌트와 유기적으로 연결된 모든 부분을 확인해야하니 좋지 않다. 

이를 위해 컴포넌트를 설계할 때 본연의 UI 렌더링에만 초점을 맞춘 컴포넌트의 경우 내부에 어떠한 로직도 수행하지 않게 작성하는게 중요하다. 

 

예를들어 내부에 라우팅 하는 경로조차도 내부 컴포넌트에 독립적으로 선언된게 아닌 부모로부터 경로를 받아와서 그 경로만 클릭으로 이동되도록 작성하는게 좋다. 

 

템플릿 html 파일에서 복잡한 로직은 작성하지 않는게 좋다.

 

Angular나 React나 모두 html에 특정 로직 작성할 수 있다. 대표적으로 삼항 연산자를 통해 특정 조건일 때 UI를 렌더링하라고 작성할 수 있다. 

하지만 삼항 연산자가 중복해서 사용된 경우 로직의 길이가 길어져 코드가 지저분해 보일 수 있다. 

 

이 부분은 중요하다고 생각이 드는게 html 코드가 길어질 경우 내부에 복잡한 로직에 의해 UI가 렌더링 되는경우 코드를 파악할 때 조금 더 어려움이 있고 왠지 읽기 싫다는 생각이 들었기 때문에 필요이상으로 템플릿 코드에 로직을 길게 작성하지 않는게 중요한것 같다.

 

이 글은 완성된 글이 아니라 계속 이어서 내용을 채워나갈 생각이다.