웹서핑하다가 저와 비슷한 생각을 하고 있는 블로거의 포스트를 읽게되어 좋은 내용인 것 같아 번역해보았어요.
여기에 있는 내용은 꼭 리액트에 국한되어있는것은 아니니 지나가다가 읽어보시면 좋을 것 같습니다.
저는 React 에는, Anti-pattern 은 있어도 Best Practice 는 존재하지 않아야 한다고 생각해요 개발자 개개인마다 문제를 해결하는 방법이 다르고, 코딩하는 스타일도 다르기 때문이에요. 저는 리액트는 개발자로 하여금 매우 높은 자유도를 주는 라이브러리라고 생각해요. 한가지 문제라고 하더라도 그걸 해결하는 방법이 여러개고, 그 중 자신이 가장 마음에 드는 방식으로 해결하면 되니까요.
리액트를 하다보면 자주 생각하게 되는 질문이, 내가 과연 지금 제대로 하고 있는건가..? 입니다. 거기에 대한 답변은, 일단 자신이 생각하기에 가장 최적의 방법으로 진행해보세요. 계속해서 꾸준히 개발을 진행하면 서서히 개선해야 할 부분도 보이고 그렇게 고쳐나가다보면 여러분 자신에게 딱 맞춰진 편안한 구조, 스타일, 틀이 만들어질것입니다.
원본 포스트는 jakblind님의 4 questions to ask yourself when you get stuck with React 입니다.
다음 리액트를 사용하다가 흔히 봉착하게 되는 몇가지 문제들이 있는데요.. 다음 질문들을 한번 살펴보세요
Q. State 는 어디에 담아야할까?
React Component 의 State 를 사용하거나.. Redux 를 사용하거나.. MobX 를 사용하거나.. 아니면..
Q. 로직은 어디에 작성해야할까?
Container 컴포넌트에 넣거나.. Action 생성자에 넣거나.. util, libs 를 사용하거나 아니면..
Q. 테스팅은 어떻게 해야할까?
Assertion 을 사용하거나, stubs 를 사용하거나, Spy 를 사용하거나, Test Runner 를 사용하거나..
반복되는 패턴이 보이시나요? 각 문제들마다 여러가지의 해결 방법이 존재합니다.
어떤 해결방법을 골라야할까요? 이상적으로는.. 그 중 하나만 골라야 하겠죠, 하지만 여러분에게는 정말 많은 선택권이 주어져있고 어떤상황에서 뭘 쓰는게 좋을지 모릅니다.
그래서 여러분은 헷갈리기 시작하고.. 결국엔 막히죠.
가끔씩은 여러분이 겪고 있는 문제가 흔한 문제임에도 불구하고 딱 정해진 방법이 없을때도있어요.
“파일 구조는 어떻게 해야할까?” 여러분 마음대로 하세요
“내가 필요한 최소한의 도구는 어떤것들이 있을까?” 케바케입니다.
음.. 딱히 도움되는 답변은 아니지요?
우리가 원하는건, 간단하고 명료한, 원칙적인 해결방법인데, 리액트 생태계에선.. 그런게 없습니다. 그러면.. 어떡할까요?
포기해요?
여러분 자신에게 질문을 하는것이 중요해요
여러분이 프로젝트 진행을 하게 됐을 때, 문제를 겪게 되면, 여러분 자신에게 질문을 물어보세요. “어떻게 하면 이 문제를 가장 적절하고 올바른 방법으로 해결 할 수 있을까?”
이 질문은 여러분을 올바른길로 인도해주고, 문제를 해결 해 줄 때도 있겠지만, 가끔씩은 오히려 혼란스러움을 초래합니다.
무슨 답을 하는가보다는 무슨 질문을 하는가에 의해 사람을 판단하라 – 프랑스의 사상가 볼테르
현실은 복잡하고, 이럴 때 해답을 찾기위해서는 다양한 각도로 문제를 바라봐야합니다.
그 방법은, 바로 여러분 자신에게 여러가지 질문을 물어보는 거예요. 자, 여기 예시를 드릴게요
1. “내가 할 수 있는 가장 간단한 방법이 뭐지?”
가끔씩은 Ajax Request 를 하기위해서 Redux Store 와 Thunk 미들웨어를 사용한 액션설정이 필요할때도있습니다.
그리고 가끔씩은 4줄짜리 Form 태그로도 충분할수도 있어요.
무조건 멋지고 ‘정확한’ 답을 찾으려고하지마세요, 그 대신에 잠깐 멈춰서 여러분이 가장 간단하게 해결 할 수 있는방법을 고려해보세요. 간단한 해결법은 더욱 유지보수하기 쉽고, 버그가 발생할 확률이 적고, 또 명쾌한건 둘째치고 가장 빨리 구현할수있습니다.
2. “내가 해결해야하는 문제가 뭐지?”
- 성능에 관련된 문제인가?
- 시장에 출시하기 위해 개발시간이 중요한 요소인가?
- Proof Of Concept (개념증명) 인가?
- 내부에서 사용되는 도구인가?
- 공부용인가?
만약에 공부용으로 진행하는 프로젝트라면, 같은 기능을 위해 2~3개정도의 다른방향의 시도를 해보세요.
그렇게 비교하고, 경험해보세요. 만약에 시장출시가 급하다면, 가장 빠른 방식으로 구현하세요. 그게 방법이 설령 “틀렸다” 할 지라도요.
3. 내 팀원들은 어떤 능력들을 갖고 있지?
주니어개발자들이 많나요? 시니어 개발자만 있나요? 만약에 당신이 개발자를 더 모집한다면 그들의 프로필은 어때야 할까요? 이 부분은 신중하게 고려해야합니다. 왜냐하면 이는 여러분의 코드가 가질 “스마트함” 과 창의성과 관련 될 수 있기 때문이에요.
4. “지금 결정을 내리고, 나중에 다시 봐도 될까?”
가끔씩은 문제를 어느정도 해결할 수 있을 정도로만 코드를 짜놓고, 나중에 더 개선하는것이 가장 좋을 때도 있습니다.
만약에 여러분들이 작업을 하는데 모든걸 처음부터 완벽하게 해결하려고 노력한다면, 오버엔지니어링을 하게 될 가능성이 있고, 코드가 보다 더 복잡해질 위험이 있습니다.
여러분은 그 코드가 앞으로 어떻게 사용 될 지 예상하기 힘듭니다. 여러분이 생각했던것보다 규모가 커지지 않을수도 있고, 해당기능이 여러분들의 서비스에서 한달 안에 사라져버릴수도 있습니다. (나는 이런걸 많이 겪었어요)
하지만, 이 생각은 적당한 선에서만 하세요! 그렇다고해서 모든걸 대충하고 넘기면 나중에 quick fix 를 하는데 시간이 너무 많이 소비될지도 모릅니다. 적당한 밸런스를 맞추세요.
마치면서..
여러분들이 만드는 각 어플리케이션들은 하나하나 다르기 때문에, 무조건 일반화된 솔류션을 선택하는게 언제나 최선의 방법이 아닐지도 모릅니다. 여러분들의 어플리케이션에 있는 문제점들을 해결법을 찾기위해선 단순히 공식 문서 및 튜토리얼들 그 이상으로 생각을 해봐야합니다.
이렇게 변수에 따라 고려를 해가면서 여러분들의 상황에 딱 적합한 솔루션을 찾아 진행을하시면 더욱 가독성이 높고 유지보수하기 쉬운 코드를 작성 할 수 있을거예요.
그렇게 개발해서 유저의 수도 늘어나면 행복하겠죠!
포스트 끝
개발을 하다보면 내가 하는 방식이 과연 최선의 방식인가? 남들은 이렇게 안하고 있는 것 같은데… 라는 생각이 들 때가 있습니다. 만약에 그 시점에서 자신이 이게 최선의 방식이라고 생각된다면, 그게 여러분에겐 바로 올바른 해결방안입니다. 하지만 물론 시간이 지나고나면, 가끔씩은 아! 이 때 했던걸 더 제대로 할 수도 있었구나! 라고 깨닫게 될 때도 많습니다. 그렇다고 그전에 만든 해결방안이 틀린건 아닙니다. 그 부분은, 개선하면 됩니다. 여기서 중요한점은, 그렇게 계속해서 발전해나가면서, 개발자로서 더더욱 성장하는것입니다.