새로운 기술을 사용할 때 주의해야 한다고 생각하는 것들

레퍼런스에서 시작해야 한다

각 기술이 보편적인 문제를 해결하는 방식은 레퍼런스에 담겨 있다. 이런 기반 지식에 익숙해지기 전에는 코드를 쓰면 안 된다. 가령 React로 처음 코드를 짠다고 할 때, state를 직접 조작하면 안 된다는 것 정도는 알고 나서 코드를 쓰기 시작해야 한다.

 

이런 기반 지식을 모르는 상태에서 코드를 쓰기 시작하면 일단 코드가 엄청 늘어난다. 문서에도 없는 버그들을 만나야 하고, 그것들을 땜질하느라 코드를 더 붙여야 한다. 레퍼런스를 읽은 사람이 이런 코드를 보면 일단 정신이 혼란해지고(...) 아예 새로 짤 각오를 하게 마련이다.

 

커뮤니케이션하는 것도 어려워진다. 가령 코드 리뷰에서 이렇게 말하는 사람이 있다면 레퍼런스를 읽은 입장에서 어떤 대답을 해줄 수 있을까?

 

리듀서에서 매번 새로운 state 객체를 생성하는 게 마음에 안 들어서 기존 state를 조작하는 방식으로 일단 짰어요.

 

나라면 useReducer를 쓰지 말고 React도 쓰지 말라고 할 것이다. 어떤 기술의 기본 철학이 마음에 들지 않으면 다른 기술을 도입할 생각을 하는 것이 합리적이다. 반대로 그 기술을 써야만 하는 상황이라면, 그 기술의 레퍼런스를 읽고 따라야 할 것이다. 이게 협상과 설득의 대상이 되면 안 된다. 레퍼런스 위에서 얘기를 하자.

 

적은 코드에서 시작해야 한다

레퍼런스와 컨벤션을 위반하면서 번다하게 쓴 코드들은 으레 일단 돌아간다는 이유로 용인되고는 한다. 그런 코드 치고 진짜 잘 돌아가는 경우는 별로 없다. 돌아가는 코드를 쓴 뒤에 그것을 가꿔나간다는 계획은 좋지만, 그 돌아가는 코드는 헐렁한 코드가 아니라 최소한의 코드를 의미하는 것일 테다.

 

수시로 불필요한 코드를 지우고, 안 쓰는 prop을 정리하고, 코드를 줄일 수 있는 아이디어를 레퍼런스에서 찾아보아야 한다. 가능한 한 적은 코드로 문제를 해결하기 위해 노력하는 건 언제든 필요하다고 생각한다.

 

많이 물어봐야 한다

커뮤니티과 주변 동료 둘 중에 하나는 붙잡고 물어보고 있어야 한다. 특히 주변 동료에게 많이 물어보는 것은 싱크를 맞추는 측면에서도 중요하다고 생각한다.

 

붙잡고 물어보는 게 미안해서 하지 못하는 성격일 수도 있다. 하지만 지금 물어보지 않으면 나중에 결국 PR로 응답해야 하고, 수많은 피드백을 남기고 번아웃된 동료에게 머지를 부탁해야 한다. 왜 전자가 후자보다 더 미안한 건지 잘 모르겠다. 후자의 상황까지 몰고 가면 안 된다.

 

디펜스를 낮추자

새로운 기술에는 새로운 문제 해결 방식이 존재할 수가 있고, 실력이 있거나 연차가 높다고 해서 그걸 빨리 알아내지는 않는 것 같다. 그러니 기본적으로 코드 리뷰에서 컨벤션 위반, 레퍼런스 위반된 부분의 피드백을 받으면, 디펜스하기 전에 제안된 방법을 검토하는 게 우선이라고 생각한다.

 

특히 "아 이건 이런 부분인데요" 하면서 비즈니스 로직을 줄줄 설명하는 행위는 신중해야 한다고 생각한다. (그런 설명이 필요한 로직이라면 리뷰어가 먼저 물어올 것이다. "이거 뭐예요...?") 이런 질답이 몇 번씩 반복되면 리뷰어의 힘이 빠질 수가 있으므로 명백히 비즈니스 로직과 상충되는 피드백이 아니라면, 일단 검토해 보거나 재질문을 하는 게 더 좋다고 생각한다.