11월 16일 (기업 네트워킹, 마스터 클래스) - boostcampwm-2022/web33-Mildo GitHub Wiki

기업 네트워킹

작년과 올해는 확실히 분위기가 다르다.. 그러나 모든 회사가 다 그런 것은 아니다.
기업마다 속도가 바뀌는 텀이 달라진다.
12월 1일 ~ 12월 6일 → 채용 연계 및 이력서를 취합해서 넣어아 햔다. 기한이 지난 이후에는 수정을 할 수 없다.
12월 16일 수료 직후부터 개별적으로 컨택할 수 있음
12월 19일 ~ 12월 20일: 네트워킹 데이 진행
2월까지: 파트너기업에서 우선적으로 채용 지원
네트워킹데이: 인재들과 기업이 서로 만나는 자리입니다.
- 오전: 수료생 부스를 통해서 프로젝트 소개 → 데모 시연
- 오후: 기업 부스 → 부스 운영 및 프로그램은 기업에서 자율적으로, 예약이 필요한 경우 사전 공지
지금부터 준비할 수 있는 것: 네트워킹데이에서 예약을 못할 수도 있으니 꼭 컴퍼니데이에 참여해보자. 이력서는 미리 준비하자. 마지막 주는 마지막까지 손을 대는 팀들이 많다. 리팩토링과 디버깅하는 작업도 많을 수 있다. 따라서 지금부터라도 기술적인 문제를 해결하는 경험에 대해서 스토리를 다듬어 나가자.
이력서는 어떻게 작성해야 할까?

1 - 기본 인적사항 (이름, 연락처, 깃헙 또는 블로그, 학력 등)

2 - 보유한 스킬 & 역량 간략히

3 - 내가 진행했던 프로젝트 & 어떤 문제 해결했는 지

4 - (옵션) 너네가 날 안뽑으면 후회할 이유 같은 거

5 - 면접관이 이걸 보고 무슨 생각을 할까.
4가지 능력: 문제해결 능력, 개발 퍼포먼스, 탐구 능력, 성장 포텐셜
채용연계형 인턴십은 전부 다 정직원으로 뽑는다는 것을 가정하고 뽑습니다.

마스터 클래스 (황준일)

API 테스트코드 작성 시 가장 중점적으로 보는 부분

백엔드 테스트 코드(도메인 로직) → 서비스 로직이 백엔드에 몰려있는 경우가 많음
예시: 논문의 정보를 가져온다 → api에 대한 params, query, body → body의 양식이 적절한가??
논문을 가져오는 요청 → 인자들을 클래스로 정의 → 클래스에 대한 검증 로직 만들기 → 검증 로직에 대해 테스트 (타입이 적절한 지, string(’A’, ‘B’, ‘C’) 등으로 고정값만 들어갈 수 있을 경우 다른 값이 들어가면 어떤 일이 발생해야 하는가) → 인수테스트(논문 정보를 가져옴 → 적절한 데이터들이 존재하는가)
양식이 바뀔 수도 있음 → 응답에 대한 프로퍼티들이 다 존재하는 지, 각각의 값이 적절한 지 → 변경에 대해서 민감하게 반응하고 바뀌는 부분을 중점적으로 테스트해야 한다.
현재 데이터들의 상태에 따라 노출되는 방식이 다른 것에 대한 테스트도 진행해보자

OAuth의 테스트

보통은 token 기반

→ 로그인 상태일 때 어떤 행위들이 가능한가?

→ 로그인 상태가 아닌 경우에는 어떤 행동의 제약이 존재하는가?

일반 회원 vs 관리자 → 무엇이 가능하고 무엇이 불가능한가?

google, kakao, naver, github 등등… → 응답 형태 → 어떻게 정제를 해야 하는가에 대한 테스트도 작성해볼 수 있을 것 같다. → 이에 대해서 파싱을 해주는 함수를 만들 수 있다.
- 그러나 OAuth 그 자체에 대해서 검증을 하는 것은 어렵지 않을까 (input → output(모킹)), 특정 input에 대한 output을 받았다고 가정하고, output을 테스트 코드로 사용한다 (mocking)

환경변수의 공유와 협업

