<div id="readability-page-1" class="page"><div><p>3주간의 프리코스를 마치고 최종 코딩테스트를 봤다.<br>
이번 테스트에서 만족스러웠던 점은 dto객체를 사용해본 것이다. 저번 미션을 MVC패턴으로 구현하던 중에 View클래스에서 도메인 객체에 의존성을 가지는 것에 의구심이 들어서 찾아본 결과 해결책으로 dto객체를 사용해보기로 했다.<br>
처음 시도해봤을 때는 DTO(Data Transfer Object)는 흔히 계층간 데이터 교환을 위해 사용하는 객체라고 해서 이 말대로 모든 계층 간 데이터를 교환 할때 dto를 사용해봤다. 이 과정중에 서비스 레이어에서 필요한 도메인 객체의 비즈니스 로직의 결과 값을 dto객체로 반환하기가 애매했다. 그래서 찾아본 결과 DTO는 단순히 계층간 데이터를 전달할 때 사용하지만, 그것이 필수는 아니라는걸 알게됐다. 그래서 서비스 레이어에서만 dto 객체를 생성해서 사용해줬다. 결과적으로 View클래스가 기존 도메인 객체 대신 dto객체에 의존성을 가지게 되어 도메인 객체의 역할을 축소할수 있었다.<br>
반면 아쉬웠던 점은 구현 중에 중복되는 상태값과 로직이 있어 추상클래스나 인터페이스의 사용 필요성을 느꼈지만 적용하지 못한 점이였다. 또한 구현 중 설계한 부분 이외에 추가적인 객체가 필요한 상황이 있었는데 어떻게 객체를 설계해야 할지 감이 오지 않아서 닥치는대로 구현했다. 결국 중복 코드가 굉장히 많이 나왔다. 이 과정에서 상속과 인터페이스에 대한 이해와 도메인 지식이 부족하다고 느꼈다. </p>
<p>테스트 결과에 대한 큰 기대하지 않고 이번에 느낀 부족한 점들을 중심으로 공부를 이어나갈 계획이다. 화이팅하자</p>
<p>참고자료:<br>
<a href="https://tecoble.techcourse.co.kr/post/2021-04-25-dto-layer-scope/">DTO의 사용 범위에 대하여(tecoble)</a></p>
<p><a href="https://www.inflearn.com/questions/139564">DTO의 사용시기 질문(인프런 김영한님의 답변)</a></p>
<hr>
<p>11월 24일 1차 미션을 시작으로 약 한 달가량 시간이 정말 빨리 흘러간 것 같다. 3개의 미션의 요구사항과 매주 받은 피드백에 적합한 코드를 짜기 위해 고민하고 공부하며 시간을 보냈던것 같다.</p>
<p>처음 기능 구현목록을 작성하는 것부터 쉽지 않았지만, 이 과정에서 설계를 어떻게 하면 좋을지 충분히 깊게 생각할 시간을 가질 수 있었고 여태껏 항상 하나의 프로그램만을 바라보고 절차적인 기능들만을 생각하며 설계했던 내 모습을 발견할 수 있었다. 여태껏 코딩할 때 무작정 구현해 나가며 그 끝을 가늠할 수 없는 불안함 속에서 해왔던 것 같다. 이 부분을 개선하기 위해서 스스로 찾아보며 어떻게 어디까지 설계하면 좋을지 기능만이 아닌 구조와 계층의 설계 부재가 문제점이라는 것을 파악했고 매주 이 부분을 보완해서 매주 미션에 녹아내기 위해서 노력했다.</p>
<p>메서드를 분리하고 클래스를 분리하고 서로 관계를 맺어 하나의 프로그램을 만드는 과정에서 자연스럽게 객체지향 프로그래밍에 관해 공부하고 있는 나는 발견할 수 있었다. 지금 와서 돌이켜 보니 요구사항과 피드백들이 단순히 제한사항이 아닌 공부의 방향을 제시해주는 힌트였다는 생각이 들었다.<br>
지난 한 달간 내가 이해하고 있다고 착각했던 것들이 무엇이었는지를 알게 해준 시간이었고 이를 통해 앞으로 어떻게 공부해 나가면 될 것인지 방향성을 잡아준 소중한 시간이었다. </p></div></div>

