Sn._.Jay

express로 이루어진 프로젝트에서 발송 관련된 기능들을 nestJs 기반으로 분리하는 작업을 하고 있는데 하다가 aws-sdk3이 나왔단 사실을 알고 뜯어보고 비교할 것없이 바로 이번 플젝에 적용시키고자 한다. 일단 AWS 피셜 달라진 점 한줄 요약 : 최상급 Typescript 지원, 새로운 미들웨어 스택 및 각 서비스에 대해 개별 패키지를 갖추고 있는 모듈식 아키텍쳐가 적용되었다. 개별 패키지로 모듈화 되었단 것 때문에 이번에 바로 적용시키고자 함. 이번에 특히 세팅 중인 발송 관련된 서버는 aws-sdk에서 SES, SNS 밖에 안 쓰고 있기 때문에 전부 가져올 필요가 없었다. 너무 커.. aws-sdk > 모듈은 '@aws-sdk/client-' 뒤에 기존에 자신이 aws-sdk에서 사용하던 ..

> 새로 싱가폴 서비스 및 신규 서비스들이 오픈을 하면서 기존 서비스 안에 깔려있던 Email, SMS 발송을 담당하던 코드를 분리할 필요성이 생겼고 이 때 새로 Notification Server를 만드는데 여기 framework는 nestjs를 사용해보고자 여기 정리하면서 시작해본다. > express는 웹 프레임워크이기 때문에 지금 개발하는 Notification API server는 더 적합하다 생각했음. 그래서 추후 리팩토링 과제로도 express -> nestjs로 변경하는게 남아있는거 > 일단 가장 먼저 '어? 이게 있구나'하고 느꼈던 강점이 module의 유무였다. nestjs 공부를 더 하고 더 개발을 하다보면 다르게 느낄 수 있겠는데 기존 typescript express로 개발을 할 ..

