티스토리 뷰
드디어 두번째 프로젝트가 끝났다. 기능 구현을 할 수 있을까 걱정했는데 버그가 있지만 모든 기능을 완성은 했다. 저번주에는 다른팀들을 보고 좌절을 했었는데 결과물을 보니 기능을 끝내지 못한 팀이 더 많았던 것 같다. 그래서 조금은 자신감을 얻었다. 당근마켓같은 웹사이트를 2주도 안되는 기간에 만드는 건 조금 짧긴 하다. 그리고 제약사항 때문에 더 힘들었다. 제약사항은 크게보면 프론트에서 뒙팩, 바벨, 타입스크립트같은 라이브러리를 제외한 라이브러리는 모두 금지고 asyn await 금지, fetch 함수 사용이였다. 그리고 화면이 슬라이드로 나오기 때문에 사실상 spa로 만들어야 했다. 백엔드는 orm이 금지였는데 나처럼 db 3, 4중 조인문을 사용하지 않은 사람들에게는 이게 백엔드 과정인가 싶을 정도로 어려웠다. 일부러 몽고디비같은 nosql이 아니라 rdbms인 mysql을 사용하라고 했기 때문에 기본 정규형은 지키면서 했기 때문에 백엔드 쿼리 짜기가 힘들었고 orm이 금지이기 때문에 더욱 더 그랬다. 서버에서는 로그인기능을 제외한 다른 부분은 팀원분이 짰다. 나는 그냥 라우터하나에 쿼리문 반환문을 전부 넣었는데 보니까 다들 디자인 패턴을 생각하면서 코드를 짰다. 우리 팀원은 mvc패턴으로 짰는데 주말간 호눅스가 추천한
https://softwareontheroad.com/ideal-nodejs-project-structure/
이 글을 읽어봐야겠다. 백엔드는 사실 경험이 없어서 대충 쿼리문 짜고 status바꿔서 json변환하는 것만 할줄알았는데 해봤자 유효성검사?? 조금은 더 공부해야겠다는 생각이 들었다. 프론트에서 공부의 필요성을 더 느꼈는데 일단 우리팀이 선택한 방식은 스택방식으로 안드로이드와 비슷한?? 구조였다. 가장 쉽고 간단할 줄 알고 선택했는데 어려운 구조였다... 대충 구조를 말하면 최상위 모듈에서 하위 컴포넌트(페이지) 인스턴스를 만들고 state, setstate를 통해 공통적인 state를 관리하고 render로 하위 컴포넌트를 불러오거나 하위 컴포넌트에 setState를 걸어서 state를 전달했다. 하위 컴포넌트에서는 rerender를 추가해서 변경되는 부분만 수정되게 만들었다. 리액트는 virtual dom, 트리구조 등 다양한 방법을 사용해서 변환되는 부분을 찾고 그 부분만 변경할 수 있지만 기본 바닐라자바스크립트는 그런걸 하지 못한다. 그래서 직접 해줘야 한다. 그런데 따로 리듀서같은 상태관리 라이브러리가 없다보니 규모가 커지면서 관리하기가 너무 힘들어졌다. 버그가 발생하면 어디서 렌더링이 되고 리렌더링이 되서 문제인지 찾는게 너무 힘들었고 고치는 과정도 힘들었다. 그래서 배포전날 새벽에는 그냥 아무렇게나 코드를 고쳤다... 진짜 이건 어쩔수가없다. 시간은 촉박하고 의존성을 따져가면서 하나하나 보기는 불가능했다. 또 다른 팀들은 프론트쪽에 분리를 엄청나게 해놨는데 우리팀은 거의 분리를 하지 않았다. 처음에는 크게 필요성을 느끼지 못했는데 나중에는 진짜 분리의 필요성을 뼈저리게 느꼈다. 코드가 300줄이 넘어가버리니 아무리 함수를 쪼개고 나름대로 정리해놔도 읽기가 너무 힘들었다. 크롱님이 디자인 패턴을 아직은 몰라도 된다고 말하지만 코드리뷰를 하면서 하는 얘기를 들어보면 그런 패턴을 적용하지 않을 수 없다. 다들 무슨 아토믹?패턴, 옵저버블패턴, 플럭스패턴, mvc패턴 등등 많은 패턴을 적용시키니 그런 것 없이 쌩으로 짜는 나와 비교하니 비교가 될 수 밖에 없다. 사실 지금 방식이 거의 리액트와 유사한 패턴이라 옵저버블패턴, 플럭스패턴과는 조금만 수정하면 코드가 비슷하기는 할 것이다. 결국 나같이 처음에는 코드를 짜다가 필요성을 느껴서 그 패턴을 공부해보고 나만의 스타일을 만드는 그게 이상적인 방향일 것 같다. 언제부터인지 모르겠지만 필요성을 느끼고 그 필요성을 느꼈을 때 공부하고 가치관이 바뀌었었는데 지금이 그 상황인 것 같다. 필요성을 느꼈을 때 공부하는 건 진짜 중요하다고 생각한다. 크롱이나 호눅스도 그런 생각을 가지고 얘기를 하시는 것 같다. 아니 애초에 우아한테크캠프 자체가 그런 것을 생각하고 만들었는지도 모르겠다.
특히 생각을 많이 했던것이 기본 프론트구조에서 url로 이동하고 새로고침을 하는 것이였는데 history의 pushstate를 이용해서 url을 이용하고 url을 /으로 나눠서 state에 넣어놓고 그거에 따라서 div태그를 불러와서 덮어버리는 구조로 만들었는데 비동기 처리가 너무 힘들었다. 그래서 그냥 settimeout으로 로딩창을 만들어버렸다. 사실 절대 하면 안되는 방식인데 시간 상 불가능했다. 거기다 async await를 사용하지 못하는 것도 굉장히 만드는데 불편함을 느꼈다. 덕분에 promise에 대해서 조금 더 잘 알게되는 계기가 되지 않았나 싶다. 실제로 promise를 적용하다가 생각지도 못한부분에서 문제가 생겼는데 async await도 promise와 제너레이터를 기반으로 동작하기 때문에 알면 무조건 도움이 된다. 뒤로가기도 기본 이벤트를 막아버리고 내가 만든 back함수를 이용했다. 그래서 일단은 pjax방식이다. 공부를 하면서 자연스럽게 pjax방식, 해시방식도 알게되었다.
기술은 이정도면 많이 얘기한 것 같고 진짜 느낀게 여기서는 잠잘 시간이 없다. cto님 가치관 때문인지 그냥 죽어라 공부를 해야한다. 사실 요구사항이 2주도 안되는 시간동안 하기엔 많이 벅찼다. 웹팩, 바벨 설정부터 제약사항 그리고 s3연결, 채팅, 좋아요 표시 등등 실제 당근카멧과 다른점이 많지 않다. 물론 페이지가 13개? 정도로 훨씬 적긴 하지만 기본적인 기능들은 전부 들어가있다. 그러면서도 코드리뷰를 하면서 여기는 분리하는게 좋겠다, 텍스트는 상수로 관리하자 같은 자잘한 부분까지 신경을 쓰다보면 진짜 시간이 많이 부족하다. 우리팀도 채팅을 배포전 저녁쯤에 시작했다. socket.io로 하려다가 room 나누는데 문제가 생기고 시간은 없고 그래서 그냥 폴링방식을 사용했다. history부분에 url버그가 메뉴쪽에 있는데 진짜 죽어도 못찾겠다. 그리고 sql 조인문에서 채팅부분에 문제가 생겼는데 시간이 없어서 해결하지 못했다. 그게 좀 많이 아쉽다. 내가 db를 좀만 더 잘했어도 가장 큰 버그 하나를 해결할 수 있었을 텐데 많이 아쉽다. 평소같으면 금요일에도 공부를 할텐데 그날 잠을 2시간자고 그 전날에도 4시간정도밖에 못자서 공부를 아얘 못했다. 심지어 후기도 다음날 아침에 쓰고 있다. 근데 진짜 많이 배우고 이렇게 열심히 혼자서도 할 수있을까 생각이 든다. 근데 다음프로젝트때는 더 바쁘겠지..... 말이안된다. 기억에 남는 프로젝트 결과물이 있는 팀이 있는데
https://www.youtube.com/watch?v=pTRENL-7d6c&ab_channel=popjiggly
위에팀이다. 진짜 다크모드구현까지 이시간에 하는건 진짜 말도안된다고 생각한다...
운동가야되서 쓰고 싶은 말은 많은데 여기서 끝내야겠다.
일단 이번주 주말에 공부할 내용은. 루카스 자료 공부, 웹팩, 바벨 공부, 웹소켓 공부, 디자인 패턴공부(프론트, 백 둘다), aws 공부이다. 할게너무 많네...
밑에는 프로젝트 결과물이다.
https://github.com/woowa-techcamp-2021/deal-13
http://ec2-3-34-144-71.ap-northeast-2.compute.amazonaws.com/
https://www.youtube.com/watch?v=tZCN-He-mAg&ab_channel=%EC%9C%A4%EC%9C%A4
'우테캠' 카테고리의 다른 글
우아한테크캠프 4주차 후기 (0) | 2021.07.31 |
---|---|
개발시 필요한 함수들 (0) | 2021.07.24 |
우아한테크캠프 2주차 후기 (0) | 2021.07.17 |
1주차 정규식 유효성 검사 (0) | 2021.07.10 |
우아한테크캠프 1주차 후기 (0) | 2021.07.10 |