Spring을 이용하여 개발할 때 고민, 클린코드 짜기, 코드리뷰 항목

개발자라면 자신과 팀원들을 위해서 깔끔한 코드를 짜야 한다. 나도 항상 잘 짜고 싶고 고민이 많아 해당 블로깅을 통해 정리를 해놓으려고 한다.

 

1. 최소한의 정성은 들였는가? ( 중복, 단일 책임원칙, 의미를 담은 상수 )

먼저 기본적으로 살펴볼 목록은 이정도 인 것 같다.

• 코드에 중복된 부분은 없는가?
• 코드가 무엇을 하는 것인지 이해가 불편하지 않은가?
• 코드가 자신이 있어야 할 자리에 있는가?
• 앞으로 변경이 일어난다면 어떤 것이 있을 수 있고, 그 변화에 쉽게 대응할 수 있게 작성 되었는가?

// 읽기 편한 코드를 만들자!
private boolean canUpgardeLevel(User user){
	Level currentLevel = user.getLevel();
    switch(currentLevel) {
    	// case BASIC : return user.getLogin() >= 50;
        case BASIC : return user.getLogin() >= MIN_LOGCOUNT_FOR_SILVER;
        
    	// ...
    }
}

// 변화에 유연하게 대응하자 ( 업그레이드 정책이 특정기간에만 변경된다면? )
public interface UserLevelUpgradePolicy {
	boolean canUpgradeLevel(User user);
    void upgradeLevel(User user);
}

그리고 일에 치여 대충대충 짜다보면, Spring @service 단 코드에 모든걸 때려박는 괴물 코드를 만들기도 한다. 

2. 객체지향적인 코드를 짰는가?

객체지향적인 코드는 다른 오브젝트의 데이터를 가져와서 작업하는 대신 데이터를 갖고 있는 다른 오브젝트에게 작업을 해달라고 요청해야 한다.
즉, 데이터를 요구하지말고 작업을 요청하는게 기본 원칙이다!

// 객체지향적으로 짜자 ( Service 단 코드 )
private void upgradeLevel(User user){
	user.upgradeLevel();
    userDao.update(user);
}

// User.java
public void upgradeLevel(){
	Level nextLevel = this.level.nextLevel();
    
    // exception 처리 코드
    this.level = nextLevel;
}

3. 테스트 하기 좋은 코드인가?

테스트 코드를 작성해야 하는 이유는 사실 안정성을 위해서이다. 하지만 나는 이것만큼 중요한 이유는 테스트 코드 작성으로 인해 코드가 깔끔해 진다는 것이라 생각한다. 테스트 코드를 작성하기 편하려면(하나씩 테스트하려면) 결국 역할 분리와 특정환경에 종속되는 코드를 작성하면 안되기 때문이다.

 

// 테스트 하기 좋은 코드를 위해서 특정 환경에 종속된 코드 작성하지 않기
@Setter
public class UserService {

	// 여기에 테스트용 MockMailSender와 실제 SMTPMailSender 필요한 것을 DI 하면 된다.
	private MailSender mailSender;
    
    private void sendUpgradeEmail(User user){
    
    	SimpleMailMessage mailMessage = new SimpleMailMessage();
        mailMessage.setTo(user.getEmail());
        // ...
        
    	this.mailSender.send(mailMessage);
    }
}

4. 제대로된 함수인가?

1. 서술적인 이름을 잘 사용하였는가?
   - 코드를 읽으면서 짐작했더 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드 ( 좋은 이름이 주는 가치는 아무리 강조해도 지나치지 않다 )
2. 함수인수가 4개를 넘어가는가?

5. 변수명은 제대로 지었는가?

• 의미를 제대로 담고 있는가? ( 밑에 url 참고 )
• 쓸데없는 접두어를 붙이지 않았나?

참고 : https://happyer16.tistory.com/entry/Clean-Code-3%EC%9E%A5-%ED%95%A8%EC%88%98

Clean Code 3장 - 함수

참고 - Spring Clean Code : https://medium.com/@madhupathy/ultimate-clean-code-guide-for-java-spring-based-applications-4d4c9095cc2a

Ultimate Clean Code Guide for Java, Spring based Applications

6. SOLID 잘 지켰니?

1) SRP 단일책임원칙

 

스프링을 하다보면 자신이 DI를 지키면서 잘 짰다고 착각하게 된다. 인터페이스 주입하고 구현체에 방대한 서브시스템을 만들면서.... 인터페이스 분리할 수 있는지 고민해보자.

서로 변하는 시기와 성질이 다른 것, 변하는 것과 변하지 않는 것을 함께 두는건 바람직한 설계구조가 아니다. 서로 관심이 다른 코드들은 분리하고, 서로 코드에 영향을 주지 않으면서 유연하게 확장 가능 하도록 DI를 적용해보자.

2) DIP는 잘 지키고 있니?

• 어떤 변수가 구상 클래스에 댛나 래퍼런스를 저장하고 있는가???
• 베이스 클래스에 이미 구현되어 있던 메소드를 오버라이드 한거 아니지???

3) OCP

• 달라지는 부분을 찾아서 나머지 코드에 영향을 주지 않도록 "캡슐화"를 하였는가?
• 또 한번, 나중에 어떻게 바뀔 것인가를 체크했나???