브렌쏭의 Veritas_Garage
TEST-DRIVEN-DEVELOP 기능 개발을 할때, 테스트를 상시적으로 하면서 개발이 올바르게 되고 있는지 확인하며 하는 것. 특히나 깃 커밋을 할때, 깃 훅으로 테스트 코드를 적용시키도록 하면, 테스트를 자동적으로 실행하고 테스트를 통과하지 못하는 경우에는 커밋이 취소되도록 자동화 시켜서 작업이 가능하다. 처음에 환경을 구축하는 것은 어느정도 시간이 걸리겠지만, 추후에 디버깅을 하기 위해서 들이는 수고와 노력, 그리고 적확하게 버그를 콕 집어 환경을 만드는 것이 더 어려운 일이므로, 장기적으로 이득이다. 특히나 앞서 찾아봤던 허스키를 사용한다면 깃 훅을 좀더 간편하게 활용해서 테스트 코드 적용과 통과여부를 자동화시킬 수 있으므로, 상당한 시간절약이 가능하다. 단위테스트의 경우에는 개별 기능에 대한 ..
각각의 마이크로서비스들은 따로 시작을 시켜줘야하는데, 기본적으로 ```npm run start:dev```를 여러번 하게 되는 것이라고 보면 된다. 저번에 말했듯이 겁나 까다롭고 복잡한데, 작은 서비스 모듈 하나 고치자고 전부 내리고 전부 재빌드하는 수고로움도 만만치 않게 화가 나는 일이라, 일장일단이 있다. 어쨋든간에, 각각의 서비스모듈은 전부 각자의 API를 가지고 있고, 서로 주고받아야 하기 때문에, 보내고 받는 과정이 드럽게 귀찮아지고, 특히나 프론트 단에서 보기에는 서비스마다 도큐먼트가 하나씩 생길테니 테스트에도 애로사항이 꽃피게 된다. 위 사진만 해도 플레이그라운드를 3개 열어두고 테스트 해야한다... 그런 불상사를 막기 위해서 교통정리해서 api를 제공해줄 서비스 사이즈의 리졸버가 필요한 것..
...만들다보면 커지고, 커져버리니 쪼개고, 쪼갰는데 다시 슬금슬금 커지고 그러면 다시 쪼개고, 프로젝트라 함은 여러명이 힘을 합쳐 하나의 결과물을 만드는 만큼, 그 결과도 혼자의 양보다 거대해지는 법이다. 세상은 넓고 사람은 많아서 혼자서도 뚝딱뚝딱 프로젝트를 해내는 사람들도 있지만, 어쨌든 결과물이 백에서부터 눈에 보이는 부분까지 크게 구성되어있다는 점은 달라지지 않는다. 큰 프로젝트는, -작은 프로젝트라고 하더라도- 완성된 프로젝트라면 여러 기능들이 합쳐져서 종합적으로 작동하게 되고, 개별 기능을 구현하고 그 기능들을 잘 모아서 문제없이 굴러가게끔 하는 것이 OOP스러운 접근 방식이었다. 그런데 결국 하나로 엮인 채, 빌드와 컴파일을 거치고 나면 모듈들은 설계 상에서만 분리되어있었을 뿐, 실제로 실..