Wiki
공통 피드백 반영
- 변수 이름에 자료형은 사용하지 않는다
- 무의식적으로 반복하던 실수. 명확한 역할과 의미를 드러내되 자료형과 자료 구조 이름을 배제한다
"생각" 이 많아지는 미션.
코드에 대한 생각
기능 자체에 대한 구상과 설계는 금방 완료했으나
그 기능의 구현에 보다 바람직한, 효율적인,
다른 사람들이 이해하기 쉬운 코드와 구조를 작성하려면 어떻게 해야 할까?
- 각각의 역할에 부합하는 기능만을 넣어 유추하고 이해하는 데 지장이 없게 설계하자
- 장황하고 타이핑이 많아지더라도 시그니처를 더 상세하게 작성하자
- 코드가 짧고 명료할수록 가독성은 향상된다
각각의 고민이 나름 상호 보완적이었는지 정확한 역할 분리 덕분에 코드를 간결히 핵심 위주로 작성 가능했다.
중간중간 역할이 애매했던 부분 또한 그 역할을 담당하는 클래스로 분리하면 된다는 기준 또한 세웠다.
설계에 대한 생각
익숙해진 레이어드 아키텍처, MVC 패턴의 구조로 클래스 구조를 설계했다.
그런데 내가 나름'알고'는 있다 생각했던 이 구조에,
- 과연 이 부분이 왜 필요한가?
- 지금 내 프로젝트에도 필요한가?
라는 질문을 스스로 던져 보았을 때, 답을 할 수 없었다.
결국 난 구조와 설계에 대해 이해하지도, 알지도 못한 채 그저 했을 뿐이었다.
understand > know > do
아쉽고 슬픈 부분이지만, 하지도 않은 것보단 낫지 않은가?
그리고 나름 경험이 쌓인 덕분인지 참고 자료와 아티클을 통해
나름 빠르게 개념과 목적은 "알" 수 있었다.
이제 그걸 직접 적용하고 시도하고 실패하며 배워갈 뿐!
테스트에 대한 생각
사실상 TDD에 대해서도 무지했던 시점에 테스트란
- 다 돌아가는 프로그램에
- 사후적으로 구현 및 적용해서
- 빌드나 배포할 때 터졌는지 확인하는
후속조치, 사후작업으로만 생각되는 부분이었다.
급작스럽게 TDD를 적용하게 되니 테스트 작성에만, 정확히는 작성에 대한 고민에만
거의 하루 가까이를 쓴 기분이다.
문법도 구조도 익숙하지 않아 여러 방면으로 뒤져보고, 코드도 뜯어보고, 공부하고
어느 정도 배운 문법으로 작성을 하려 하니 또 어떻게
입/출력, 호출과 반환, 결과 확인, 상태 변화 추적 등
각 기능에 따라 다른 동작을 테스트해야 할 지 너무나 생각이 깊어지는 밤들이었다.
그럼에도 과연 그 고통은 성장통이었는지
이번 과제에서 세운 내 기준,
- 일단 만들고
- 아니면 수정하고
를 명확히 준수하며 수없이 많은 수정을 진행한 결과, - 왜 테스트가 중요한가?
- 왜 테스트를 작성하기 어려운가?
- 테스트는 어떻게 작성해야 하는가?
에 대한 빙산의 일각의 부분엔 도달한 느낌이다.
테스트를 먼저 구현하는 것은, 결국 내가 설계한 구조를 구현하는 첫 단계라 볼 수 있다.
결국 실제 코드를 작성하고 시그니처를 짜야 테스트를 작성할 텐데,
그 과정이 바로 명세 단계의 설계를 실제 코드로 구현하는 것이기 때문이다.
그렇기에, 설계가 불완전하면 시그니처의 작성에 혼란이 오고, 수정 소요가 발생한다.
수정의 과정에서, 실행 흐름에 따라 결합된 클래스 간의 관계가 인식되고,
각 접합점들의 연결과 동작이 예상되며, 결과적으로 구현의 구체화가 가능하다.
결국 테스트는 설계와 구현 사이에서 접합점이자 강화점이 되어 주는 느낌인데,
그때그때 그런 느낌을 받으면서도 코드 작성에 급급해 제때제때 정리해놓질 않으니
지금처럼 모호한 표현밖에 작성하지 못하는 느낌이다.
이번 과제를 진행하며 생각한 부분, 고민한 내용을 더 정리하고 복습하며
더 여유롭지만 더 철저하게, 개발 중간 중간 단계에서 배우고 느낀 점을 더 상세하고 치밀하게 정리해
유의미한 기록과 내 스스로를 위한 자원을 만들어내야겠다.
날도 흐리니 5시에 가로등이 켜지는 요즘 날씨에
따뜻한 집에서 착실한 도전을 해나갈 것이다.