애초에 환경변수를 고정으로 해놓는다. 배포를 하는 경우 환경변수를 정제할 수 있다. → 배포를 github actions로 한다고 가정했을 때, Actions의 Secret에다 배포에 필요한 환경변수를 정의하고 삽입한다. (.env는 비어있는데, 이를 환경변수로 사용하기) → echo > .env.test
.gitignore로 env를 쓰고, .env.template을 이용해서 private한 공간에 어떤 환경변수들이 있는 지 정의를 해놓고 가져다 쓴다. → repository는 공개되어 있지만 노션/슬랙/위키 등에 환경변수를 올려놓을 수도 있고, 서버에 올려놓은 다음에 이것을 다운로드 받아서 쓸 수 있게끔 할 수 있다.

다양한 IDE

결국 불편함을 인지해보자. IntelliJ에 있는 것들은 결국 vscode 내부에도 존재하는 기능인 경우가 많다. intelliJ에 있는 기능들은 VSC에서는 잘 찾아보면 있다.
editplus → sublime text → vscode → intelliJ
어차피 회사를 가게 되면 강제하게 된다. 회사에서 webstorm만 쓰게 하거나, vscode만 쓰게 하거나…

HTTP GET 메서드 업데이트

분명 GET의 용도가 있기는 하지만, 용도보다 중요한 것도 있다. (가령 돈..)
API의 사용량이 많을 수록 서버에 대한 사용량도 많아진다.
내가 실제로 페이지에 방문한 경우 / API로만 호출하는 경우 → 어떻게 구분할 수 있을까?
결국에는 분리하는 것이 나을 수 있다. 악의적인 사용자가 나올 수 있기 때문

Soft Delete의 HTTP Method

그냥 DELETE도 괜찮다! (API라는 것이 그냥 데이터를 다루는 것일 수도 있지만, 클라이언트 입장에서 DELETE를 사용하는 것도 좋다)
DELETE /api/posts/1 호출 → GET /api/posts/1 호출 → 404 나온다 (실제로는 DB에서 상태만 바꾸어놓은 상태임)
API의 동작 측면에서는 합리적이지 않을까

데이터 로드가 오래 걸리는 경우 → SSR vs CSR

SSR로 html을 먼저 만들고, API를 호출해서 만들어진 데이터로 CSR? → 그렇게 하면 된다
잘 생각을 해보면 API를 호출하지 않았을 때, 비어있을 때, 데이터가 아무것도 없을 때, 미리 렌더링을 그냥 해주면 되지 않을까?
초기 화면 → SSR로 만들더라도 CSR로 해도 상관없는 부분
따라서 가능하면 캐싱을 적극적으로 활용해보자!!

즐겨찾기 해제 → HTTP 메서드를 POST vs DELETE

POST, PUT, DELETE, 등등…
POST + DELETE → 추가와 삭제를 따로 / PUT → 한 번에 처리 / PATCH → 한 번에 처리
이럴 때는 POST + DELETE로 해도 괜찮지 않을까…
nginx에서… → delete, put, patch 등을 다 막아버리는 경우 / 무조건 post만 허용하는 경우 / post 조차도 허용하지 않는 경우 → 웬만하면 POST로 진행해보고 나중에 리팩토링을 진행해보자. 고민에 대한 투자가 그렇게까지 중요한 것 같지는 않다. 그러면 최대한 단순하게 처리를 하자.
- 이거는 항상 고민…

OT / CRDT

쉽지는 않을 거 같다..
a, b, c, d → 프로토타입을 구현 → 어 할만하네? vs 안될 거 같다… → 결정
버릴 수 있는 시간에 대한 리스크를 감수해야 한다. → ‘이정도는 투자해도 되겠다.’라고 판단되는 시간

동일 서비스 모듈 내에서 서로 참조를 하는 것에 문제가 없을까..

동일한 서비스 파일 내에 생성해도 되는 지 잘 모르겠다
보통 utils를 만들어서 쓴다. 그런데 아예 다른 layer(저수준)을 만드는 것도 좋은 방법이기는 하다
그러면 service보다 더 낮은 단계의 (혹은 더 복잡한 단계의 일) → 어떤 Layer로 만들꺼야..
예시) facade 패턴을 직접 만들어서 이 패턴에 의존시킬 수 있게끔 함
- GithubFacade
  - GithubAuthService
  - GithubRepoService
  - GithubPullService
- GithubReviewFacade
  - GithubAuthService
  - GithubRepoService
  - GithubPullService
- 등등….

소켓서버 통신시 client에서 잘못된 요청을 보내게 되었을 경우의 처리 방법

