조건문 Refactoring
if ~ else문은 꼭 필요하면서도, 프로젝트를 복잡하게 만드는 요소입니다. 잘못 사용한다면, 열심히 개발한 프로젝트가 최악의 프로젝트가 될 수도 있죠.
조건문을 작성하면서 많은 개발자 분들이 실수하고 있는 부분들을 담을테니 참고해주세요!
1. return true; / return false;를 사용하지 마라!
조건 절이 Boolean 반환 값을 가지는데, 굳이 if ~ else문을 사용하면 코드가 복잡해집니다.
[Bad😢]
public boolean isAdmin(User user) {
if(user.role == UserRole.ADMIN) {
return true;
} else {
return false;
}
}
[Good😍]
public boolean isAdmin(User user) {
return user.role == UserRole.ADMIN;
}
2. 삼항연산자를 사용하라!
함수가 flag에 따른 return값을 가진다면, 삼항연산자를 쓰는 것이 바람직합니다.
[Bad😢]
public int getPrice(User user) {
if(user.role == UserRole.ADMIN) {
return 5000;
} else {
return 10000;
}
}
[Good😍]
public int getPrice(User user) {
return user.role == UserRole.ADMIN ? 5000 : 10000;
}
3. 다중 if문을 사용하지 마라!
클린 코드에서는 if문이 1번도 많다고 하고, 정말 많이써봐야 2번이라고 합니다. 따라서, if문을 적절히 메서드로 분리하는 것이 중요합니다.
[Bad😢]
public void getMedal(User user) {
if(user.role == UserRole.USER) {
int rank = repository.getRanking(user);
if(rank <= 3) {
user.medal += 1;
}
}
}
[Good😍]
public void getMedal(User user) {
if(user.role == UserRole.USER && isRanker(user)) {
user.medal += 1;
}
}
조건문 개선안은 꾸준히 나오고있습니다.
부정문 처리를 먼저 해서 return으로 탈출을 시켜야 한다, return은 가능한 적게 호출해야 한다, 와 같은 내용도 있었지만,
그런 부분들은 정답으로 보기 어려운 것 같다고 생각해서 뺐습니다.
더 공부해서 2편으로 찾아오겠습니다.
감사합니다.
'Programming > Refactoring' 카테고리의 다른 글
DTO를 Inner static class로 간결하게 관리하기! (+ domain 분리) (0) | 2022.04.16 |
---|---|
리팩토링 - Switch문을 다형성으로 바꾸기 (0) | 2022.02.27 |
리팩토링 - 반복문 분리 (split loop) (0) | 2022.02.26 |
리팩토링 - 메소드 올리기 (Pull up method) (0) | 2022.02.20 |
리팩토링 - 함수 추출 (Extract function) (0) | 2022.02.19 |