기능 외 요구사항
프리코스에선 미션의 요구 사항이 다음과 같다. 과제 진행 요구 사항, 기능 요구 사항, 프로그래밍 요구 사항
우선 과제 진행 요구사항에서 원하는 건
1. 마구잡이로 진행하지 마라, 문제를 해결하기 위해선 기능 분리와 정리가 우선되어야 한다.
2. 과제의 버전 관리와 커밋명에 신경써라
라고 느꼈다.
또한 프로그래밍 요구 사항에선 JDK21 버전 환경과 우테코의 자바 코드 컨벤션을 지키는 것을 요구했다.
기능 요구사항
앞선 요구사항에 맞춰 README에 구현 기능을 정리했다.
https://github.com/seogwoojin/java-calculator-7/tree/seogwoojin
처음엔 큰 기능 3개만 작성했는데, 기능 개발에 들어가면서 내가 너무 요구사항을 대강 작성했구나 라고 깨닫게 됐다. 😥
이후 도메인 별로 큰 요구사항을 설정하고, 도메인 별 세부 요구사항과 그에 속하는 디테일한 제한 조건을 거는 식으로 요구사항을 리팩토링했다..
기능은 크게 개발적으로 어려운 부분들이 없었으나 요구사항에서 모호한 부분이 아주 많았다.
실제로 현업에 가게되면 대체로 그런 애매한 요구사항에 맞춰 진행하기에 아마 개발자로서 이런 애매한 요구사항을 어떻게 해석할 지 고민해보는 마음에서 이렇게 내신 것 같다.
우선 나는 최대한 요구사항의 워딩 위주로, 또 몇안되는 예시에서 힌트를 얻어 진행했다.
아무래도 주관을 최대한 빼고 싶었기 때문이다.
진행하면서 배운 것
아키텍처 패턴
무작정 클래스를 분리 하지말고, 기능에 맞는 아키텍처 패턴을 선택하는 것이 좋을 것 같았다.
처음에 기능만 놓고 분리했더니, 어떤 기능을 수행하는 코드가 어디에 있는 지 가독성이 떨어졌다.
그래서 무난무난한 MVC 패턴을 적용하기로 결정했고, 리팩토링을 진행했다.
제어의 흐름을 담당하는 Controller, 비지니스 로직과 정보들을 담당하는 Model, 입출력을 담당하는 View 3가지로 분리하니 흐름을 보고 싶으면 컨트롤러를, 내부 기능을 보고 싶으면 모델을 참고하면 돼서 편했다.
TDD
사실 테스트 코드를 그렇게 좋아하지 않았던 내 자신을 반성하고 있다.
단위테스트를 통해 함수의 동작이 잘 이루어지는 지 보거나 에러를 명확하게 발견하기 쉽고
통합테스트를 통해 여러 예외적 상황을 찾아볼 수 있었다.
실제로 대부분의 에러는 이 코드를 통해 찾을 수 있었고, TDD의 또 한가지 장점은 TEST 코드가 다른 사람에게 내 코드에 대한 설명이 될 것이다.
다음으로 클린코드
코드를 작성하는 데에는 컨벤션이 존재한다는 사실을 알게됐다.
우테코에서 적절한 가이드라인이 제공되는 점이 좋은 것 같다. (사실 내가 찾아봐야 하는데)
구글 자바 스타일 코드를 우테코가 조금 변형한 코드고 매번 적용하기 어려워서 나는 인텔리제이에 코드 포매터를 등록해서 저장마다 컨벤션이 유지되도록 설정했다.
들여쓰기, 공백 등도 내 코드의 일부분임.
또 함수 하나에 한 개의 기능만 수행하는 것, 함수명 변수명을 적절히 짓는 것(축약X!)에도 집중하면서 코드를 작성했다.
개인적으로 클린코드를 하는 이유는 1. 가독성, 2. 유지보수성 두가지라고 생각하고 실천하고 있다.
2주차부턴..
- 또 기능을 명확하게 분류하고 예외 사항들을 꼼꼼히 고려하여 개발 과정 중 요구 사항 변경을 최소화하겠습니다.
- 이번 주에도 컨벤션을 지키며 개발하겠습니다.
- TDD를 더 깊이 공부해 테스트 중심 설계를 해보도록 하겠습니다.
'회고' 카테고리의 다른 글
@RequestBody - Json Data의 null은 왜 0 이 됐을까? (0) | 2025.01.16 |
---|