0_0_yoon.log

yoon

3주간의 프리코스를 마치고 최종 코딩테스트를 봤다. 
이번 테스트에서 만족스러웠던 점은 dto객체를 사용해본 것이다. 저번 미션을 MVC패턴으로 구현하던 중에 View클래스에서 도메인 객체에 의존성을 가지는 것에 의구심이 들어서 찾아본 결과 해결책으로 dto객체를 사용해보기로 했다. 
처음 시도해봤을 때는 DTO(Data Transfer Object)는 흔히 계층간 데이터 교환을 위해 사용하는 객체라고 해서 이 말대로 모든 계층 간 데이터를 교환 할때 dto를 사용해봤다. 이 과정중에 서비스 레이어에서 필요한 도메인 객체의 비즈니스 로직의 결과 값을 dto객체로 반환하기가 애매했다. 그래서 찾아본 결과 DTO는 단순히 계층간 데이터를 전달할 때 사용하지만, 그것이 필수는 아니라는걸 알게됐다. 그래서 서비스 레이어에서만 dto 객체를 생성해서 사용해줬다. 결과적으로 View클래스가 기존 도메인 객체 대신 dto객체에 의존성을 가지게 되어 도메인 객체의 역할을 축소할수 있었다.
반면 아쉬웠던 점은 구현 중에 중복되는 상태값과 로직이 있어 추상클래스나 인터페이스의 사용 필요성을 느꼈지만 적용하지 못한 점이였다. 또한 구현 중 설계한 부분 이외에 추가적인 객체가 필요한 상황이 있었는데 어떻게 객체를 설계해야 할지 감이 오지 않아서 닥치는대로 구현했다. 결국 중복 코드가 굉장히 많이 나왔다. 이 과정에서 상속과 인터페이스에 대한 이해와 도메인 지식이 부족하다고 느꼈다. 
테스트 결과에 대한 큰 기대하지 않고 이번에 느낀 부족한 점들을 중심으로 공부를 이어나갈 계획이다. 화이팅하자
참고자료: 
DTO의 사용 범위에 대하여(tecoble)
DTO의 사용시기 질문(인프런 김영한님의 답변)
11월 24일 1차 미션을 시작으로 약 한 달가량 시간이 정말 빨리 흘러간 것 같다. 3개의 미션의 요구사항과 매주 받은 피드백에 적합한 코드를 짜기 위해 고민하고 공부하며 시간을 보냈던것 같다.
처음 기능 구현목록을 작성하는 것부터 쉽지 않았지만, 이 과정에서 설계를 어떻게 하면 좋을지 충분히 깊게 생각할 시간을 가질 수 있었고 여태껏 항상 하나의 프로그램만을 바라보고 절차적인 기능들만을 생각하며 설계했던 내 모습을 발견할 수 있었다. 여태껏 코딩할 때 무작정 구현해 나가며 그 끝을 가늠할 수 없는 불안함 속에서 해왔던 것 같다. 이 부분을 개선하기 위해서 스스로 찾아보며 어떻게 어디까지 설계하면 좋을지 기능만이 아닌 구조와 계층의 설계 부재가 문제점이라는 것을 파악했고 매주 이 부분을 보완해서 매주 미션에 녹아내기 위해서 노력했다.
메서드를 분리하고 클래스를 분리하고 서로 관계를 맺어 하나의 프로그램을 만드는 과정에서 자연스럽게 객체지향 프로그래밍에 관해 공부하고 있는 나는 발견할 수 있었다. 지금 와서 돌이켜 보니 요구사항과 피드백들이 단순히 제한사항이 아닌 공부의 방향을 제시해주는 힌트였다는 생각이 들었다.
지난 한 달간 내가 이해하고 있다고 착각했던 것들이 무엇이었는지를 알게 해준 시간이었고 이를 통해 앞으로 어떻게 공부해 나가면 될 것인지 방향성을 잡아준 소중한 시간이었다.

우테코 프리코스 및 최종 코딩테스트 후기

댓글