출근 33일차

뮤·2022년 10월 12일

회사이야기

목록 보기

33/118

점심시간의 대화

리더 : 지금 출고에 직결되는 큰 에픽 두개가 동시에 가서 걱정이네요
나 : 저 작업 거의 다 완료됐는데, 프로덕션 배포 해볼까요?
리더 : 작업 다 된거에요?
나 : 택배사가 분리되어있는데 데칼코마니처럼 짜서, 기존에 쓰던 택배사는 당장도 붙일 수 있어요
리더 : 돌아가서 바로 올려보죠 (점심먹으러 가는 길이였다.)
나 : ?
나 :
나 : 내일까지만 시간을 주십쇼 내일 퇴근할때 프로덕션 배포하고 금요일 대응해보겠심다
리더 : 콜

생각한것보다.... 더...잘됐다!?

나는 현재 두개의 에픽을 함께 작업하고 있다.

기존에는 택배사 추가 연동작업만 있었는데
코드를 계속 보는데 개선할 여지가 너무 많아보였고, 노션을 만들어가서 리팩토링을 해보겠다고
허락을 받고 택배사 통합 관리까지 받아왔다.

추가적으로 기존에 운영적으로 문제가 있던 부분을 신규 기능에 추가하면서 현재 나는

2개의 에픽, 3개의 백로그, 대략 2N여개의 테스크를 들고 작업을 하고 있다.
(나는 테스크 한개마다 노션으로 명세를 자세하게 적는 편이라, 대충 메소드 2N개정도 만든다고 보면 된다.)

그 중 대략 1N개 가량의 테스크가 완료되는 시점에서 저 이야기를 듣고, 데브DB에서 셀프 Q/A를 시작했다.

물론 Q/A도 체크리스트가 있어야하니까 당연히 노션으로 만들었다^^;

그리고 부하 테스트를 개발DB에서 진행했다. (혹시 몰라서 허락받았다, 터질까봐;)

그리고 결과는...대성공이였다!
대충 계산해보니 속도를 67.5%정도 빠르게 만들었다.

그리고 더 중요한 것은 현재 AWS의 HTTP 커넥션 최대유지시간 60초로 설정되어있다.
그러다보니 기존의 방식으로는 100~200장이 한계여서 대량출고가 있을 때 문제가 크게 발생했다.

저런 문제를 보면서 테이블 설계부터 기존 로직의 대부분을 날려버리고 새롭게 구현을 한 것이였다.

그런데 기존에 100장도 힘들었는데, 960장을 출력하는데 47초.

즉 1000장도 문제 없이 출력을 할 수 있도록 만들었다!
문득 프린터에 1000장의 용지를 넣을 수 있는가에 대한 의문이 좀 들어서(...) 이 부분은 조금 알아봐야할 것 같지만?

또, 테이블 설계를 할 때 유니크한 값들을 레코드에 있도록 설계를 해놔서
나중에 반품이라거나 신규 기능을 넣을 때도 기반 테이블로 작업을 할 수 있다!

내가 생각한 것보다 더욱 효과적으로 작동했고, 제일 중요한 것은 바로!

입력값, 출력값에는 변함이 없다.
현재 FE의 손이 없어서 나 혼자서 마술이라도 부렸어야했는데?

부렸다. 마술!

당연히 자랑했다, 이런건 티내면서 살아야 성과를 인정받는다 ㅋㅋ

CTO님 리더님 팀원 모두 반응은 똑같았다
완전 최고

어떻게보면 당연하다, 신입이라고 대려왔는데 이것저것 다 헤집으면서 뚝딱하고 있으니...
연봉협상때 이야기를 좀 낼 수 있겠다 싶었다. 프로덕션 배포까지 잘 올라가면!

그리고 난..지금에서 만족을 못한다, 기존 프로세스 더 고칠 여지가 많다.
일단 지금 하는 에픽부터 마무리하고!

으음~ TypeORM 버전업.....

코드리뷰를 받던 사이에 짬이 생겨서 TypeORM의 0.2버전과 0.3버전의 구현체를 살펴봤다.

0.2 버전
- 모든 메소드들이 prototype로 적용
- 조건 분기를 나눌 때 switch문을 사용
0.3 버전
- 모든 메소드들이 클래스로 적용
- 조건 분기를 나눌 때 if문을 사용
삭제 예정인 Connection
- DataSource로 변경해서 사용해야함
하위 호환을 전혀 안하는 manager(EntityManager)
- 다른 것들은 정상 작동하지만, 조회 관련된 모든 메소드들이 호환 X
SelectQueryBuilder의 경우 변경점이 없음
- 미래를 위해서, 조회는 createQueryBuilder로 작성하기