첫번째 스터디

2023.02.03

나쁜 코드

💡 나쁜 코드로 프로그래머가 치르는 고통

깨끗한 코드

💡 깨끗한 코드란?

• 주의 깊게 작성한 세세한 사항까지 꼼꼼하게 신경쓴 코드. 깔끔하고 단정하게 정리된.
  
• 잘쓴 문장처럼 읽히는.
• 짐작했던 기능을 그대로 수행해야하며, 읽으면서 놀랄일이 없는. 함수명, 매개변수명, 책임 분리,,
  
• 남들이 수정하기 쉬운
• 시간이 지나도 깨끗하게 유지되는

의미 있는 이름

의도를 분명히 밝혀라!

의미있게 구분하라!

• 불용어를 추가한 이름은 아무런 정보를 제공하지 못한다.

class Product {}
class ProductData {}
class ProductInfo {}

• 중복 또한 불용어이다.
  변수 이름에 variable, 테이블 이름에 table.

getActiveAccount()
getActiveAccounts()    // 여러개 리턴이 필요할 수 있는데, 어떻게 변경하면 좋을까?
getActiveAccountInfo()

• 그릇된 정보를 피해라.

ex 1)

ex 2)

ex 3)

클래스 이름, 메서드 이름!

• 클래스, 객체 이름은 명사 또는 명사구
• 메서드 이름은 동사 또는 동사구

한 개념에 한 단어를 사용하라!

👍

의미 있는 맥락을 추가하라!

firstName, lastName, street, houseNumber, city

→ addrFirstName, arrdLastName, addrState

→ Address Class 생성

---

그래서!

💡 네이밍 그거 어떻게 잘 할 수 있는데요..?

• 개념 정리 및 일원화
  
• 그런데
  우리는 협업해서 일해야 하는데요..? 개념에 대한 이해가 다를 수 있어요!
  
  
  

✋ 그래서 제안합니다! 육하원칙을 적용한 네이밍은 어떤가요?

언제, 어디서, 누가, 어떻게, 왜, 무엇을

→ DealService.process(events)
누가 : 딜 서비스가.
어떻게 : 처리한다.
무엇을 : 이벤트들을.


operation에 따라서 처리가 달라짐.

→ SpecialShopMatchService.processCreate(events)
누가 : 특가샵 매치 서비스가.
어떻게 : 처리한다.
무엇을 : 이벤트들의 생성을.


Link Type에 따라서 처리가 달라짐.
→ SpecialShopMatchService.processTourTicketCreate(events)
누가 : 특가샵 매치 서비스가.
어떻게 : 처리한다.
무엇을 : 투어티켓 이벤트들의 생성을.

함수

작게 만들어라

👍

한 가지만 해라

💡 한 가지의 범위가 뭔데요..?

• 지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행
• 의미 있는 이름으로 다른 함수를 추출할 수 있다면, 그 함수는 여러 작업을 하는 것이다.

switch 문

public Mony caculatePay(Employee e) throws InvalidEmployeeType{
	switch (e.type) {
		case COMMISSIONED:
			return calculateCommissionedPay(e);
		case HOURLY:
			return calculateHourlyPay(e);
		case SALARIED:
			return calculateSalariedPay(e);
		default:
			throw new InvalidEmployeeType(e.type);
	}
}

• 4가지 문제점
  1. 길다
  2. 한 가지만 수행하지 않는다.
  3. SRP 유발
     코드를 변경할 이유가 여럿이다. isPayday(), deliverPay()
     - 단일책임 원칙 SRP(single responsibility principle)

         <aside>
         💡 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화 해야함.
         
         </aside>
         
         책임 : 변경하려는 이유
         
         [JPA 예시](https://stackify.com/solid-design-principles/)
         

  4. OCP 위반
     새 직원 유형을 추가할 때마다 코드를 변경해야 한다.
• 리펙토링 Switch 문을 추상 팩토리에 숨긴다. → 다형성

  public abstract class Employee {
  	public abstract boolean isPayday();
  	public abstract Money calculatePay();
  	public abstract void deliveryPay(Money pay);
  }
  
  public interface EmployeeFactory {
  	public Employee makeEmployee(EMployeeRecord r) throws InvaliedEmployeeType;
  }
  
  public class EmployeeFactoryImpl implements EmployeeFactory {
  	public Employee makeEmployee(EmployeeRecord r) throws InvaliedEmployeType{
  		switch (r.type) {
  			case COMMISSIONED:
  				return new ComissionedEmployee(r);
  			case HOURLY:
  				return new HourlyEmployee(r);
  			case SALARIED:
  				return new SalariedEmployee(r);
  			default:
  				throw new InvaliedEmployeeType(r.type);
  		}
  	}
  }

Switch 문은 단 한 번만 사용해라!

부수 효과를 일으키지 마라!

Public class UserValidator {
	private Cryptographer cryptographer;

	public boolean checkPassword(String userName, String password) {
		User user = UserGateway.findByName(userName);
		if (user != User.NULL) {
			String codedPhrase = user.getPhraseEncodedByPassword();
			String phrase = cryptographer.decrypt(codedPhrase, password);
			if ("Valid Password".equals(phrase)) {
				Session.initialize();
				return true;
			}
		}
		return false;
	}
}

checkPassword() → checkPasswordAndInitializeSession()

‘한 가지’만 한다는 규칙은 위반하지만, 하는 작업을 명시하는 편이 더 좋다.

REAL WORLD CODING

오류 코드보다 예외를 사용하라

주석

적절한 주석은 가독성을 높이고 코딩을 편리하게한다!

• 정보를 제공하는 주석
• 의도를 설명하는 주석
• 의미를 명료하게 밝혀주는 주석
• 결과를 경고하는 주석
• 중요성을 강조하는 주석
• TODO 주석