여러분들은 코드를 작성하실 때 어떤 방식으로 시작하고, 끝을 맺으시나요?
저는 개발해야하는 순간이 다가오면 잠깐의 고민을 하고 바로 키보드를 두들기며 코드를 작성합니다.
이 방식이 잘못되었다는 것은 아니지만, 저는 제 습관을 고치고 싶습니다.
코드를 작성하다보면 무엇을 짜고 있는지 가끔 방향을 잃을 때도 있고, 명확하지 못한 코드들이 남발하게 되며, 나중에 코드를 보게 됐을 때 기억이 나지 않는 등의 문제를 겪곤 합니다.
그래서 앞으로는 코드를 작성하기 전에 저만의 규칙을 만들어보고자 합니다.
사진의 모든 출처는 다음과 같습니다.
TWT 규칙
'TWT' 규칙을 처음 들어보시나요? 그럴 수 밖에요.. 제가 만들어낸 규칙이거든요 ㅎㅎ
'TWT'이란 Think Write Test의 약자로 생각하고, 코드를 작성하고, 테스트 하자는 내용을 귀엽게 나타내봤습니다.
Think 단계
이 단계에는 내가 구현하고자 하는 것이 무엇인지 생각하는 단계입니다. 예를 들어 방치형 게임을 만들겠다고 생각하겠습니다. 방치형 게임에는 방치 시스템이 필요하고, 방치 시스템을 만들기 위해서는 어떤 시스템이 필요한지 등을 생각하는 단계입니다.
이 단계에서 가장 중요한 것은 머리로만 생각하는 것이 아닙니다.
손으로 설계도를 그리든, UML을 작성하든 시각적으로 나타낼 수 있는 무언가를 적어가며 생각하는 단계입니다.
생각은 잊혀지게 되지만, 시각적으로 그려진 것들은 사라지지 않습니다.
그래서 저는 UML를 그리는 방법을 배우고 있으며, 이 포스팅에서는 짧고 간단하게 설명해보고자 합니다.
UML이란?
UM은 Unified Modeling Language의 약자로, 시스템 및 소프트웨어 개발 과정에서 사용되는 표준화된 시각적 모델링 언어입니다.
UML을 작성할 때는 구현할 시스템이 존재하고, 해당 시스템을 코드로 작성하는 것보다 UML로 시험해보는 쪽이 비용이 적게 들때 사용합니다.
또는, 1)시스템의 구조와 동작을 시각적으로 표현하여 이해하는데 도움을 주거나, 2) 시스템의 설계를 문서화할 때, 3)개발자들간의 의사소통을 돕기 위한 수단으로 사용할 수 있습니다.
🔽 사진 예시는 표 아래에 있습니다 🔽
| 관계 | 설명 | 예시 |
| 일반화 | 한 클래스가 다른 클래스를 상속받는 관계 | 동물 클래스가 포유류, 조류 클래스를 상속 |
| 실체화 | 추상 클래스나 인터페이스를 오버라이딩하여 실제 기능을 구현하는 관계 | 인터페이스 ' IFlyable'이 클래스 '비행기'를 구현 |
| 의존 | 한 클래스가 다른 클래스를 사용하는 관계 | 주문 클래스가 결제 클래스를 사용 |
| 연관 | 두 클래스가 연관되어 있지만 각각 독립적으로 존재하는 관계 | 학생 클래스와 과목 클래스 간의 연관 |
| 직접연관 | 두 클래스 간의 연관이 바로 가리키는 관계 | 주문 클래스와 고객 클래스 간의 직접 연관 |
| 집합 | 한 클래스가 다른 클래스를 포함하는 관계 | 부서 클래스가 직원 클래스를 집합 |
| 합성 | 한 클래스가 다른 클래스를 라이프타임 동안 포함하는 관계 | 자동차 클래스가 엔진 클래스를 합성 |
일반화의 경우 상속받는 클래스들이 부모 클래스를 가리키고 있습니다.
이때 실선과 삼각형 화살표 조합으로 이루어져 있습니다.
실체화의 경우 2가지 표기법으로 나타낼 수 있습니다.
왼쪽 표처럼 <<interface>>를 나타내어 점선 표기 및 삼각형 화살표로 나타낼 수 있으며, 우측 사진처럼 인터페이스를 동그란 원으로 나타내고 실선으로 나타낼 수 있습니다.
의존은 하나의 클래스가 다른 클래스를 참조할 때 사용할 수 있습니다. " 객체생성/객체 사용/메서드 호출/객체 리턴/매개변수로 해당 객체를 받는 것 등" 다양한 형태로 참조할 수 있습니다.
User Class의 경우 Schedule Class를 참조하고 있습니다. 이때 객체 참조를 계속 유지하고 있지 않으며, 해당 함수를 사용하면 참조는 끝이납니다.
점선과 화살표의 조합으로 나타낼 수 있습니다.
연관은 하나의 클래스가 다른 클래스를 사용할 때 사용할 수 있습니다.
의존과 달리 연관의 경우 클래스 내부에서 타 클래스를 선언하고 있으므로 해당 클래스가 사라지기 전까지 계속 참조를 하는 형태를 띄게 됩니다.
두 클래스가 서로 연관이 있는 경우 실선으로 나타내며, 하나의 클래스가 다른 클래스를 사용하는 경우에만 실선과 화살표 조합으로 나타냅니다.
Wrtie 단계
이 단계에는 Think단계에서 생각한 것을 토대로 코드를 작성하는 단계입니다.
Think 단계에서 제대로 설계도를 만들어 냈다면, 그 설계도를 바탕으로 빠르게 코드를 작성해나가면 됩니다. 물론, 설계도에는 기능만 적혀 있을 뿐, 알고리즘(구현 방식)이 적혀 있는 것이 아닙니다.
따라서 Write단계에서도 기능을 구현할 때 반드시 많은 생각을 통해 효율적으로 코드를 작성해야 합니다.
유니티로 예를 들자면, 캐릭터를 Think단계에서 설계했고 기능적으로 움직인다는 내용이 포함되어 있을 때, Update문을 통해 캐릭터를 움직이는 알고리즘을 작성해야 합니다.
이때, 캐릭터를 움직이기 위해 Rigidbody를 사용하는데 Update에 매번 GetComponent를 호출하는 방식을 사용하게 되면 비효율적인 코드가 되므로 이런 부분에 있어서는 코드를 설계할 때 미리 염두해두고 있거나, 코드를 짤 때 주의해야 하는 부분입니다.
Test 단계
이 단계에는 Write 단계에서 구현한 기능을 테스트하는 단계입니다.
이때 주의하실 점은 코드를 짜고 테스트하고 코드를 짜고 테스트하라는 소리가 절대 아닙니다.
소프트웨어 개발 3대 원칙 중 하나인 코드를 'Dry' 하게 짜라라는 소리입니다.
Think 단계에서 설계를 제대로 했고, Write 단계에서 코드를 제대로 작성했다면 Test 단계는 마지막 단계에서만 이루어지면 됩니다. 중간 중간 단계에서 계속 수시로 Test를 하게 된다면 많은 시간 낭비와 피로가 쌓이게 될 것입니다.
저는 앞으로 제가 직접 만든 TWT 규칙을 저 스스로에게 적용해서 개발할 때 반드시 지켜보고자 다짐하고 있습니다.
앞으로 코드를 짤 때 반드시 UML과 같은 수단을 이용해서 시각적으로 설계도를 그리고, 그것을 바탕으로 코드를 작성하는 습관을 가지겠습니다!