코드숨 8주차 교육과 겹쳐서 많은 시간을 투자하진 못 했지만.. 요구사항에 맞게 개발하여 제출했다.
아래에는 제출한 과제진행 소감이다.
1. 객체 지향 프로그래밍
객체간 협력과 책임,역할에 대해 스스로 결정하면서 개발하였는데요. 크게 게임을 실행시키는 클라이언트, 플레이어, 심판으로 나누어서 진행하였습니다. 객체에 대해 적절한 역할과 책임을 부여하고 객체간 협력을 설계하는 방법을 이 과제를 진행하면서 연습한 것 같습니다
2. 컨벤션
컨벤션을 계속 읽으면서 개발해야해서 쉽지가 않았습니다..
제일 힘들었던 것은 들여쓰기 깊이를 2이상 하지 않는 것 이였습니다
가능한 메소드로 분리해내려 노력하였지만 이게 최선일까? 더 좋은 방법은 없을까?라는 고민에 많이 빠져 개발 목적을 잊을 때가 있었습니다
3. 기능 목록을 개발하며 갱신하고 기능단위로 commit 하지 못한 것이 아쉽습니다
4. 점진적인 개선이 아니라 한 번에 많은 것을 개발하려 하여 개발 방향을 자주 잃었던 것 같습니다
- TODO 목록을 갱신하며 완전한 TDD로 개발 못 한점이 아쉽다
- 한 기능에 집중하여 TDD로 개발하지 않아서 도중에 개발 방향을 잃은적이 많다...
- 객체간 책임을 나누는 것이 힘들다
- 심판이 선수들의 숫자를 판별해줘야할까? 프로그래밍 상에서 보면 선수들이 서로 판별하면 될 것 같은데?
- 일단 숫자 판별은 클라이언트 -> 심판 호출 -> 심판이 선수들에게 숫자를 판별하라고 메시지 전송
TDD 원칙
- 실패하는 단위 테스트를 작성할 때 까지 프로덕션 코드를 작성하지 않는다.
- 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
- 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
- TDD 원칙은 너무 미래를 예측해서 오버 엔지니어링을 막기 위함이다
- 1차적으로는 도메인 로직을 테스트하는 것에 집중
- 아무 것도 없는 상태에서 새롭게 구현하는 것 보다 레거시 코드가 있는 상태에서 리팩토링 하는것은 몇 배 더 어렵다
- TODO 리스트는 계속 갱신하라
- 기능을 구현하면서 문서를 업데이트 해라
- 죽은 문서가 아니라 살아있는 문서를 만들기 위해 노력해라
- 기능 목록을 클래스 설계와 구현, 함수 설계와 같이 너무 상세하게 적지마라
- 너무 세세한 부분까지 정리하기 보다 구현해야할 기능 목록을 정리하는데 집중해라
- 예외적인 상황도 기능 목록에 정리해라
- Util성격의 기능이 TDD로 도전하기 좋다
- 테스트 가능한 부분에 대해 TDD로 도전
- TDD를 구현하기 힘든 기능을 만난다면 아주 세세하게 기능을 분리해서 TDD를 적용해야 한다.
- 분리하기 힘들다면 연습을 계속 해야한다..
- 분리하다보면 책임에 맡게 객체를 생성해나갈 가능성이 높다
- 원시값들도 객체화 하는 연습을 해보자
- 이름을 통해 의도를 드러내라 (축약하지 마라)
- 네이밍을 짓는데 시간을 투자하라
- 불용어
Info,Data,a,an,the를 사용하는 방식을 적절하지 못 하다
- 개발도구의
code foramt기능을 활용해라 - 인텔리제이 mac
Option + Cmd + L - 공백과 구현 순서도 컨벤션이다
- 불필요하게 공백 라인을 만들지 않는다
space와tab을 혼용하지 마라- 값을 하드코딩하지 마라
위의 사항들을 명심하며 2주차 과제를 진행하자
추가 조건
개선 방안
- 토프링 책을 읽으면서 템플릿/콜백 패턴을 오늘 읽어서 그런지 자동차 경주 우승자들을 가려낼 때의 조건들을 콜백으로 만들 수 있지 않을까?
- 우승자들을 가려내는 조건과 자동차가 전진하는 조건에 전략 패턴을 적용해 보았다
- TDD로 개발하면서 DFS마냥 도메인을 개발하였다
RacingCars를 개발하다가Car를 개발하고,Car를 개발해야지 하면서CarName과Forward를 개발하게 됐다.- 객체간 책임이 잘 분리되는 기분이였다
내가 생각한 객체들의 책임들
RacingCars: 자동차 경주의 책임을 가진 클래스- 차들을 출발선에 세우기
- 랜덤 값을 받아 전진할 수 있는지 구분
- 레이스를 시키는 책임
Car: 자동차 정보를 가지는 클래스- CarName과 Forward 필드를 가지는 책임
- 출력 형식에 맞게 자동차의 정보를 문자열로 반환하는 책임
- 가장 높은 점수를 전달받아 현재 차가 승리자 인지 확인
- 전진할 때
RacingCars→Car→Forward순으로 메시지를 전달한다 - 전진할 수 있는 조건은 어디서 구별해내야 할까?
Car가 구분하자 RacingCars는Car에게 전략을 담아 메시지를 전송하자
CarName: 자동차 이름을 가지는 클래스- 자동차를 생성할 때 이름 검증을 하는 책임
Forward: 움직인 횟수의 정보를 가지는 클래스- 움직인 횟수만큼
-를 반환하는 책임
- 움직인 횟수만큼
Number: 시도 횟수를 저장하기 위한 클래스- 시도 횟수 밸리데이션 책임
- 횟수가 감소하거나 양수인지 확인하는 메소드 추가
위와 같이 개발하면서 테스트 코드가 중첩되고, 메시지를 연속으로 전달해야하는 상황이 생겼다.
예를 들어, 전진할 수 있는 조건을 통과하여 전진 시키려하면 Forward까지 메시지를 전송해야 한다.
어떻게 보면 계층 형식으로 도메인에 접근하게 되었다
TDD를 생각하며 개발하니 필요없는 메소드를 작성하고 테스트하는 상황이 많았다
실제로 필요한 기능을 구현하면 이전에 작성한 메소드와 테스트 코드가 불필요한 경우가 있었다
- 개발하려는 기능에 대한 이해도가 떨어져서 그런가?
- 소프트웨어 장인
- 개발자로서 어떤 마음가짐으로 살아갈 것인지에 대한 가이드를 제시하는 책이다.
- 프로그래머라는 우리 업에 대한 자부심을 느끼고, 전문가로서의 책임과 역할에 대해 자세하게 다 루고 있다.
- 소프트웨어 장인정신 매니페스토
- 동작하는 소프트웨어 뿐만 아니라, 정교하고 솜씨 있게 만들어진 작품을,
- 변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을,
- 개별적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을,
- 고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를,
- 객체지향 생활 체조 총정리
- 함께자라기, 1만시간의 재발견, 클린코드, 테스트주도개발, 리팩토링 책 추천을 해주셨다
탈락했다. 공통 피드백에서 스스로 놓친것 같다는 부분
- 기능 목록 구현을 세세하게 TODO에 남기지 못한 것
- 개발하면서 TODO에 남기지 않고 부가적인 부분도 바로 개발했다
- 발생할 수 있는 예외케이스에 대해 고민
사전과제로 주어진 과제 자체는 간단한 문제다.
숫자 야구 게임, 자동차 경주 게임을 구현하는 것은 쉬웠다.
하지만 신경써야 할게 많다.
- TDD로 도메인 먼저 개발하기
- 객체지향적 객체간 협력과 책임, 관심사 분리하기
- 컨벤션을 지키면서 개발하기
내가 개발할 기능이 협력이라고 생각하고 도메인을 TDD로 개발하면 책임이 쉽게 분리되는 것 같았다.
RacingCars를 작성하다가Car를 작성하고,Car를 작성해야지 하면서CarName과Forward를 작성한 것
하지만 마냥 쉽지 않았다.
- 각 객체의 내부,외부를 구분하여 캡슐화를 어느정도까지 할지?
- 메시지를 어떻게 전달할지?
- 불필요한 메소드를 작성하고 그 메소드의 테스트 코드를 작성하여 리팩토링할 때 삭제하는것이 많았다.
스스로 객체의 책임과 협력을 결정하며 개발하는 것이 처음인 것 같다..
재밌엇다. 다들 사전과제만 해도 많이 배운다고 하시던데 사실이다.
"내 개발 능력이 굉장히 낮다. 내가 이때까지 작성한 코드들은 완벽한 절차지향적이었고, 되기만하는 코드를 작성했구나." 반성하게 되는 계기도 되었다
좋은 경험이였다. 6기는 내년 3,4월 중에 열린다고하니 그때 다시 도전해야겠다