(레거시 시스템) 개편의 기술 - 배달 플랫폼에서 겪은 N번의 개편 경험기, 권용근 을 듣고.
개편 시작하면서 사전에 미리 다지고 가야할 부분들을 이라던지,
개편을 대비해서 미리 잘해두면 좋은점들을 알려주셨다.
특히 4장의 가시성 확보 부분은, 프로젝트를 시작하기에 기초적인 얘기들 이었지만 개인적으로 여유가 없어서 생략되거나 못챙기는 부분들이 많았다.
하지만 발표자는 기초적인것을 강조했고, 훨씬 짧은 기간이 주어져도 챙기는 모습이 감명깊었다.
그밖에도 더 열악한 환경에서도 개선을 이루어낸 점을 보고 나는 엄살이었구나 싶다.
1. 의존성을 한 방향으로 정리하다
각 레이어마다 깊이(뎁스, 또는 레벨) 을 둬서 한쪽으로만 흐르게 해서 스파게티 코드를 줄인다.
eg. Controller -> Service -> Domain
역방향은 당연히 다른방향이고
같은 레이어의 참조도 다른 방향이라고 봐야한다.
예를들어 aService (2) -> bService. (2)
이경우엔 공통기능을 다른 하위 기능(3)으로 추출하자.
이때 3에 문제가 생기면 다 전파된느것 아냐? 할수도 있는데, 여기서 말하고자 하는건 관측성이 좋아진다. (사이드이펙트를 추적할수 있게된다)
2. 변경 대상에 대한 경계를 나눈다
계층이 명화하게 되어있지 않은 시스템인경우에 대해 설명.
1. 변경대상을 모듈이나 패키지로 아예 나눠 버린다.
2. 계층에 책임과 역할을 정의해주면 된다.
3. 테스트를 확보한다
테스트 확보는 안정감을 줄수 있다.
발표자는 언어, 프레임워크, 데이터베이스까지 바뀌면서 기존 tc 를 재사용이 불가한 경우.
다음과 같이 json Diff 를 이용해서 테스트를 했다.
테스트원칙은 인터넷이 안되는 상황에서도 돌아가야 하지만, 이렇게라도 해서 테스트를 확보했다고 한다.
4. 프로젝트 가시성 확보
일정을 예측해야 일정에 대한 리스크를 더 잘 관리할수 있다.
엑셀이든 뭐든 우리의 기준에 맞춰서.
도메인을 뽑고 서브도메인을 뽑고. 초기에 일정 기록 필요
- 일정을 관리할수 있다
- 서로 뭘 하고있는지를 알수 있다. -> 내 개인일정을 계획할수 있다.
- 개편이 길어지면서 지칠수 있다. 어디쯤 왔는지 알수있다
- 이해관계자들을 설득하기 위한. 이 프로젝트를 후원하기 좋아진다.
부록
도메인 이해 차이가 크면 모두가 힘들다
- 잘 아는사람은 부담감이 큼. (내 의사가 곧 결론)
- 모르는 사람은 쫓아가는데만 해도 힘듦
- 두 그룹은 서로간의 의사소통에도 많은 비용이 듦
이벤트스토밍을 하면서 해결할수 있다.
도메인에서 무슨 일이 일어나고있는지 빠르게 알아내기 위한 워크샵 기반 방법
DDD 를 떠나서도 좋은 방법이 된다.
결론
지금 꼭 개편을 하지 않더라도, 유지보수하기 좋은 소프트웨어를 만들어야한다.
