N° 01 — 목록
'refactoring' (2)
-
Software Architecture/DDD & PatternsDDD Patterns - 10. GoF 디자인 패턴
공구함의 도구는 자리가 있다 — GoF 23개 패턴이 빛나는 자리와 어둡게 되는 자리작은 스타트업에 입사한 주니어를 하나 상상한다. GoF 디자인 패턴 책을 막 다 읽은 그는 첫 업무로 '게시글 좋아요' 기능을 맡았다. 그의 손은 LikeService를 만들기 전에 LikeServiceFactory부터 갔다. 인터페이스를 정의하고, 구현을 분리하고, 빌더로 조립하고, 프록시로 감쌌다. 리뷰 시간에 선배가 물었다 — "좋아요 기능 하나에 클래스가 아홉 개인 이유가 뭔가요?" 주니어는 자신 있게 답했다. "확장성이요." 선배는 한참을 보다가 조용히 PR을 닫았다. 6개월 뒤 그 코드는 좋아요 카운터에 버그가 생겼을 때 다섯 개의 파일을 함께 읽어야 하는 원인이 됐다.이 이야기의 교훈은 "패턴이 나쁘다"가 아..
-
Software Architecture/FoundationsFoundations - 05. 기술 부채와 의사결정
대출을 받아 출하한다 — 기술 부채의 본질사업자가 대출을 받아 지금 투자하면, 지금 가치를 얻는 대신 이자를 치른다. 상환 계획이 있으면 현명한 선택이고, 없으면 파산으로 이어진다. 소프트웨어에서도 비슷한 일이 벌어진다. 출시일을 맞추기 위해 결제 모듈의 카드 번호 길이 검증을 건너뛰고 코드 옆에 // TODO: 출시 후 추가를 달아둔다. "출시 후"는 오지 않는다. 6개월 뒤 한 사용자가 잘못된 카드 번호로 결제를 시도하고, 검증 없는 시스템은 그걸 승인 처리해 버린다. 환불 비용과 고객 신뢰 하락이 그 TODO 주석의 이자였다.이것이 기술 부채(technical debt)다. "나중에 고치지"로 미뤄둔 결정이 이자를 치는 현상. 이 은유는 널리 쓰이면서도 자주 오해된다 — 부채를 "나쁜 코드"와 동일..