바닐라코딩 부트캠프 5주차 후기

바닐라코딩을 시작한지 5주가 지났다. 4주차는 test 및 break 주간이라 따로 후기를 쓰지 않았고, React를 배우고 github 배틀 과제를 했던 5주차 후기를 작성한다.

 

부트캠프에서 React를 배운다는 점은 이미 알고 있었던터라, 많이 연습하고 들어오고 싶었는데 사실 React는 만족할만큼 충분히 예습하고 들어오진 못했었다. 게다가 나는 Class 기반 Component로 진행되는 강의를 들었던지라, ken 님이 알려주셨던 함수형 Component가 좀 생소해서 어려움이 있었다. 공식문서를 최대한 꼼꼼히 읽으면서 하나 둘 이해하고 있지만 아직 많이 부족하다고 느껴진다.

 

게다가 테스트 코드도 처음으로 작성해봤는데, 마치 1주차 과제에서 each를 맞닥뜨린 것 같은 느낌이었다. 아는 사람은 아는 그 each의 기분... jest는 뭔지, jest-enzyme은 또 뭔지, 이 문법들은 다 뭐고 도대체 무엇을 테스트해야 할지 전혀 감을 못 잡으며 하루를 허비하기도 했다..

 

5주차 피드백 정리

[ 개선점 피드백 ]

• 3항 연산자를 두가지 이상 중첩해야 할 경우, 괄호 등을 통해 구분해주어야 가독성에 좋다. 하지만 3항 연산자로 코드를 짧게 쓰는 것보다 더 중요한 것은 가독성이기 때문에 장단점을 비교해 더 적합한 방식을 쓰면 좋다. => 100% 맞는 말씀! 내가 왜 3항 연산자가 여러 개 중첩된 코드를 쓰게 됐는지, 얻은 교훈은 무엇이었는지는 아래에서 좀 더 자세하게 작성한다.
• 고정된 string value는 상수로 관리해줘야 유지보수에 좋다. => 지난 과제에서 들었던 피드백인데 적용을 못했다. 에러 메세지이든, input 받는 데이터의 key이든 고정된 value일 경우에는 const를 이용해 대문자로 상수처리 해줬어야 했는데 세심하지 못했다. 아예 코드를 작성할 때 이 부분 생각조차 못 했었기 때문에 아직 내게 습관이 충분히 되지 못한 듯 하다. 이번이 두 번째로 받은 피드백이니 다음주 과제부터는 반드시 반드시 적용해야겠다...
• 하위 컴포넌트로 갈 수록 비즈니스 로직과 관련이 없어야 한다. => 이번주 피드백에서 가장 큰 교훈이었다. 사실 컴포넌트가 하위로 갈수록 점점 더 단순한 기능(단순히 props를 전달받아서 화면에 보여주는 등..)만 가지게 되기 마련이다. 그런데 내 컴포넌트 중 가장 하위 컴포넌트에서 input받은 데이터의 값에 따라서 형태를 변환해주는 로직이 포함되어 있었다. 이 부분을 상위 컴포넌트에서 해결하고 변환된 값을 가장 하위 컴포넌트에 props의 형태로 전달해줬으면 더 단순하고, 재사용성이 높은 하위 컴포넌트가 됐을 것 같다. 이 부분은 몰랐던 부분이라 꼭 잘 기억해야겠다!
• 반복적으로 사용되는 컴포넌트에는 key가 있어야 한다. 그리고 map을 활용해서 반복해라. => 이 부분 이번 과제에서 찜찜한 부분이었는데 역시나 지적해주셨다. 이건 100% 내가 refactoring이 부족했던 부분이라.. 할 말이 없다. 다만 다음주 과제부터는 무조건.. 무조건.. 적용하는 것으로...

 

# 논리와 구조에 대한 고민

3항 연산자가 중첩될 수 밖에 없었던 이유를 '논리와 구조'의 측면에서 정리하고자 한다.

 

논리, 구조는 바닐라코딩 부트캠프 시작부터 '다음 과제에서는 더 나아져야지..!'라고 다짐했지만, 현실은 매번 아쉬움이 남는 부분이었다. 왜 매주 아쉬움이 남았을까. 그렇다고 내가 과제를 받으면 무조건 덥썩 손부터 나가는 타입은 아니다. 매 과제마다 목표를 달성하기 위해 어떻게 구조를 만들어야 할지 틀을 잡고 시작했었다. 하지만 그럼에도 예상치 못한 예외가 항상 발생하고, 그 때마다 기존 구조에 조금씩 덧붙이다 보니 최초의 깔끔한 구조가 더럽혀지게 된다. 이번에 삼항 연산자가 중첩된 이유도 이와 같다.

 

왜 매주 논리와 구조에 대한 아쉬움이 남는지 곰곰히 생각해봤다. 결론은 '조급함' 때문이다. '누가 쪼는 것도 아닌데 왜 조급해?'라고 생각할 수 있지만 학원에 있다보면 매일 평온한 마음가짐을 가지기는 쉽지 않다. 결국 꼼꼼히 구조를 짜고 시작하는 것이 최종적으로는 시간을 아낀다는 점을 나도 잘 알지만, 여기저기서 이것저것 만들어내는 모습이 보이고, 그러한 이야기가 귀에 들리면 마음이 무작정 평온할 수만은 없다.😂 '나도 이제 얼른 코드로 옮겨야 되려나?' 같은 생각이 스멀스멀 피어나고, '그래 이 정도 구조 짰으면 이제 코드로 옮겨도 되겠다!' 같은 생각으로 합리화를 하게 된다.

 

조급함은 함께 공부하는 분들 말고도, 내 마음 속에서도 스스로 피어난다. 내 마음속에서는 '할 것이 너무 많다.'는 생각이 조급함을 촉발하는 주요한 요인이 된다. 예를 들어 이번 과제에서는 테스트 코드도 작성해봐야 한다는 사실이 나를 꽤 부담스럽게 했다. '한 번도 해본 적이 없는데 잘 쓸 수 있을까?', '테스트 코드를 쓰려면 뭐부터 해야하지? 얼른 공부해야겠다.' 같은 생각이 들면 자연스레 조급해지기 시작하고, 그러다보면 자꾸 구조를 등한시하고 빨리 눈에 보이는 코드로 옮기고 싶은 생각이 앞선다.

 

코드에서는 에러가 나면 debugging을 해서 에러의 원인을 찾아내고, 해결방법을 찾으면 해결된다. 그런데 사람의 심리에 대해서는 해답이 없다. 그래서 나도 이 문제에 어떤 해답이 있는지 잘 모르겠다. 그냥 '조급해하지 말고 충분히 꼼꼼한 구조라고 생각할만큼 더 깊게 고민해!' 같은 다짐은 맞는 말이지만 내가 그것을 몰라서 그랬던 건 아니니까.

 

다만 내가 '조급함'을 가지고 있다는 것을 인지하는 것이 해결의 시발점이지 않을까 싶다. 원대한 서사로 시작해서 시시한 결론으로 끝나는 영화같은 글이지만, 무슨 해결방법이라고 쓸만한 것이 없는 것 같다. '조급함'이 있다는 것을 인지하고, 조급해한다고 느껴질 때는 잠시 카페같은 곳으로 장소를 옮겨서 혼자만의 시간을 가져보거나.. 해야하지 않을까 라고 막연히 생각하는 내용으로.. 5주차 후기를 마쳐본다.🤣

 

이 모든게 좋은 개발자가 되어가는 성장의 발판이려니 해야지..!