3줄 요약: 내부적으로 여러 상태(state)를 가지는 모듈을 작성할 때는, 곧바로 코드부터 작성하기 시작하면 좋지 않습니다. (특히, 본인이 좋은 구조를 한번에 설계할 역량이 있지 않다고 생각할때는요.)
코드를 작성하기 이전에 상태전이도를 Uml을 사용해 작성해보는것을 추천합니다.
서론
운동선수가 먼 거리를 뛰려면 도움닫기를 하듯이, 여러 상태를 가지는 복잡한 요구사항을 만족시키는 코드를 작성하기 위해서 또한 비슷한 동작이 필요하다는것을 알고 계시나요?
본론
이미 작업 이전에 전체적인 그림을 그리지 않고 바로 코드를 작성하기 시작하면, 결과물이 만족할 만한 퀄리티가 나오지 않았었던 경험이 있을것입니다.
그 이유는 전체적인 그림을 조망하며 설계하지 않으면 빠트리기 쉬운 엣지 케이스가 발견되기 때문인데요,
특히 "상태" 를 가지고 있는 view Logic 인 경우 상상하기 힘든 다양한 실패 루트를 코드를 작성해가는 와중에 바로 알아채기는 쉽지 않았었습니다.
pseudo-code 의 어려움
이때, 흔히 의사 코드 (pseudo-code) 를 작성해보며, 자신이 작성하는 코드를 머리속에서 검증해보는데요.
이미 경력과 실력이 충분한 개발자분들의 경우 이 단계로서 충분하지만, 의사 코드로 "무엇을" 해야하는지 잘 모르는 주니어 개발자의 경우에는 단순히 코드를 IDE 에 작성하냐, 아니면 종이, 혹은 텍스트 에디터에 코드 비슷한걸 다시 되풀이하고, 이 단계를 수행하면서 얻을 수 있는 이점을 가져가기는 쉽지 않은것이 사실입니다.
제가 느꼈었던 어려움은 대략 다음과 같은데요,
- 코드의 로직을 어디까지 기술해야하는지 알기 힘들었었습니다. (예를들어 사용하는 프레임워크에 해당하는 로직을 작성하면, 이는 과연 유사 코드라 할 수있는지.)
- 반대로 생략해야 하는 로직은 어디 까지 생략해야하는지 알기 힘들었습니다. (극단적으로 내부 로직은 모두 적당한 이름의 메소드 안에서 수행된다고 가정하고 작성하면, 유사 코드를 작성하는 큰 의의가 느껴지지 않았습니다.)
Test case 구성의 어려움
또한, TDD 프로그레밍으로 피처를 개발해 나갈때도 유사코드를 사용할때와 비슷한 어려움을 반복하여 느꼇었는데요.
로직을 작성하기 이전에 해당 피처의 테스트케이스를 작성하고 개발을 진행하지만,
어디까지 테스트해야하는지, 어떤 부분은 테스트를 하지 말아야하는지에 관해서 그 경계점을 짚기가 상당히 힘들었었던 기억이 있습니다.
또한, 작성한 모든 테스트케이스를 만족하는 코드를 개발완료 했더라도, 과연 이 케이스가 피쳐의 완결성을 보장한다고 느껴지기 힘들었습니다.
몇번의 어려움을 반복 한 이후, 제가 생각한 이런 어려움을 느끼게 하는 근본적인 이유는 바로 view logic이 "상태"를 갖고있기 때문이라는것을 알게되었습니다.
하지만, 그렇다고 상태를 가지지 않는 구조로 피처의 요구사항을 바꾸자는건 있을수 없는 일이기 떄문에,
가능한 구조의 완결성을 보장하는 설계를 할 수 있는 방법에 대해 여러 방면에서 알아보았는데요,
상태전이도
제가 현 시점까지 알게된 방법중에 가장 좋은 결과를 보장했었던 방법은 바로, 상태 전이도(State-transition-diagram)를 그리는 방법입니다.
상태전이도를 작성해야하는 근거
그 이유는 상태를 가지는 모든 모듈은, 유한상태머신(Finite-State-Machine)으로 기술 될 수 있기 때문입니다.
따라서 완결성 있는 구조를 보장하는 FSM 을 설계한 뒤, 그 구조를 그대로 코드로서 이식하기만 하면,
적어도 처음 설계에서 가정한 전제와 요구사항에 한해서는 완결한 구조를 보장 할 수 있게 됩니다.
상태전이도를 작성하면 얻을 수 있는 이점
이 뿐만이 아니라, 상태전이도를 작성할 시에 얻는 이점은 다양한데요,
- 모듈이 요구사항을 만족하기 위해 몇 가지의 상태를 가져야 하는지 코드를 작성하지 않고 검증 할 수 있습니다. (이는 상태의 가짓수를 줄여 코드의 가독성과 유지보수성에 기여합니다.)
- 상태전이도에서의 "전이" 는 "이벤트" 혹은 "테스트케이스" 로 볼 수 있고, 전이로 변경된 "상태" 는 검증값으로 생각할 수 있습니다. 상태전이도의 그림이 모듈의 모든 기능을 내포하므로, 이에 기반해 테스트케이스를 작성하면 자연어에 가까운 검증 로직을 작성 할 수 있게 되고, 구조의 완결성을 보장 할 수 있게됩니다.
- 동료 혹은 미래의 자신에게 코드보다 가독성이 좋은 다이어그램을 제공 할 수 있게됩니다.
예상되는 단점
하지만 이러한 상태전이도를 작성하면 전이도와 현재 피처과 동일하다는것을 보장해야합니다.
피쳐를 처음 개발할때야 위의 조건의 어렵지 않지만, 몇번의 패치와 리팩터가 진행된 이후에도 여전히 "전이도" 즉 그림에 대해 동기성을 만족하라는 요구사항은 자칫 개발에 집중해야할 시간을 오히려 그림을 자르고 오려붙이는데 더 많은 투자를 해야하는 비효율을 가지라는 것으로 들릴 수 있다는것을 이해합니다.
보완책
하지만 걱정하시는 부분은 Uml 을 사용하면 상당부분 해소 할 수 있습니다.
PlantUml을 위시한 여러 Uml을 git 저장소의 문서 탭에서 관리한다면, 이러한 상태전이도를 관리하는데 들게되는 노력은 마크다운 문서를 관리하는 노력과 큰 차이가 없게됩니다.
결론
따라서 본인의 조직이 TDD를 적극적으로 도입하고 있거나, 혹은 본인의 view logic의 완결성을 보장하는데 어려움을 느끼는 FE 개발자라면, 위와 같은 이점을 가져갈 수 있으니 다음 피처를 진행 할 때 부터 상태 전이도를 먼저 작성해보는것을 강력하게 추전합니다.
