Skip to content

Conversation

@qwer920414-ctrl
Copy link

안녕하세요!
두번째 단계를 진행하고 있습니다.
아직 완성은 되지 않았는데, 중간에 궁금한것들이 있어서 먼저 리뷰요청 드립니다.

수강 신청 기능 요구사항을 보고 밑에서 부터 조금씩 위로 올라가며 구현하고 있었습니다.
CourSe -> Session -> Date/CoverImage/Policy/state으로 보고
CoverImage는 또 ImageType, ImageSize, ImageDimension으로 나누어지고 그 안에서부터 구현을 시작하였습니다.

요구사항에 맞춰서만 구현을 해보다가 조금씩 내용이 빠진거 같은 느낌이 들었습니다.
이걸 Session을 만드려고 보니 ImageType은 타입을 직접 입력하던가...?! 보통은 이미지 이름.타입 이렇게 등록을 하지 않을까 싶었던 부분

PaidEnrollmentPolicy에서는 Capacity에 대한 내용을 추가해서 Money와 Capacity에 대한 클래스를 구현했는데,
Session에서 수강신청(enroll으로 만들 예정입니다)을 하면, 현재 수강생을 증가하는 메소드가 필요하지 않을까 하는 부분

이런 빠진거 같은 부분은 Session 단계에서 알게되었으면 그때 다시 돌아가서 추가하면 되는 과정일까요?

해당 클래스들을 구현할때, 요구사항을 텍스트 그대로만 생각하고 개발하다보니 저런 부분들을 놓친거 같습니다.

이외에도 피드백 주시면 다시 한번 생각해보고 이어서 개발 진행하겠습니다.
( 이 후 과정은 'Session 구현 -> Sessions(일급컬렉션) 구현 -> Course 완성' 으로 생각하고 있습니다! )
감사합니다!

Copy link
Contributor

@javajigi javajigi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

질문에 답변만 하기 위해 코드 리뷰는 진행하지 않았어요.
코드 리뷰는 요구사항을 완성한 후에 진행하도록 할께요.

Q1. PaidEnrollmentPolicy에서는 Capacity에 대한 내용을 추가해서 Money와 Capacity에 대한 클래스를 구현했는데,
Session에서 수강신청(enroll으로 만들 예정입니다)을 하면, 현재 수강생을 증가하는 메소드가 필요하지 않을까 하는 부분

이런 빠진거 같은 부분은 Session 단계에서 알게되었으면 그때 다시 돌아가서 추가하면 되는 과정일까요?
A1. 맞습니다. 처음부터 요구사항 분석을 완벽히 한 후 객체 설계를 진행할 수 있는데요. 우리가 처음 요구사항을 받았을 때 모든 요구사항을 빠트리지 않고 분석하기란 쉽지 않을 수 있습니다.
도메인 지식은 프로그램을 구현하다보면 높아지기 때문에 높아지는 도메인 지식에 따라 객체 설계가 바뀌거나, 빠트린 요구사항을 추가하는 것이 당연한 접근 방식입니다.
프로젝트 진행 중 요구사항이 변경되는 경우도 다반사이기 때문에 초반에 완벽한 설계를 하는데 집중하기 보다 지속적인 리팩터링 역량이 훨씬 더 중요하다 생각합니다.

미션 마무리한 후 다시 리뷰 요청 주시면 코드 리뷰 진행할께요.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants