사내 코드에서 악취(code smell)가 난다.

2023년 1월 5일 목요일 오후 3:45
사내 코드에서 악취(code smell)가 난다.

입사하면서부터 늘 궁금한게 있었다.
이건왜이렇게 했지?
물론 보다보면 생각보다 잘 짜여진, well-made practice도 존재한다.

늘 보다보면 왜 이렇게 했지? 싶은데 사실은
왜냐는 질문은 성립하지 않는다. 그것은 그때는 최선의 코드였기 때문이다.
그때에는 어쩔 수 없이 작성했지만 지금까지도 스멜이 나는 건 어쩔 수 없는 일이다.


일단 첫번째로, 컴파일타임에 모든것들이 결정된다는 것이다.
고객이 개인고객인지, 법인고객인지도 모르는데,
개인고객이라면 인증방법으로 무엇을 선택할지 아직 결정도 안했는데,
납부방법도 마찬가지다.
코드는 이미 모든것을 알고 있으며, 거의 모든 데이터들을 준비해놓고 if문으로 분기처리를 하고 있다.

단말기나 요금제도 마찬가지다.
단말기를 선택하지 않는 '유심단독' 상품이 있다.
대부분의 요금제는 '요금제 테이블'에서 조회해오지만 모든 요금제가 그렇진 않다.
이쯤에서 컨트롤러와 서비스의 차이에 대해 생각해볼 수 있다.
컨트롤러는 컴파일타임에 이미 결정된, 동적자원이다.
서비스는 런타임에 결정되야 하며, UI(컨트롤러, viewofMvC)와 무관한 정적자원이어야 한다.
물론 컨트롤러와 1c1로 매핑되는 서비스가 있을 수도 있다.
하지만 페이지의 기능이 지나치게 많아질 경우, 리팩터링에 대해 생각해봐야 한다.
이는 화면 -> 백엔드 -> 디비로 이루어진 '저장' 기능외에도
디비 -> 백엔드 > 화면 순서로 이루어진 게시판상세와 같은 조회성업무도 마찬가지이다.
아니 디비에 뭐가 어떻게 저장되있을 줄 화면이 알고 컴파일타임에 모든것을 결정하는가?
물론 페이지는 이미 결정된 사항이다. 컴파일타임에
기획자의 화면설계나 사업부서의 사업구상안이 그렇다.
디비도 마찬가지이다. 어떤테이블의 어떤컬럼에 어떤 데이터가 들어가야할 지는 이미 컴파일타임에서 결정되ㄴ 사안이다.
하지만 코드는 다르다. 변경가능성이 존재한다.
그래서 PDD(페이지 주도개발), DDD(데이터베이스 주도개발)이 나쁘다고 한것이다.