방학이 끝나가기 이틀 전, 체스 미션 회고록을 작성하고자 한다.
너무 오랜 시간이 지나고 쓰다보니 기억이 생생하진 않다.
따라서 했던 고민들을 왜 했고, 현재는 해당 고민에 대해 어떻게 생각하는지에 대해서만 작성하려고 한다.

역시 회고록은 따끈따끈할 때 작성해야한다..!

설계에 대해

당시 페어와 함께 거의 하루 온종일을 설계하는 데에 사용했다.
특히 이때 전반적인 클래스 구조를 생각하는 것이 아니라 세부 구현 방법에 대해서도 같이 고민을 했다.
그러다보니 밑그림 자체도 그려지지 않았고, 이거 미션 끝낼수나 있을까 싶었다.

그래서 다음 날부터 바로 일단 부딪혀보자는 마인드로 시작했다.

머리로만 설계하고 구상했던 내용들이, 직접 부딪혀보니 생각했던 것과 전혀 다르게 흘러가는 것도 있었다.
하지만 탁상공론을 하는 것보단 훨씬 진전이 있었다.

체스 미션 피드백 시간에 설계에 관해 네오에게 질문했다.

"미션이나 프로젝트를 시작함에 앞서 설계를 할 때, 어느 정도까지 설계를 하며 얼만큼 시간을 가지나요?"

많은 크루들도 의견을 달아주었고, 네오도 질문에 대한 답변을 해주었다.
모두 공통적으로 큰 그림만 대충 그려놓고, 바로 구현을 한다고 했다.
그리고 가장 와닿았던 의견으로는 달리가 이야기해준 마시멜로 챌린지이다.

요구사항 분석

기존에 요구사항 분석을 다음과 같이 했다.
주요 객체들의 역할과 책임이라는 대제목을 작성하고, 그 아래에 필요할 것 같은 객체들을 작성한다.
그리고 그 객체 아래에는 해당 객체에게 어떤 역할을 위임할 것이며, 어떤 책임을 가질 것인지 작성했다. 이때 구현 세부 사항도 함께 작성하려고 했다.

이번 체스 미션도 위처럼 했다. 그러다보니 계속해서 변경되는 설계에 따라 요구사항 분석도 계속해서 수정이 되었다.
시간에 쫓기며 구현하는 상황에서 요구사항 분석을 같이 관리하는 것을 포기하여 결국 작성하지 않았다.
그냥 단계별 요구사항만을 작성했다.

객체지향의 사실과 오해 책을 모두 읽은 지금 시점에서 '이랬으면 어땠을까?' 하는 생각이 든다.

1. 프로그램 요구사항을 대제목으로 작성하고 그 아래에 사용자의 입력을 포함한 전체적인 프로그램의 흐름을 작성한다.
2. 작성한 프로그램 요구사항을 바탕으로 주요 객체들을 작성하고 그 아래에 해당 객체가 가질 역할과 책임을 작성한다. 이때, 구현 세부사항이나 자세한 행위는 작성하지 않는다. 해당 객체가 어떤 메시지를 수신할 것인지만 집중한다.
3. 요구 사항에 작성한 기능을 하나씩 TDD 방식으로 구현한다.

테스트 메서드 네이밍

이때까지만 해도 테스트 메서드 네이밍에 대한 내 기준은 다음과 같다.

methodTest() or methodTest_exception()

그런데 문득 테스트 메서드 네이밍에 대한 더 나은 기준이 궁금해졌고, 리뷰어 코다께 질문했다.
답변으로 이 링크를 공유해주셨다.

위 링크를 읽고나서 드는 생각이, 기존 내 방법으로 할 경우 테스트 메서드를 보고 어떤 메서드를 테스트하는지 명확하게 파악할 수 있지만 프로덕션 코드의 메서드 네임을 수정한 경우 테스트 코드도 함께 수정해주어야 하는 관리 포인트가 늘어나는 단점을 가진다.

따라서 테스트 코드는 단순히, 해당 테스트에 대한 설명을 적어주기로 기준을 변경했다.

예를 들어 addTest() 에서 더한_결과를_반환한다() 처럼 메서드 네임과는 관련이 없지만 해당 메서드가 하려는 목적에 대해 작성하는 식으로 변경했다.

instanceOf의 사용을 지양하자

처음엔 Board에서 각 기물의 종류에 따라 검증 로직을 나누었다.
그러다보니 instanceOf의 사용이 자연스러워졌고, instanceOf의 사용을 지양하자 라는 링크와 함께 피드백 받았다.

간단히 말해 instanceOf 사용은 추상화 계층을 무너뜨린다.