팀 프로젝트를 하다보면 팀원과 의견이 다를 때가 많다. 당연한거다. 그 팀원은 자신의 방식대로 살아왔고 나는 나 방식대로 살아오면서 행동도 다르고 생각도 다르다. 이는 협업할 때 좋은 쪽으로 귀결될 수도 있으나 안 좋은 쪽으로 귀결될 수 있다. 좋지 않은 쪽으로 귀결되는 것을 막기 위해서는 팀원과 토론을 통해서 우리가 가야할 길을 정하는 것이 좋다.
토론을 통해 답을 정할 때도 많지만 그 토론이 치열해지고 팽팽해질 때가 많다. 그럴 때는 어떻게 해야할까? 겪었던 상황을 보며 살펴보자.
상황
팀원A와 나는 대면으로 코드리뷰를 하는 중이었다. 한가지 문제에서 토론이 시작했다. 일단 이번 프로젝트에서는 path와 query param을 통해 사용자에서 보여주는 컨텐츠와 사용자에게 주어지는 권한을 결정한다. 그리고 문제는 naviagte하는 코드에서 생겼다. 프로젝트에서 컨텐츠를 작성하고 페이지를 이동하는 로직이다.
const handleSubmit = () => {
// 제출로직...
navigate(`이동해야하는 uri`);
}이 이동해야하는 uri 를 결정하는 함수를 어떻게 작성하느냐에 대해 토론을 시작했다.
팀원 A는 route가 생길 때마다, 그에 대한 함수를 새로 작성하자고 의견을 냈다. 이에 대한 이유는 이 컨텐츠1uriBuilder 라는 함수는 한 번만 쓰이는 것이 아니라 여러 곳에서 쓰이고 path나 query string에 변경이 생긴다면 이 uriBuilder 라는 함수가 모여있는 파일로 와서 고치면 변경에 대해 쉽게 대처할 수 있다는 장점이 있다고 하였다. 일리 있는 말이다. path나 query string에 변경이 생긴다면 해당 uri로 navigate 하는 코드가 있는 컴포넌트 로직을 찾을 필요가 없는 장점이 있다.
const handleSubmit = () => {
// 제출로직...
navigate(컨텐츠1uribuilder(컨텐츠id));
}
// utils 파일
const 컨텐츠1uribuilder = (컨텐츠id) => {
return `/컨텐츠1/${컨텐츠1id}`
}
const 컨텐츠1수정uribuilder = (컨텐츠id) => {
return `/컨텐츠1/${컨텐츠1id}/eidt`
}이에 대해 나는 동감했지만 조금은 다른 생각을 가지고 있었다. 일단 path나 query string에 변경이 생길 경우는 적을 것이라고 생각했다. 그래서 저는 컨텐츠이름과 컨텐츠id를 key/value로 받아서 이를 navigate 할 uri로 변환해 주는 추상화된 함수를 작성했다. 이렇게 추상화된 함수로 작성하면 모든 navigate 하는 곳에서 사용할 수 있는 장점이 있으나 path나 query string에 변경이 생긴다면 해당하는 컴포넌트 로직으로 가서 변경을 하는 비용이 발생하는 문제가 있었다.
const handleSubmit = () => {
// 제출로직...
navigate(convertUri({
'컨텐츠1': 컨텐츠1id, 'edit': ''
}));
}
// utils 파일
const convertUri = (args) => {
// uri로 변환하는 코드
return 변환된uri
}서로의 의견을 피력하면서 토론은 팽팽해졌다. 각자의 의견은 각자의 장점과 단점을 가지고 있었고 주장하는 바도 정당한 이유가 있었다. 이럴 때 참 곤란하다. 결국 끝이 날 것 같지 않아 내가 양보하는 방향으로 코드를 작성하기로 했다. 우리의 공동의 목표는 프로젝트가 잘 진행되고 코드의 질을 높이는 것이지 자신의 코드만 적용되는 것은 아니기 때문입다. 내 코드가 프로덕션 코드에 반영되지 않아서 매우 아쉽지만 그래도 얻은 것은 많은 것 같다. 다음번에 비슷한 상황이 벌어지면 저번에 제가 양보했으니 이번에 팀원 A에게 양보해 줄 수 있냐고도 말할 수 있을 것 같다. 그리고 서로의 주장이 정당하다면 양보를 통해 공동의 목표로 빠르게 다가가는 것이 더 서로에게 이득이 되는 것을 알게 되는 계기가 되었다.
