[네이버 부스트캠프] 멤버십 3주차 후기

멤버십 시작한지 벌써 3주가 지났다. 3주간 아주 휘몰아친 느낌이어서 3주가 어떻게 지나갔는지 모르겠다.

이번 주말이 그래도 좀 여유가 주어진 주말이라 이 시간을 활용해서 내가 공부한 것들과 앞으로 더 공부해야할 것들, 그리고 개선해야 할 점들을 정리해보고자 한다.

 

이번 프로젝트에서 배운 것들

클라이언트 사이드 렌더링 (client side rendering)

이번에는 첫주차 과제와는 다르게 클라이언트 사이드 렌더링 방식으로 프로젝트를 진행해봤다.

구글링 하면 개념은 많이 나오는데 정확히 코드가 어떤식으로 구현되어 있는 건지는 잘 나와있지 않아서 많이 고민을 했던거 같다.

내가 구현한 방법은 클라이언트단은 웹팩으로 public폴더만 만들어주고 이 폴더를 서버가 가져다가 렌더링 해주는 방식이었다.

다른 팀원분께 들어보니 이 방식은 완전히 클라이언트 사이드 렌더링 방식은 아니라고한다. 정확히는 클라이언트, 클라이언트 서버, 서버 가 다 따로있고 클라이언트 서버가 페이지를 렌더링, 그리고 서버는 그냥 데이터 api만 있는 방식이라고 한다.

내가 사용한 방식은 WAS라는 이름의 방식이라고 해주셔서 이 부분을 추가 공부해봐야겠다고 아직 생각만 했다..ㅋㅋㅋ

출처:

https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html

 

webpack & babel

webpack을 사용해봤다. js, 이미지 파일, css를 묶어서 bundling 한 기본적인 기능만 사용해 보긴 했지만 왜 사용하는지 이해했고 어떻게 쓰는지 알았으니 앞으로 사용은 더 응용해서 써봐야겠다.

같이 공부했던 팀원분이 하신걸 보니까 webpack.common, webpack.dev, webpack.prod 이렇게 파일을 나눠서 하셨던데 그 부분에 대해서도 더 공부해봐야겠다.

webpack과 바벨을 공부하면서 느낀점은 브라우저마다, 그리고 브라우저 버전마다 돌아가는 코드가 다 다르다는 것, 이걸 다 맞추면서 코드를 짜는게 생각보다 쉽지 않다는 점이다.

아래는 내가 만들어 놓은 webpack boilerplate이다.

webpack boilerplate

https://github.com/leesunmin1231/webpack_boilerplate

 

SASS (SCSS)

이번에는 css대신 sass라는 걸 써봤다. css에 비해서 여러가지 부가 기능들 (함수, 조건문 등등)을 쓸 수 있는거 같은데, 아직까지는 큰 장점을 못느껴봤다. 내가 아직은 css에 그렇게 크게 신경 안쓰고 있어서 그런건가 싶고. 내가 반응형 웹페이지를 만들어야 하는 상황이면 굉장히 유용해질 거 같다.

아직은 css에서 calc연산도 잘 안쓰고 있는 사람이라..

css는 여전히 어렵다. (솔직히 제일 어려운거 같다.)

조금만 틀어져도 이상하게 나오니까. position으로 transition 잡아서 일부러 블록 겹치게 만드는 거나, 클릭하면 html 틀 달라질때, 원래 css적용안되도록 클래스 이름도 전부 구분해서 넣어줘야하고..

다음주는 html layout반드시 지켜서 짤거다.

 

이벤트 전파, 이벤트 위임

하.. 이것도 빨리 공부하고 학습정리 해야겠다.

잘 정리되어 있는 레퍼런스:

https://ingg.dev/event-delegation/

무지성 이벤트 리스너 달아놓기만 해가지고 좀 이벤트 전파 과정 공부해서 다음 과제는 이벤트 위임 적용해봐야지.

 

state관리

이벤트 발생 → state변화 → rendering

나름대로 이번 코드에 적용해본다고 해봤는데, 뒤늦게 공부하고 다시 구조를 바꾸는 바람에 잘 적용이 안된 느낌이다. 다음 프로젝트도 이 방식으로 해보려고한다.

좀 더 자료 찾아보고 공부해본 다음에 코드 구현 시작해 봐야지.

 

