시도하기 전에는 당신이 무엇을 할 수 있는지 결코 알 수 없다. - 윌리엄 코베트
해보지 않으면 알 수가 없다
나의 첫 리액트 프로젝트, 시작하기 전에는 느낄 수 없었던 것들이 프로젝트가 어느정도 궤도에 오르니 보이기 시작했다.
백문이 불여일견이고 백견이 불여일행이라
역시 한번 해보는 것만큼 좋은 경험과 배움은 없는 것 같다.
이번에 배웠던 것들을 다음번에는 잘 써먹을 수 있게 하기위해서 기럭을 남겨본다.
늘 협업을 중점에 두자
스스로 위대해질 수 있는 사람은 없다.
프로그래밍을 할 때 협업이 가장 중요한 이유는 프로그램은 혼자 만들 수 없기 때문이다.
간단한 쉘을 만들거나 예제 프로그램을 만드는 것은 혼자서 할 수 있을지 몰라도 이렇게 누군가에게 제공해야되는 서비스를 제작할 때 혼자하는 것은 거의 불가능하다.
프론트 팀은 그래도 어느정도 협업에 대해 신경을 쓰고 코딩을 했다고 생각했지만, 나중에 보니 사실 그렇지 못했다.
우리는 CamalCase 그리고 컴포넌트/페이지로 구분해서 관리하는 방법을 정하고 이 방법대로 코딩했지만, 이는 충분하지 않았다.
우선, Components에 우리가 만든 모든 jsx파일을 밀어 넣음으로써 이 컴포넌트들은 어디에서나 쓸 수 있는 인상을 주었다.
이렇게 함으로써 컴포넌트 간의 의존성을 정확하게 인지시킬 수 없었고, 제작된 컴포넌트들의 이름은 충분히 명확하지 않았다.
만약 바로 옆에서 코드를 친 동료에게 물을 수 없는 상황이라면 읽는 이에게 혼란을 주기에 충분한 네이밍 및 관리방식이었다.
우리는 개발을 함에 있어서 LiveShare 방식을 취했기 때문에 즉각적인 소통이 가능해 실수하지 않을 수 있었지만 앞으로 모든 코딩을 LiveShare로 할 수 없지 않은가?
나와 우리팀원 주한님은 둘 다 리액트 초보였고, 그렇기 때문에 하나하나 물어가며 공부하는 과정을 이어나갈 수 있었다.
비슷한 수준의 팀원과 하나하나 지식을 쌓아나간다는 것은 매우 큰 행운이라고 생각한다. 만약 나보다 못하는 사람이거나 나보다 잘하는 사람이라면 '이거 물어봐도 괜찮을까?'라는 생각으로 코딩할 수 없었을지도 모른다.
우리는 비슷한 수준이었기 때문에 서로에게 묻는 비용이 적었고, 덕분에 리액트 시작부터 공부 - 4개 페이지 개발까지 1주일 안에 끝낼 수 있었다.
과연 이번같은 행운이 또 있을 수 있을까? 나는 그럴 수 없다고 확신한다.(이런식으로 다 할 수 있었다면 github가 왜 있겠는가?)
코드는 어떻 작성해야되는가?
코딩 규약의 중요성
다음번에는 이번처럼 LiveShare로 같이 코딩하는 행운이 없을 것이라고 생각해야겠다.
이번에 할 때는 학습과 병행했기에 너무나도 좋은 방법이었지만 생산성은 그렇게까지 높지 않았다.
이번에는 우리가 하나하나 배우면서 서비스를 만들어나갔기에 그런 것일 수도 있지만 과연 월급주는 회사에서도 이런 상황을 받아들여줄까? 내가 사장이어도 이런 방식으로 협업하는 개발자는 환영하지 않을 것 같다.
GitHub 그리고 PeerReview
왜 선배 개발자들이 주니어는 돈을 좇기보다는 PR을 잘해주는 회사로 가라고 조언해주는지 정확하게 알았다.
PeerReview, 해보니까 너무나도 어렵다. 다른이의 코드를 읽고 이해하는 것은 내 코드 치는 것만큼의 노력을 내게 요구했다.
왜 우리의 PR은 어려웠을까 생각해보면, 네이밍에 있어서 내공이 부족했다. 그리고 리액트의 depth을 다룸에 있어서도 부족한 내공이 우리의 리뷰들을 방해했다.
우리가 사용한 변수들은 2번 생각해야 어떻게 사용하는 것인지 알 수 있었고, 가끔 작성한 리액트 코드들의 depth는 너무 깊어 한눈에 이게 어떤 내용인지 알아보기 쉽지 않았다.
왜 변수 네이밍 그리고 한눈에 보이는 코드가 중요한 것인지 알 수 있었던 대목이다.
누군가가 알아보지 못하는 코드는 1주일 후의 나도 알아보지 못한다.
알아보지 못하면 관리할 수 없다. 그런 코드는 좋은 코드가 아니다.
다음에는 이렇게 해보자!
1차적으로 릴리즈 후 멘토 소플님께 멘토링을 받으면서 받았던 조언을 바탕으로 나는 많은 것들을 깨달았다.
1. 컴포넌트들은 폴더별로 분리하여 컴포넌트의 의존성을 명확하게 명시하자
- Table 내부에 쓰는 Component는 Table에서만 쓸 수 있도록 구분해서 보관하자
2. 중요한 내용들은 .env에 보관하여 관리하자
- 이번에는 zustand상태에 다 밀어넣어놨었다
3. 공백을 잘 활용하자
- 90년대 컴퓨터가 아니다! 이제는 동료가 잘 볼 수 있도록 코딩하자
- 중요한 것은 공백, 빈줄 줄이기가 아닌 동료가 잘 알아볼 수 있는 코드다
4. Import를 할 때에도 잘보이게 하자!
- 비슷한 출처를 가진녀석들을 모아서 import하자
- 컴포넌트 사이즈가 큰 것부터 순서대로 import하자
5. function 하나를 쓰더라도 어떻게 작성할 것인지 정해놓자
- 작은 것도 하나하나 정해서 규칙에 맞게 작성하자
6. 디자인 패턴은 다 이유가 있어서 세상에 나온 것이다
- 아토믹 디자인 패턴을 익히고 잘 써먹자
7. API관리들도 하나로 모아서 해주자(예: APIManager)
8. Bool Type을 가리는 함수는 isGood 처럼 is를 붙여서 작성해주자
이 외에도 수많은 조언들을 해주셨지만, 다 담기에는 내용이 많아 이정도만 추려본다.
우리끼리 코딩을 하면서는 어렴풋하게 이게 중요한건가? 싶었던 부분들을 왜? 와 함께 짚어주시니 '아 저게 필요한 것이었구나!' 라면서 바로바로 이해할 수 있었다.
직접 코딩해보며 어렴풋하게 느꼈던 필요성들과 멘토님의 친절한 설명이 함께하며 앞으로 내가 어디로 가야되는지 파악한 순간이었다.
'프로젝트 > 42프로젝트' 카테고리의 다른 글
| 15분이면 충분하다 배포방법(AWS EC2, Vercel) (0) | 2023.03.31 |
|---|---|
| 비용을 아끼자(모닝글로리 웹페이지 제작 5) (0) | 2023.03.17 |
| 어떻게 배포할 것인가?(모닝글로리 웹서비스 제작 3) (0) | 2022.11.29 |
| 어떻게 개발할 것인가?(모닝글로리 웹서비스 제작2) (0) | 2022.11.17 |
| 첫 회의와 Figma와의 첫만남(모닝글로리 웹서비스 제작 1) (0) | 2022.11.07 |