-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[4기 - 이홍섭] 1~2주차 과제: 계산기 구현 미션 제출합니다. #186
base: hongxeob
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
안녕하세요 홍섭님. 라이브 코드리뷰 피드백 반영하시느냐 고생 많으셨습니다.
함께 이야기 했던 내용중, 적용 안된 부분과 아쉬운 부분들이 있어 리뷰로 몇자 남겼습니다!
자기주도적 코드리뷰를 통해 많은 배움을 얻을 수 있었습니다. 다만 아직까지 패키지 분류를 어떻게 하면 좋을지 고민이 많이 됩니다.
-> 여러 방법이 존재합니다. 비슷한 역할을 하는애들끼리 모아두면 관리하기에 더 좋겠죠?
도메인 주도로 응집, 계층 구조 고려, 기능 또는 모둘별로, 유틸리티랑 설정 분리 등등
앞으로 개발하시면서 다른사람들 패키징, 또는 라이브러리나, 프레임워크들의 패키지 구조를 보신다면 잘 모아두신걸 보실 수 있습니다.
경험하시면서 늘으실거라 생각합니다.
코드 중 유효성을 체크하는 Validator 클래스가 있습니다. 여러 종류의 계산기가 생겼을 때 유틸성으로 사용하기 위해 static을 사용하였습니다. 다만 non-static 메서드로 만들고 인스턴스성으로 사용하여 필요한 곳에만 주입 시켜주는게 나은지 고민입니다.
- 저의 의도는 나중에 다양한 형식의 계산기(컨버터)가 생길 수도 있을 것을 고려해 다양한 곳에서 쓰려고 static으로 만들었습니다.
-> 홍섭님의 의도를 제가 이해한바에 따르면, 다양한 형식의 컨버터가 생긴다면.. static일수록 코드를 직접 건드리고 수정해야 하는 경우가 많아질것 같은데요 ?
커밋시 커밋 단위를 잘 쪼개었는지, 또 깃 커밋 메세지 컨벤션에 의거해서 커밋 메세지를 잘 쓰고 있는지 잘 모르겠습니다.
-> 팀 바이 팀, 케이스 바이 케이스라고 생각합니다. 커밋단위가 다 다르더라구요.
지금 커밋 내역 보니 그래도 prefix를 깔끔하게 두셔서 읽기에 불편한점은 없었습니다!
처음으로 이렇게 객체지향에 관하여 생각해 보고 설계 및 구현을 해보았는데, 만약 같은 기능이지만 구현 방법에 차이가 있다면 그 중 어떠한 기준을 가지고 (개발자의 취향?, 팀의 규칙?, 사용자의 관점?) 방법을 선택하는 것이 가장 best practice에 가까워질 수 있을지 모르겠습니다.
-> 잘 하셨다고 생각합니다만, 처음이라고 하신다면.. 앞으로 더 성장이 기대가 됩니다.
저도 이부분은 흑구님과 동일한 생각인데요,
다만 프로젝트를 할 때마다 주제가 바뀌고 경험이 쌓여 더 나은방향을 고민하게 되더라구요.
혼자 개발하더라도 매번 다르고 팀의 규칙도 팀이 바뀌면 달라집니다 .
가능하면 셋 다 챙기는것이 좋습니다.
흑구님 영수님 소중한 코드리뷰 정말 감사드립니다!
1차 pr 후 답변 및 궁금한 점PR 답변
코멘트 중 궁금한 점
✅ PR 포인트 & 궁금한 점
|
// @Override | ||
// public boolean equals(Object o) { | ||
// if (this == o) return true; | ||
// if (o == null || getClass() != o.getClass()) return false; | ||
// CalculationResult that = (CalculationResult) o; | ||
// return Objects.equals(formula, that.formula) && result == that.result; | ||
// } | ||
// | ||
// @Override | ||
// public int hashCode() { | ||
// return Objects.hash(formula, result); | ||
// } | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
이런거 커밋하지 마세요.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
앗 커밋시에는 조금 더 신중하게 하는 습관을 길러보도록 하겠습니다..!
📌 과제 설명
👩💻 요구 사항과 구현 내용
✅ 피드백 반영사항
✅ PR 포인트 & 궁금한 점
자기주도적 코드리뷰를 통해 많은 배움을 얻을 수 있었습니다. 다만 아직까지 패키지 분류를 어떻게 하면 좋을지 고민이 많이 됩니다.
코드 중 유효성을 체크하는
Validator
클래스가 있습니다. 여러 종류의 계산기가 생겼을 때 유틸성으로 사용하기 위해 static을 사용하였습니다. 다만 non-static 메서드로 만들고 인스턴스성으로 사용하여 필요한 곳에만 주입 시켜주는게 나은지 고민입니다.커밋시 커밋 단위를 잘 쪼개었는지, 또 깃 커밋 메세지 컨벤션에 의거해서 커밋 메세지를 잘 쓰고 있는지 잘 모르겠습니다.
처음으로 이렇게 객체지향에 관하여 생각해 보고 설계 및 구현을 해보았는데, 만약 같은 기능이지만 구현 방법에 차이가 있다면 그 중 어떠한 기준을 가지고
(개발자의 취향?, 팀의 규칙?, 사용자의 관점?)
방법을 선택하는 것이 가장 best practice에 가까워질 수 있을지 모르겠습니다.