# J 사 과제 테스트 회고 ## 기능 * 회원가입 * 토큰기반 로그인 * 민감정보 암호화 * 복잡한 계산이 필요한 내부 비즈니스 로직 * 느린 외부 API 에 대한 처리 ## 개선 점 #### 테스트 코드 작성 부분이 미흡했다. * 기능 개발 후 바로 단위 테스트를 작성하는 것이 중요하다는 것을 깨달았다. * 간단한 기능이라고 생각해서 미뤄두었던 단위 테스트 코드가 나중에 작성하려고 하니 귀찮고 짐처럼 느껴졌다.. 그래서 오히려 작성에 시간이 더 소모되었다. #### 처음부터 너무 좋은 코드를 작성하려고 했다. * 기능적 요구사항을 만족하는 코드를 작성하고 나중에 리팩토링으로 개선해도 충분하다. #### 핵심 기능에 우선 순위와 중요도를 두고 개발해야 했다. * 중요도가 높은 기능에 우선순위를 두고 공들여 만들었어야 했다. * 부가 기능을 더 신경쓰면서 작성했다.. 로깅, 에러 핸들링 등등 * 아마도 이것은 과제 테스트 이기 때문에 당락을 결정할 변별력이 있는 기능이 있었다고 생각한다. 그 기능의 구현에서 만족스러운 품질의 코드를 작성하기에 시간이 부족했다. * 기능적요구사항은 충족하였으나 결과는 과제 전형에서 탈락하게 되었다. * 물론, 탈락의 이유를 피드백 받지는 못했으니 이것이 이유가 아닐 수도 있겠다. * 아마 핵심적인 기능은 다음과 같이 구현되었어야 했을 것이다. * 느린 API 를 비동기, 캐싱 등의 전략으로 개선하기 * 복잡한 비즈니스 코드를 함수형으로 가독성 좋고 재사용성이 높은 코드로 작성하기 #### 도메인 주도 설계, 객체지향을 고려해서 구조를 설계해 보는데... * 공부로 익힌 개념만으로 이해가 충분하다고 생각했으나, 직접 코드로 만드는 산출물에서 그렇지 않음을 깨달았다. * 도메인 객체가 어떤 로직까지 처리해야 하고 * 서비스는 어디까지 경계이고 * 유스케이스는 어떻게 할지 * 과제 후, 이것에 대한 고민은 어느 정도 정리가 되었다. * 도메인 객체는 자신의 데이터를 사용하는 메서드를 제공하는 범위 * 서비스 객체는 도메인 객체가 제공하는 메서드를 사용 함으로써 비즈니스를 표현 * 유스케이스 객체는 서비스의 메서드를 사용 함으로써 사용자의 요구사항을 표현 ## 회고 * 다른 과제 테스트와 일정이 겹쳐서 아쉬움이 남는 과제 테스트 였으나, 평소 관심을 가지고 있던 도메인 주도 설계에 한걸음 가까워지는 소중한 고민과 경험을 하게 되었다. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://programmer-jjy.gitbook.io/second-brain/technical/review/j.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.