오늘 배운 것

• 내 코드를 남에게 설명하는 과정이 곧 내가 내 코드를 이해하는 과정이다.

UML 클래스 다이어그램

여러가지의 다양한 UML이 있지만 가장 대중적으로 많이 쓰이는 클래스 다이어그램에 대해 알아보자.

클래스 다이어그램?

한 타입의 특징과 서로 다른 타입 간의 관계를 파악하기 위한 다이어그램

UML?

소프트웨어 공학에서 사용되는 표준화된 모델링 언어

모델링 언어?

객체 지향 프로그래밍에서 소프트웨어 집약 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화 할 때 사용되는 언어

명세화?

분명하고 자세하게, 완전한 모델을 만드는 것을 의미함

UML이 왜 필요한데?

UML은 같은 같이 일하는 동료, 그리고 바로 미래의 나 자신을 위해서 필요하다.

먼저 동료 개발자와 협업이 필요한 상황이 존재한다면 내 코드를 보여주어야 한다. 하지만 프로그램이 커지면 커질 수록 내 코드 역시 계속해서 커질 수 있고 그럴 수록 추후에 동료에게 내 코드에 대해 설명하고 이해시키는 것은 보통 일이 아닐거다. 그럴 때 UML로 작성한 문서가 있다면 동료 개발자는 더 쉽게 내 코드를 이해할 수 있을 것이고 협업과 의사소통 과정에서 시간을 많이 절약할 수 있을 것이다.

미래의 나는 지금의 내 코드를 절대 100프로 이해할 수 없다. 당장 내일만 되어도 내 코드를 설명하지 못 할수도 있다.(이건 좀 문제가 있겠는데?) 그럴 때 문서화된 자료가 하나 있다면 내가 짠 코드의 구조를 더 쉽게 떠올릴 수 있을 것이다.

주의할 점

UML은 정답이 없다.

UML을 그리는 방식에는 뚜렷한 정답이 존재하지 않는다.

이 사진의 선들만 보더라도 하나하나 구분하는게 여간 쉽지는 않다.
의존과 연관, 연관과 직접연관 등등의 구분이 명확하게 지어져 있지 않기 때문에 모두가 통일되게 사용하진 않는 것 같다.

TIP

UML이 너무 복잡해진다면 상위 개념에서 생각해보기, 파트 별로 쪼개보기

꼭 지켜야하는 법칙은 없다!! 의사소통이 목적이기 때문에 상대방이 알아볼 수 있게만 작성하는 것에 중점을 두자