Error에 대한 class 혹은 model을 하나 만들어 놓자!
에러 → BadRequest에 대한 에러 / unAuthorize에 대한 에러 등등.. express/koa 등에서도 존재할 텐데, 이를 적극적으로 활용해보자!
- 소켓 통신과정에서 HttpException이 발생하면 바로 특정 형태를 가진 Response를 만들어서 전달해준다. → 예시) graphQL → 얘는 무조건 200이다… 특정 형태로 응답이 오는데, 어떤 데이터는 데이터가 없을 수도 있고, 어떤 데이터는 request 형태가 잘못 되어 있을 수도 있다.
소켓 통신도 rest api와 마찬가지로 unit testing, api 문서 만들기를 많이 할까?
- 당연히 편하지 않을까? → 이거는 소켓 뿐만 아니라 다른 경우도 다 마찬가지다.. 소통 방법은 다양하기 때문임.

CI/CD

CI: toothless로 체크하는 것을 진행하기도 한다.. → 지속적으로 체크를 진행함 → 검증된 것을 올려야 한다 → 모두가 안전한 코드를 공유 → 브랜치에서 pull을 받았을 경우 이상이 없어야 한다
CD: 지속적으로 배포를 한다. 코드 변경이 파이프라인 이전의 변경을 모두 통과하면 Merge가 되면서 진행된다.
Naver Container Cluster → 코드 커밋 / 푸시 등등..
Jenkins(CD) + Github Actions(CI) 병행하는 편 → 하나만 쓰지는 않고 보통 두 개를 많이 씀
Github Actions를 실행해보는 환경을 무료로 제공해준다. (runners)
Workflow → Ubuntu / Window 환경에서 같은 코드를 테스트해본다. 그러나 runner에 대해 어느 정도의 제한이 존재할 수 있다.
직접 Runners를 구현해서 사용할 수 있다 (actions-runner).
self hosted runner를 VPC에 넣어서 사용하는 것이 가능하다.
Actions Secrets에서는 비밀이라서 공개되지 않았던 부분들을 실행하는 것이 가능하다. → 어차피 secrets에서는 내용이 감춰진다.
json 파일을 미리 가져오기 → jobs / schedule → cron: “* * *” …. → 이런 방식으로 정기적으로 json 파일을 가져와서 저장소에 지속적으로 반영을 함 → 크롤러를 실행함 → 이러면 DB 안 써도 크롤링으로 가능함
jenkins로 콘솔을 출력 → Github Actions로도 할 수 있다. ← 크롤러로 실행을 하게 되면 workflow가 적용되는데, 이것을 기반으로 task들을 돌릴 수 있음
Lighthouse CI → PR이 올라오면 실행해서 성능 결과를 올려줄 수 있음 → Lighthouse CI를 올려줌 (성능을 올려주는 것이 가능하니 한번 찾아보자)
Jenkins의 좋지 않은 점은 Dashboard에 Jobs들이 직렬로 처리됨 (병렬 처리 X), 그러나 github actions는 병렬 실행이 가능하다는 장점이 존재함. 예를 들어, jobs가 여러 개가 실행되면 병렬적으로 다른 컴퓨터에서 실행됨. lint, tsc, unit test, e2e test, deploy 관련 job들에 대한 runner들을 각각 따로따로 사용할 수 있음
yarn 2 berry 같은 것을 사용하면 zero-install로 관리할 수 있음 (설치는 필요하지만 오래 걸리지 않음)
marketplace → checkout 보통 많이 사용함 (이것저것 설치하고 지정할 수 있음 → git log까지도 싹다 나옴) → commit과 push를 바로 해주는 작업도 존재함
한번 cron scheduling과 관련해서 만들어보고 공유해보자
git hook, husky → 이 아이를 많이 쓴다! LifeCycle Hook과 관련된 command를 설정할 수 있다. package.json에 lint-staged를 통해 eslint 하기 전에 뭐뭐 하는 지 체크를 한다. 커밋을 하기 전에 yarn lint-staged를 수행한다. → 꼭 push를 해야만 할 수 있는 것은 아니다. 코딩 컨벤션 체크도 마찬가지로 할 수 있다. → eslint나 prettier → 이런 것들은 전체 코드에서 석용하면 너무 오래 걸리기 때문에 staged된 애들에 대해서만 실행할 수 있도록 하기!
main에 머지 prod에 배포 / dev에 머지 → …에 배포
Health Checking → 일정 주기마다 호출해보고, 정상적으로 확인해보기