날짜 수정
안녕하세요!
날짜 수정 관련해서
minusDays를 변경하는게 어째서 불편한건가요?
안에 들어가는 파라미터만 바꿔주면 되는데 불편해지는 부분이라는게 잘 이해가 안되네요
답변 1
0
안녕하세요! 질문 감사드립니다!
실제로는 더 다양한 이유가 있겠지만 가장 직관적인 이유들만 짚어보면 아래와 같습니다!
(사실 제가 불편하다고 표현 했지만 정확히는 유지보수성이 좋지 않다에 가까운 것 같네요!)
만약 해당 날짜 정보가 정책이라서 여러군데에서 사용하고 있는 기준 값일 경우 파라미터에 직접 넣는 것으로는 요구사항에서 날짜 정책 수정이 생길 경우 n개의 지점을 수정해야하는 문제와, 수정 누락이 발생 할 수 있는 문제가 있습니다
그러므로 이런 불편함(유지보수성의 불편) 때문에 minusDays 직접 쓰는 것 보다는 상수를 추출해서 사용하는게 좋을 것 같습니다날짜를 파라미터에 순수하게 넘기면 당장 코드 작성자는 이해하기 쉬우나, 추후 시간이 지나면 코드 작성자 포함, 다른 팀원이 수정하려할때 이 날짜 값이 뭔지 의미 자체가 헷갈릴 수 있습니다
그러면 수정하기 두려워지게 될 것 같구요! 그래서 이것 또한 상수 추출을 해서 사용하는게 좋을 것 같습니다!
요런 이유로 불편함이라는 느낌으로 표현했는데 설명이 조금 부족했던 것 같네요!
모쪼록 답이 되었길 바랍니다! 완강까지 화이팅입니다!
궁금한점이 여러개 생겼습니다.
1
38
1
다양한 관점의 코드 경험을 위해 개선하지 않은 코드
1
55
1
histories() 응답에 PointHistory.id를 포함한 이유가 궁금합니다/
1
44
2
SettlementTargetRepository Jquery 질문
1
48
2
부가 기능을 이벤트 핸들러로 분리하는 기준이 있을까요?
1
60
2
엔티티의 pk 를 0으로 초기화하시는 이유가 있을까요??
1
67
2
제미니님 안녕하세요!
1
77
2
개념 간 격벽 분리와 목록 조회 시 발생하는 참조 구조
1
85
2
프로덕트와 프로덕트카테고리 사이의 삭제 정책
1
76
2
새로 개발한다면 구현 순서
1
136
1
의존 방향에 대한 고민
1
125
2
어드민(Back-office)에서 예약 변경 시, '할인 조건 재검증(쿠폰 회수)' vs '기존 혜택 유지' 중 어떤 정책이 일반적인가요?
1
98
2
OrderKeyGenerator 인스턴스화 generate() 질문
1
84
1
외부 API 통합 시 데이터 제어 범위 설계 질문
1
98
1
PG 결제 승인 로직
1
130
2
QnA에서 Join 필드 표현법
1
90
1
결제서비스 콜백 동시성문제 가능성
1
110
2
굿
1
109
1
도메인/엔티티 분리 상황에서 쓰기 작업 하는 방법
1
137
2
도메인 객체와 엔티티 객체 사용
1
139
2
CouponService 의존성 의문
1
98
2
상품 목록 조회 고도화 질문
1
112
2
표현 계층에서의 접근 지점이 다양해지는것과 이를 해결하기 위한 파사드의 도입에 대해 제미니님의 생각이 궁금합니다.
1
123
2
제품상세 코드 느끼기
1
144
2