목표
개인의 성장 목표, 기술적 고민거리와 트러블 슈팅 경험 등을 문서로 정리합니다.
[피어세션]에서 받은 질문과 피드백을 정리하여 추가해두길 권장합니다.
- 상시로 진행한 개인 회고 결과가 있다면 해당 기록으로 갈음할 수 있습니다.
회고
한마디
이번 주는 TDD 때문에 울고 웃었던 한 주였습니다. 페어 프로그래밍 시간이 화/목밖에 없어 시간 압박이 좀 있었는데, 화요일에 이렇다할 성과가 없으니 제가 조바심이 나서 돌이켜보니 좀 예민했던것 같기도 하네요.. 반성
그럼에도 정말 미친 체력으로 목요일 엄청난 양의 페어프로그래밍도 함께 마치고 추가로 Swagger까지 적용해주신 준섭님 정말 존경하고, 저도 운동 열심히해서 체력도 멘탈도 강인한 개발자가 되어야겠다는 생각을 했습니다. 흑 그리고 발표 빠뜨려서 죄송해요,, 하트❤️
KPT 회고
Keep
- 기록하며 개발하기
- 따로 시간을 내는 것보다 훨씬 효율적이고
- 이런 기록은 비슷한 문제의 해결에 실질적인 도움이 많이 되는 것을 절실히 느꼈습니다. Keep going!
- 페어 프로그래밍할 내용 미리 학습 정리하기
- 막연히 만나기보다, 미리 어떻게 개발할 지를 손만 움직이면 될 수준으로 미리 알아봐두니 개발 시간을 현저히 단축시킬 수 있었습니다.
- 앞으로도 가능한 이렇게 미리 학습하고, 개발하는 습관을 들이면 좋겠습니다!
Problem
- 백로그의 중요성
- 백로그가 Story 기반으로 모호하게 작성되다보니 여기에 맞추어 개발하기가 상당히 힘들고, 커밋을 할 때도 PR을 날릴 때도 여러 차례 딜레이가 있었습니다.
- 빠뜨린 백로그도 많았습니다. 추가해주는 데 또 한세월..
- 현재까진 이슈를 수정하며 유도리있게 잘 해결해나가고 있습니다만, 월요일에 백로그 단계부터 상세히 Task를 작성해두면 참 편하겠습니다!
- 페어 프로그래밍의 장단점
- 개인의 성장에는 깨닫는 점이 정말 많았지만, 분업이 아니다보니 프로젝트 전체의 생산속도는 확실히 감소한다는 것을 느꼈습니다.
- 시간 분배할 때 이 부분을 고려하여 넉넉히 잡고, 개발시간 전후로 미리 학습하고 마무리 기록을 잘 하는 습관을 들여 효율을 올려봅시다!
Try
- 백로그 이슈 개선하기
- 빠뜨린 백로그 추가하고 이슈 open하기
- 월요일에 Task 가능한 상세히 정리하고 계획하기
- 페어 프로그래밍
- 사전 학습 : 페어 프로그래밍 전 개발할 내용 사전에 계획해두기
- 기록 남기며 개발 : 과정이 느려지더라도 캡쳐와 로깅을 철저히 하며 진행
- 정리 부채 해결하기
- 학습해둔 내용들 주말에 정리해서 블로그 올리기! 제때제때 해라!
개인의 성장 목표
기술적 도전
- 배포
- GitHub Actions와 Docker를 활용한 CI/CD
- AWS, NCP
- 아키텍처 구조
- 각 인스턴스들의 역할 : EC2(Server), Lambda(Cloud Functions), S3(Object Storage), VPC(VPC), ELB(Load Balancer), RDS(CloudDB) 등
- NGINX
- HTTPS(SSL/TLS) 구축하기
- 로드 밸런싱 기능 활용
- 보안 기능(IP/Port 스캐닝 차단 등) 활용
- 리버스 프록시를 통해 프론트엔드, 백엔드, 스토리지 서버 등 요청 처리
- DB
- MySQL 동시성 제어
- 쿼리 최적화
- NestJS
- NestJS LifeCycle
- Test
- TDD로 개발하기
- 부하 테스트 및 로드 밸런싱을 통한 대용량 트래픽 대비
기술적 고민
TDD로 API 구현하기
- Controller, Service 유닛 테스트를 활용한 TDD 도전 ->
failed - e2e(End to End) 테스트를 활용한 TDD 도전 ->
succeeded
Controller, Service를 개발하지 않은 상태에서 완벽한 유닛 테스트를 작성하는 것은 상당히 힘든 일이였습니다.
특히 유닛 테스트하는 계층 외 종속되는 모든 부분을 mocking하는 방식은 그 실효성에 대해서 페어분이 의문을 제시하시기도 하고, 저도 좀 더 나은 방식이 있을 것 같아 고민을 많이 해봤습니다.
리뷰어 멘토링에서 e2e 테스트로 TDD를 시작해보라는 조언을 주셔서, 결과적으로는 frontend 입장에서 요청해야 할 api에 대해 e2e 테스트로 실패하는 테스트 코드를 작성하고, 이를 통과하도록 구현하는 방식을 시도했고, 성공적으로 구현을 할 수 있었습니다(supertest 모듈 활용).
일반적인 TDD 방법론에 대해서도 학습할 수 있었는데, 다음의 순서로 진행됩니다.
- Red (실패하는 테스트 코드 작성)
- Green (테스트를 통과하도록 구현)
- Refactor (리팩토링)
앞으로 도전할 테스트 관련 Task는 다음과 같습니다.
- Transaction 또는 테스트 테이블 활용한 DB CRUD 테스트
- Code Coverage 고려
Swagger 적용
프로젝트의 특성상 프론트의 Three.js관련 Task가 많아 백에서 담당하는 API 구현이 프론트보다 빨리 진행되고 있고, 이로 인해 API 인터페이스를 백에서 결정하고 프론트에 효율적으로 공유해주고자 Swagger를 적용하게 되었습니다.
알아보고 테스트 브랜치를 만들어 적용해보았는데, 생각보다 쉽고 Postman같은 기능도 되어 편리하더군요! 짱입니다.
프로젝트에 적용 후 PR은 페어분이 해주셨는데, 이번 프로젝트 발표때 제가 이 부분 소개드리는 걸 깜빡해 정말 죄송하고 눈물이 납니다 ㅠㅠ 흑흑 고생많으셨어요..
배포 및 배포 자동화 계획
현재 다음 과정까지는 완료했습니다.
- NCP 내 VPC, subnet, Server 인스턴스 생성 및 외부 접근 가능하게 설정(ssh), docker 설치
- docker 이미지 만들어서 push/pull하여 프로젝트 수동 배포
지난 주 말미에 했는데, 아쉽게도 개발 기록을 남기지 않아 다시 한 번 정리해야 겠습니다. 앞으로 추가로 고민할 내용은 다음과 같습니다.
- NGINX 설정파일 작성 (fe 정적파일 서빙, be 리버스 프록시)
- main으로 push된 모노레포 속 be, fe 프로젝트를 각각 docker로 빌드
- docker-compose로 한 번에 수동 배포
- GitHub Actions로 자동 배포
시간이 없어 금요일 전 배포는 무산이 되었지만, 일요일에 만나 시도를 해볼 예정입니다.
트러블 슈팅
Upstream Repository 동기화 및 작업 브랜치 설정
Upstream Repository 동기화 및 작업 브랜치 설정
upstream project를 갈아엎어 origin과 충돌날 때, upstream 기준으로 강제 동기화 하는 법
갈라진 branch, 충돌 해결해서 rebase하기
두 개의 PR을 날리고 첫 PR에 수정사항이 발생했을 때, 안전하게 rebase하는 법
모노레포에서 jest test 환경설정
모노레포에서 패키지 설치 후 자동완성 안되는 문제 해결
근데 보통 모노레포 + yarn berry + vscode면 이 시점에서 코드는 에러가 없는데 자동완성이 안된다..
yarn workspace server install # 결론: 안해도 됨.기존엔 VSCode 이런 식으로 설치를 해줘야 자동완성 및 import가 되는 줄 알았는데 (안되면 이것도 해보시길),
자동완성 안되는 이유는 그냥 VSCode가 인식을 못해주는 거여서, 리로드를 하면 되는거였다.
cmd+shift+p 후 reload 검색, 개발자: 창 다시 로드 클릭
사랑합니다