형식을 바꾼 이유
지난 1주 차에는 전체적인 플로우와 함께, 각 단계에 따라 필요한 클래스와 메서드 및 변수까지 아주 상세하게 정의했으나, 몇몇 이유로 형식을 조금 바꾸었다.
이번 미션은 어느 정도 미션 사이클에 익숙해지기도 했다. 그리고 무엇보다 로직은 리팩토링 등으로 언제든지 바뀔 수 있기에, 로직을 바꾸면 추후 기능 명세까지 변경해야 하는 번거로움이 있었다. 절차에 따라 상세하게 기재해 두면 How에 대해서는 더 좋은 방법으로 바꿀 수도 있어야 하는데, 사고가 갇히는 느낌이 들기도 했다.
정리하자면
이번에는 How보다는 예외사항을 포함해 해당 기능에서 구현되어야 하는 What을 중심으로 적었다.
requirement.md
위와 같이 두 가지 방법으로 적어보았다. 하나는 절차 지향으로 How를 간단하게 적고, 하나는 객체 지향으로 각 객체가 어떤 역할을 해야 하는지를 적어서 전체적인 구조를 생각했다.
객체지향? 함수형?
사실 요즘 프론트 쪽에서는 함수형 프로그래밍이 대세라지만, 우테코에서는 객체 지향 프로그래밍을 지향하는듯해서 객체 지향 프로그래밍을 지향하기로 했다. 물론 프로그래밍 방법이 무슨 대수냐 싶긴 하겠다만, 이번 기회에 다양한 프로그래밍 방법을 학습하며 적용하려는 노력 그 자체가 충분히 의미 있을 것 같았다. 정답은 없다. 본질적으로는 요구사항 파악이니까.
본질에 대한 생각
그러니 절차 지향이든, 객체 지향이든 하나의 문제를 다양한 시각에서 보기로 했다. 절차 지향으로 단계를 하나하나 짚으면서 게임 단계별로 구현해야 하는 기능이 무엇인지 파악했다. 그리고 각 MVC 패턴을 공부하면서 각 객체의 역할을 어떻게 배치할지 고민했다.