들어가다…
Qmarket은 실행 코드로 구성된 서비스입니다. 아니요, 모든 것이 항상 100% 작동하는 것은 아닙니다. 분명히 오류가 발생합니다. 일부 오류는 눈에 띄지 않고 사용자가 발견하고 다른 개발자는 코드를 살펴봅니다. 때때로 핫픽스 또는 데이터베이스에 대한 직접 액세스를 통해 이 문제를 해결합니다. 이는 문제의 원인을 제대로 파악하는 데 바람직하지 않은 방법입니다.
문제는?
다음은 현재 존재하는 많은 문제 중 일부입니다.
- 비즈니스 논리는 여러 위치에서 복제됩니다.
- 귀하의 코드는 읽기 어렵습니다.
- 자동화된 테스트가 없습니다.
- 문제가 발생하면 인식하기 어렵습니다.
변하지 않는 것은 변한다는 사실뿐이다. -헤라클레이토스-
Objects and Object Oriented Facts and Miunderstandings를 읽으면서 이 문구를 본 것 같습니다. 마음에 와닿는 문구입니다. 절대 변하지 않을 것이라고 약속했던 모든 기능이 저를 실망시키지 않고 변경되었습니다. 여하튼 변화에 빠르게 적응해야 하는 현 상황에서 특히 1~3이 가장 큰 걸림돌이다. 실제로 존재하는 문제를 진단하면 분명히 더 많을 것입니다. 데이터베이스 구조, 트랜잭션, 느린 성능, 변경하기 어려운 구조… 많은 문제점을 인지하고 있지만 위의 4가지 문제점을 어떻게 해결해야할지 고민중입니다.
어떻게?
한 번에 많은 문제를 보면 머리가 아프다. 그리고 쉽게 결정하세요. 전복시키자 사실 그게 내가 들어와서 코드를 봤을 때 처음 내린 결론이었다. 아이디어는 모든 논리를 새 서버로 점진적으로 옮기는 것이었습니다.
기존 서버 코드는 javascript 기반 node.js 런타임에서 실행되고 있었습니다. 내가 가진 가장 강력한 무기도 javascript 였지만 어떤 것으로 평가되는 유형은 vscode를 notepad.exe로 빠르게 전환했습니다. 그 때문에 새로 만든 서버는 타이프스크립트를 사용했다. 물론 모든 것은 범죄입니다. (오래된 코드라 자세히 보면 전과가 있을 수도 있습니다.) vscode에서 제공하는 인텔리센스와 레드라인은 적어도 자바스크립트보다는 나았습니다.
Spring의 표면에서 약간의 영감을 얻어 서비스 계층(SomethingService)과 데이터 액세스 계층(SomethingModel이라는 표현을 사용함)의 소스 코드를 분리하려고 했습니다. 아, 그런데 실체 같은 건 없습니다. 의존성 주입도 없습니다. 이 작업의 주요 목표는 비즈니스 로직을 통합하고 (적어도) 읽을 수 있는 코드를 작성하는 것이었습니다. 나는 잘 읽었다. 저 외에는 읽을 사람이 없었습니다.
나는 winston과 morgan을 통해 요청과 본문을 파일에 기록했고, 오류가 발생하면 오류 메시지와 스택을 Slack의 “오류” 채널에 출력하도록 Slack의 웹후크를 설정했습니다. 사실 이전 서버에도 요청 로깅이 있었습니다. 다만, console.log가 같이 뜨면서 개발하면서 찍은 로그는 그냥 지옥이었다. 사실 새 서버에서는 그냥 쓰고 지웠습니다.
테스트의 99%가 작동하지 않았습니다. 서비스 계층에 대한 강력한 결합 답변을 찾지 못했습니다. (이젠 답을 어느 정도 알 것 같다. 의존성 주입을 받으면서 테스트할 때 가짜를 주입해서 테스트하면 된다. 자바스크립트는 require를 모의하는 것 같다?) 데이터베이스와 관련 없는 유틸리티 모듈만 테스트했다.
기존 코드를 새 서버로 바로 옮길 수 없어 적용해야 하는 API부터 마이그레이션을 시작했습니다. 이전 서버에서 /api로 시작하는 요청은 새 서버로 프록시되었습니다.
이제 모든 것이 준비되었습니다. 이제 시간이 있을 때 기존 코드를 조금씩 옮기는 것이 완벽합니다. 새 서버는 많이 부족하겠지만 예전 서버보다 더 할 것 같지는 않습니다.
앗, 그러고 보니 서버 개발자가 저밖에 없네요. 새로운 기능과 이전 기능에 대한 유지 관리가 나란히 수행되었습니다. 결국 예전 코드와 새 코드를 자주 봐야 했고(사실 예전 코드가 더 많이 보였다), 결국 새 코드는 몇 가지 새로운 기능이 추가된 상태에서 그냥 멈췄다.
큰일이야. 결국 레거시 v2를 만들었습니다.
다음 페이지에 계속