QnA
코드리팩토링을 하며 일급 객체를 추가하며 인수타입/반환타입을 변경하며 코드 전체적으로 수정할 곳이 많다. 괜찮은가? 리팩토링을 하면서 코드 여기저기 수정이 일어나는건 어쩔 수 없다고 생각합니다 오히려 긍정적인 신호일 수도 있는데요.생각지도 못한 곳에서 까지 빨간색 밑줄이 쳐진다면 너무 많은 의존관계를 맺고 있던 것이므로 리팩토링 포인트에 대한 신호로 쓸 수 있습니다.다만 이렇게 대대적인 리팩토링을 할 때 경계해야 할 것은 빨간줄을 지워가면서 눈에 보이는 개선사항들을 처리해가면 커밋 단위가 너무 커진다는 것입니다.커밋 단위를 작게 하면서 변경을 해주신다면 큰 문제 없을 것 같습니다!!로또 당첨번호객체는 그냥 당첨번호로 현실에서는 사람이 직접 자기 로또랑 비교하지 그에 대한 결과를 비교하는건 사람과 같은 객체가 있어야하거나 헬퍼 클래스가 있어야 하는거 아닌가?객체지향 프로그래밍은 객체가 스스로 일을 하도록 하는 프로그래밍입니다 당첨번호는 당첨 번호로써만 있으며 다른 클래스에서 정보가 필요할 때 정보를 제공하는 역할만 한다면 절차 지향 언어인 C 언어의 구조체에 가까운 모습일 것 같네요 객체를 객체스럽게 사용하도록 리팩토링해라.라고 포비가 포스팅해두신 글 이 있는데 이 글이 도움이 될 것 같습니다!!개발을 하다보면 연쇄적으로 여러곳을 건드리면서 커밋의 범위가 크고 넓어지는데 어떻게해야할까?코드를 작성(수정)함에 있어 처음 목표로했던 것만을 작업 후 커밋하는걸 목표로 한다.1. 큰 숫자는 가독성을 위해 언더바(_)를 사용하자.
//worst case
int price = 2000000000;
//good case
int price = 2_000_000_000;
Java
복사
2. 상황에 맞는 콜렉션을 잘 사용하자.
예를들어 로또번호는 1~45의 숫자중 중복없이 6자리를 골라야 하는데, 이 때 그냥 단순히 List 콜렉션을 사용하게 되면 중복을 허용하기 때문에 로직에 실수가 생기면 동일한 숫자가 들어 갈 수 있고, 이를 처리하기위해 따로 로직을 구현해야 한다.
하지만, Set 의 경우 중복을 허용하지 않기 때문에 이런 경우에는 List 보다는 Set이 더 어울린다.
3. 반환타입이 Object인 것은 피하자.
기본적으로 Object는 cast가 필요하고 시그니쳐를 봤을 때 무엇을 리턴하는지 파악하기가 힘들다.
4. 스스로 상태는 갖지않고 파라미터 가공 밑 반환만 하는 클래스는 유틸성 클래스로 만들어라.
멤버변수를 가지고 있지 않은 클래스를 인스턴스화 해서 사용 하면 메모리만 소비할 뿐이다.
