1.유틸리티용으로 사용하는 클래스에서 기능 미지원해서 복잡하게 돌아가야하는 경우가 있었음
그 기능 쓰려고 호출하는게 프론트단도 사용하는거라 프론트단 코드, 백엔드 타 도메인 일부 코드도 수정해줘야했는데
사실 유틸리티 클래스만 수정하면 그만인 상황. 특히 타 도메인 (타 팀에서 관리)코드를 우리꺼 쓰자고 수정하는게 부담스러운 상황
2.근데 유틸리티 클래스는 모든 도메인에서 사용중이고 삑사리나면 큰일나는 상황이라 만들어진 이래로 하나도 수정한적 없음. 이거 잘못만져서 법적문제 생기면 어떻게하냐 테스트 할 인력도 없다
3.그래서 결국 동일한 유틸리티에 기능만 확장한 클래스를 하나를 더만들면 어쩌냐? 하는데 그렇게 하면 기존 유틸리티클래스랑 충돌이 발생안하는거 확신하냐? 그 유틸리티는 이전에 외주로 만든건데 내가수정하면 유지보수 책임은 어떻게되는거냐? 등등 또 새로운 문제들이 나옴
4.제일 수정범위 좁으면서 문제소지 적은 방법이 내가 쓰는 기능만을 위해서 호출하는 부분을 아예 분리하는거. 근데 완전 동일한 기능을 보여주는데 프론트랑 백에서 호출하는부분이 다르다고 분리하는게 말이되냐? 이거 추후에 중복로직 제대로 관리할수있냐..
여기서 대부분의 금융권에선 결국 중복로직으로 문제 해결함.
왜 금융권 코드가 중복에 누더기골렘이 떡칠이 되어있는지 알수있는 날이였음 ㅇ.ㅇ
누가 똥 위애 똥을 쌓아올린다고하는데 그런느낌인가
ㅋㅋ 똥젠가
기존 똥의 로직이 절대 잘못되면 안됨. 고객한태 통지하나 잘못가는것만으로 몇억이 깨질수도있음
토스는 그런거 다 마이그레이션 성공했다 ㅇㅅㅇ