DB 성능 최적화 스터디 시작하면서 어떤 목차를 다루고 공부할지 정리하고 스터디 계획 짬 ~ 현재 회사 개발에 가장 밀접한 내용을 위주로 다루려고 선정함 (마스터, 슬레이브는 아직 개발하지 않아서 내용에서 제외) MYSQL 아키텍처 (1~32) : MySQL의 아키텍쳐와 스토리지 엔진에 대한 내용을 다루고 있으며 트랜잭션을 비롯한 RDBMS의 기본에 대해 다룬다. 병목지점 찾기 (35~89) : 벤치마킹과 프로파일링 : 서버의 작업량이나 처리 속도에 대해 판단할 때 영향을 주는 요소에 대한 이야기로 주요 변경 전후에 application을 벤치마크해서 변경 사항이 얼마나 효과적인지 판단해야 하는데 변경 사항이 부정적인 영향을 주는지 긍정적인 영향을 주는지에 대해 측정하는 법을 다룬다. 벤치마칭 (35~6..

엄청 간헐적으로 'JavaScript heap out of memory'이라고 말하며 test가 죽어버리는 일이 발생하기 시작 > 간헐적으로 발생하고 다른 개발자분들도 동일하게 발생. 다시 돌리면 사라짐 메모리 누수 때문인거 같아서 시작하였다. + 기존 전체 커버리지 테스트 (Service단의 전체 테스트)를 돌리면 너어어어어어무 오래 걸리는게 항상 걸렸다. 평균 테스트 커버리지는 80% 내외로 총 테스트 갯수는 900정도 됨 > 최근 토스 세션에서 말하길 해당 개발자는 약 1400개의 테스트가 걸리고 1분이 넘어가서 리팩토링을 시작하였다고 하였다. 즉 우린 무조건 손을 봐야하는 수준인거 (4/30일 기준 914개 2분 35초) 이렇게 오래걸리는 이유와 상당한 연관이 있어보였음. > 누군가가 테스트를 무..

- TDD의 핵심 expect에 대해서 얼마나 다양하게 많은지, 각각의 함수에 대해 어떤 상황이 적합한지 정리해보자 expect().toBe() : 인스턴스 비교를 할 때보단 값을 비교할 때 사용하는 것이 더 적합하다. 인스턴스를 인스턴스 내부의 property값들이 전부 같은지 비교하기 위해 toBe를 쓰게 된다면 서로 다른 객체라고 결과를 내보냄 expect().toEqual() : 인스턴스 값들을 체크하고자 한다면 toEqual이 적합하다 test('dummy test', () => { const data = {id : 3}; data['content'] = 'test case'; expect(data).toEqual({id: 3, content: 'test case'}); }) expect().t..

- jest의 장점 중에 하나인 모킹(mocking)에 대해 정리한다. mocking이란 : ' mock = 모조품 ' 뜻 그대로 받아드리면 된다. 즉 테스트하고자 하는 코드가 의존하는 function이나 class에 대해 모조품을 만들어 '일단' 돌아가게 하는 것이다. 대표적인 예로 내가 테스트해야하는 코드 속에 전부 완료되고 나서 이메일을 발송해야하는 기능이 있다면? 테스트를 돌릴 때마다 이메일 발송하는 부분이 실행이 되어서 찐으로 이메일을 보내거나 이메일 발송에 문제가 있으면 내가 테스트 하고자 하는 부분과 상관없이 계속 테스트 결과는 Fail이 떨어질꺼 그래서 이럴 때 email보내는 부분을 '모킹'한다~ 라고 함 mocking 처리 : 함수를 개별적으로 모킹할 땐 jest.fn(), 모듈 덩어리..

이번 장은 실제 오픈 소스 라이브러리를 리팩로팅하는 페이지이다 TestCode의 커버리지는 최대한으로 높여야 한다. 그리고 테스트 코드의 버그는 없어야 한다. 주석 변경까진 이력 변경은 하지 않아도 되고 불필요한 주석은 바로바로 지워야 한다. 클래스, Function의 이름은 적절하게 지어야 한다. static final 상수 모음보다 enum을 사용한다. 부모 클래스는 자식 클래스에 대한 정보를 모르는 것이 구조적으로 옳다. if의 연쇄도 enum으로 옮길 수 있다. 일반적으로 Function 인수로 플래그 값은 바람직하지 못 하다...

이 장의 내용을 한줄로 요약하자면 멋진 코드는 절대 한번에 나오지 않는다. 오히려 한번에 내보내려고 하면 안 된다. 1차 초안 쓰고 2차 초안을 만들고 그리고 최종안을 만드는 것처럼 공예하듯 만들어야 한다. 일단 프로그램이 돌아간다고 다음 업무로 넘어가선 안 된다. 점진적인 개선 이 파트 자체가 책에선 양이 엄청난데 이건 코드가 대부분이라 긴거 인자 값을 받아서 Parse하는 함수를 따로 만들어져있고 일단 변수로 할당하고 parse로 따로 다시한번 돌린다. parse도 변수들을 전부 parse해버리는 함수임 변수도 타입별로 맵이 전부 나뉘어 져있었음 딱 저번에 말했던 지나치게 짜잘하게 function으로 나누면서 갯수가 너무 많아져버림 그렇다고 제대로 나눈것도 아녀 한 함수에 여러 기능을 부여한 경우도 ..

깔끔한 코드를 구현하기 위한 4가지 규칙! 모든 테스트를 실행하라 설계는 의도한 대로 돌아가야 한다. 모든 테스트 케이스를 항상 통과해야한다. 이 때 테스트가 불가능한 시스템이 있는데 이는.. 항상 논란의 여지가 있다. 과연 검증이 불가능한 시스템을 둬야하는가 왜 테스트 코드를 짜야하냐면 결합도가 높아지면 테스트 코드를 작성하기 힘들어지기 때문에 테스트 코드를 짜다보면 결합도도 낮아진다. 리팩토링 테스트 코드를 모두 작성하였다면 이제 코드와 클래스를 정리하라 이 때 코드를 정리하면서 다른 기능을 해치는거 아닐까 걱정하지 않아도 된다. 1번 테스트 코드를 전부 작성하였다면! 시스템 관심사를 모듈로 나누고 이름을 좀 더 기능에 적합하게 수정하고, 중복 코드 제거, 클래스 메소드 갯수를 최한으로 줄이는 단계이..

* 창발성이란 : 개별적으로는 보이지 않던 것들이 집단으로 보면 보이게 되는 것을 말한다. -> 즉 아래 4가지 규칙들을 개별적으로 사용되면 티가 안나는데 이 4가지를 동시에 활용할 때 가시적인 효과를 얻을 수 있다~ 이런거인둡 깔끔한 코드를 구현하기 위한 4가지 규칙! 모든 테스트를 실행하라 설계는 의도한 대로 돌아가야 한다. 모든 테스트 케이스를 항상 통과해야한다. 이 때 테스트가 불가능한 시스템이 있는데 이는.. 항상 논란의 여지가 있다. 과연 검증이 불가능한 시스템을 둬야하는가 왜 테스트 코드를 짜야하냐면 결합도가 높아지면 테스트 코드를 작성하기 힘들어지기 때문에 테스트 코드를 짜다보면 결합도도 낮아진다. 리팩토링 테스트 코드를 모두 작성하였다면 이제 코드와 클래스를 정리하라 이 때 코드를 정리하..