Database

드디어 백엔드 부분이다.

관계형 데이터베이스는 처음 공부해봐서 여러모로 많이 애먹었다. 여전히 잘 알고 있는건 아니지만, 그리도 쿼리문 직접 짜보고 설계한번 해봤다는거 정도.

테이블 여러개 만들고 foriegn키 적절하게 잘 활용해서 데이터 가져올때 join으로 잘 가져오는게 가장 큰 메리트라고 생각했든데, 막상 직접 구현해보고 다른 분들 말씀도 들어보면 지속적으로 유지보수해야하는 db라면 오히려 foriegn키 최소화하는게 낫지 않나 하는 생각도 든다.

테이블 많고, 데이터 많을 때, db가 어떻게 설계되어있는지 참고하면 좋은 사이트들이 있어서 아래 적어놓는다.

대형 프로젝트 database ERD

https://www.slideshare.net/shekhardesigner/airlines-database-design

https://vertabelo.com/blog/a-database-model-for-a-hotel-reservation-booking-app-and-channel-manager/

MySQL

이번 프로젝트에서 상당부분 내 발목을 잡은 부분이다.

어떻게든 어거지로 가져다 쓰긴 했는데 아직 한~참 먼게 느껴지는 데이터베이스..

학부 수업으로 1년을 배우는 내용인데 내가 몇시간 공부로 따라잡겠다고 하는거 자체가 욕심이긴 하지.

각잡고 공부하면 너무 오래걸릴거 같아서, 필요한 부분 구현하면서 그때 그때 공부한 부분 채워나가는 방식으로 해야할 거같다.

이번에는 그냥 mysql 안써서 몰랐는데 그냥 mysql은 async, await를 못쓴다고 한다.. (충격)

mysql2가 promise api가 있어서 async, await이랑 잘 동작한다고.

사용할때, mysql2/promise를 require해야 잘 동작한다. (이부분도 knex써서 잘 몰랐다…)

그냥 아무생각없이 하지말고 왜? 을 붙이는 습관을 들이도록 하자.

출처:

https://holywater-jeong.github.io/2018/06/08/node-mysql-async-await

db는 너무 어렵다…

 

http API

서버와 데이터 주고받아야 해서 REST api 를 공부해봤다.

출처:

https://meetup.toast.com/posts/92

이것도 읽어보기만 하고 정리는 아직 안했다. (한게 뭘까?)

아무튼 메소드 적절하게 써서 api 구현하고 싶었는데, 그러지 못해 아쉽다. (무지성 Post요청 보내기..) get으로 적절하게 필요한 상황마다 써보려고 쿼리문도 만들었으면서 왜 그랬지 하하

다음 과제는 좀더 신경써서 해봐야지.

이외에도 공부해볼 부분이 많다.

 

 

코드 리뷰중에 가장 기억에 남았던 부분은

• 가져오는 데이터의 범위를 좁히는 작업은 굉장히 중요한 기본기이다.
• 어떻게 하는 게 좋을지 검색해 볼 때는 best practice라는 키워드를 써보자. ex) node architecture best practice
• 모듈을 분리할때는 후에 새로운 기능 추가나 유지보수 시에 생산성이 좋은 코드인지 고민해보자.

 

추가 공부해 볼 키워드

함수 순환 구조

Promise.all

REST API 정리

Functional Options 패턴 공부해보기.

함수형 프로그래밍 (reduce)

mySQL 인덱스, COUNT, SUM

Reference 자료형과 Premitive 자료형

DB 성능테스트 (k6, ngrinder)

eslint

node architecture best practice에 대해 알아보기 예시 글

디자인 패턴

• https://refactoring.guru/design-patterns
• https://patterns-dev-kr.github.io/

 

다음 구현에서 적용해볼 내용

클래스 이름 신경써서 해보기

크롬에서 디버거 사용해보기

return await 은 안티 패턴이다. https://eslint.org/docs/latest/rules/no-return-await

node의 전역 컨텍스트를 좋아하지 말자

동시성 이슈를 고민하자

array 빌트인 함수는 한번쯤 모두 읽어보기, 기억하고 있다가 나중에 필요할 때 적절히 쓸 수 있도록

부하테스트 해보기 참고

크롬 디버거

https://ko.javascript.info/debugging-chrome