안녕하세요. 블로그 주인 "초보프로그래머" 입니다.

드디어 일상이란 카테고리에 첫 번째 게시물을 작성해보네요.

하지만 일상이라고 해서, 갑자기 큰 주제에서 벗어나는 것 보다는 그래도 개발 블로그니, 개발과 관련된 생각과 일상을 적어보려고 해요. ㅋㅋㅋㅋ

그 중, 첫번째 주제로 잡은 것은 UML을 그려보자라는 것이었습니다.

사실 문서화라는 것이 정말 귀찮은 작업이고, 작성했다 하더라도 누가 찾아볼까라는 생각도 되서 등한시 하고 있었는데, 이번에 인수인계 받은 로직을 리팩토링하며 UML을 그려보는 것이 어떨까에 대한 생각이 들었습니다.

갑자기 그 생각이 든 것은, 어찌보면 간단한 이유입니다.

객체지향적으로 프로그래밍한다? 디자인 패턴을 잘 활용한다? 분명 이 생각을 가지고 코딩을 수행하다보면, 분명 클래스의 개수가 기하급수적으로 늘어납니다. ㅡㅡ^ (리팩토링 전 모든 로직들이 Spring 프레임워크 기반의 서비스 클래스에 정의되어 있지만, 리팩토링 후 클래스들이 많이 생겼습니다. 즉 봐야할 클래스가 많아진 것이죠.)

짜임새있게 만들어진 구조라면 "변화에 유연한 개발자가 되자" 라는 것에 부합할 수 있겠지만 아무것도 모르는 사람이 보면 그냥 복잡하게 짠 코드로만 보일 것입니다. 

아래는 트리와 비슷한 개념을 코드로 표현하기 위해서, 컴포짓패턴을 사용한 것인데 모르는 사람이 보면 그냥 난감합니다. 하지만 어떤 트리의 개념이 추가된다면 AbstractApprovalDepth 클래스를 상속받은 구현클래스를 작성하여 위치에 맞게 child를 명시한 곳에 추가하면 됩니다. 모르면 그냥 모르죠.....

무언가 모순이지 않나요? 

유지보수 좋으라고 여러 패턴 도입하며, 개발을 했는데 남이 보면 복잡합니다. ㅡㅡ^

그래서 UML을 문서화하며 모든 부모클래스에 해당 UML을 언급하면 그나마 보기 좋지 않을까에 대해 고민해보게 되었습니다. 

원래 인스턴스를 만드는 것은 클래스 구조를 보았을 때, 가장 하위클래스를 사용하는 것이 적절하기 때문에 모든 비지니스 클래스에 UML을 넣는 것은 조금 그렇고(귀찮아질듯?), 어느정도 틀이 되는 인터페이스나 추상클래스에만 UML을 참고하게 하여 처음보는 사람이 부모클래스를 하나라도 타고 가면 UML을 볼 수 있게하자 라는 전략으로 해보려고 했습니다.

그래서 프로젝트 하나 몰래 만들고, ㅋㅋㅋ (아직 선배님들은 아무도 모르는게 함정..)

말머리는 다음과 같이 해보았습니다. 프로젝트의 취지입니다. 

첫 번째 이슈 작성!

이슈에는 목적을 명시하고 UML 올렸습니다. UML만 올리면 살짝 부족한 느낌이 있더군요. 그래서 살짝 코멘트도 같이 올렸습니다. (DB의 ERD처럼 관리가 잘되었으면 좋겠습니다. ㅜㅡㅜ)

UML을 명시했으니, 코드와 연결을 해야겠죠...

상위 클래스에 가서,

이렇게 연결을 해주었습니다. 문서화가 과연 도움이 될까요?