UML

연휴 [1] 를 마치고 출근해서 처음으로 머리써서 처리한 일은 동료 개발자 가 두레이에 남겨 놓고 간 작업입니다. 필자가 먼저 서울에 갔을 때 북경에 남아 있던 [2] 그가 갱신한 작업 내용을 보고, 필자가 '무얼 더 개선할 수 있을까?' 생각하는 일입니다. 그가 나에게 작업을 요청한 것이 아니라 우리가 서로 나눴던 의견을 상기하고, 그의 개선에 대해 살펴보는 일인 터라 매우 느슨한 협업이라 할 수 있습니다. 그는 왜 UML 그림을 그렸는가? 지난 번에 둘이 만나 나눈 이야기부터 떠올려봅니다. 매일 일상이 Go로 프로그램을 짜는 그가 굳이 UML 도해를 그려 두레이에 공유했습니다. 필자가 Go 개발자가 아닌 탓도 있겠지만, 그가 UML로 표현하는 목적을 친절하게 써두었습니다....

역사는 반복된다. 올해도 어김없이 그 패턴 이 돌아왔다. OOO 공부하게 책 하나 추천해주세요. 이틀 전에 즉흥적으로 답했던 내용을 글로 쓰면서 더 많은 분에게 전달을 시도한다. 결론부터 말하면 세 권을 추천했다. 도메인 주도 설계 이하 DDD 중에서 빌딩 블록 관련 내용 UML을 활용한 객체지향 분석 설계 중에서 1부 개념 UML, 실전에서는 이것만 쓴다 DDD 책을 추천한 이유는 10년이 훨씬 지난 내용이지만 아직도 생생하게 쓰이고 있다는 점이다. 또한, 그 중에서 중에서 빌딩 블록으로 추린 이유는 실제 구현과 연결지으면 실효가 높기 때문이다. 두번째 언급한...

설계에 최소한의 노력만 하라 고 말하면서 UML 모델을 남용할 수는 없다. 그렇지만, 가끔 그리고 싶은 충동을 느낄 때가 있다. 대부분은 대화과정에서 즉흥적으로 매직으로 그린 경험이다. 대화할 때 흔히 쓰는 UML 도해 popit에 올려둔 글만 보아도 대화하며 설명을 위해 그린 흔적이 있다. 대략 쓰임새를 요약해보면 다음과 같다. 어떤 개념(예: 판매처가 다양할 때)을 분류하고 싶은 경우 그리는 클래스도 프로그램 호출순서를 확인 할 때 (동료 코드를 보고, 호출 순서에 대해 묻거나 제안할 때) 순차도 작성...

개발자들과 대화를 통해 설계를 개선하는 상황에 대한 글입니다. 이번 글에서는 권한 관리 기능에 대한 설계를 어떻게 진행했는지에 대한 글입니다....

팀원들간에 가볍게 소통하면서 설계에 참여하는 경험 공유입니다....