클린코드 3장 (함수), 4장 (주석)

JAVA/클린코드|2020. 6. 20. 23:04

 

함수


- 함수를 만드는 기본 규칙은 작게 만드는 것!

 

- 함수 내부에 if 문 등의 1단이나 2단 그 이상의 중첩 구조가 발생되면 안된다.

 

- 함수의 활동은 한가지 그 이상을 하지마라.

 

- switch문에 다음과 같이 한가지 작업만 해야한다는 SRP 이론과 코드의 변경이 있으면 안된다는 OCP 규칙을 위반한다. 이를 해결하기 위해서는 다형성을 이용해서 해결해야 한다.

// 문제 코드
public int calEmployeePay(Employee e) {
	switch (e.type) {
		case SALARIED:
			return calculateSalariedPay();
		case HOURLY:
			return calculateHourlyPay();
		case .....
	}
}

// 변경 내용
public interface Employee {
	int calPay();
}


public SalaryEmployee implements Employee {
		
		@Override
		public int calPay() {
				...
		}
}

public int calEmployeePay(Employee e) {
	return e.calPay();
}

- 함수 이름이 길어지더라도 서술적으로 한방에 이해가 가능한 이름이 오히려 더 깔끔하고 좋은 코드다.

  ex) includeSetupAndTeardownPages..

 

- 함수의 인수는 기본적으로 3개 까지가 사실 마지노선이라고 생각하고 그 이상은 절대 오지 않도록 해라. 인수가 있으면 함수 자체를 이해하는데 더 어려움을 겪게 된다.

 

- 인수가 늘어난다면 별도의 인수 객체를 만들어서 묶어서 보내는 게 더 낫다.

  ex) int x, int y ⇒ Point point

 

- 함수의 이름과 인자가 한꺼번에 이해가 가능한 이름에 가장 좋다.

  ex) write(name), assertExpectedEqualsActual(expected, actual)

 

- 함수의 이름과 다른 행위를 함수안에 실행 시키지 마라 ex) checkPassword() 함수내에서 사용자 세션을 초기화 한다거나 하는 행위는 자칫하면 엄청 큰 버그를 일으킬 가능성이 크다.

 

- 에러 코드를 사용하는 것보다는 try catch를 이용해서 에러 코드를 분리하는 것이 좋고, try catch블록은 모든 영역이 아닌 별도 함수내에서 처리하도록 하는 것이 좋다.

 

- 중복된 코드를 계속 양산하지 마라.

- 모든 함수와 함수 내 모든 블록에 입구와 출구는 하나만 존재해야 한다.

 

 

 

 

주석


- 잘 작성된 주석은 이해가 되지만 경솔하고 근거없는 주석은 코드를 더 이해하기 어렵게 만든다.

 

- 주석은 코드로 의도를 표현하지 못해서 실패를 만회하기 위해 적은 코드이다. 그러므로 주석을 달고 있다면 코드를 잘 못 작성한 건 아니지 잘 생각해봐라.

 

- 주석은 언제나 코드를 따라가지 못하기 때문에 언젠가 주석은 코드와 분리되어 고아가 되어버리는 순간이 오기 때문에 조심해야 한다.

 

- 저작권 등의 정보를 알리거나 외부 라이브러리 등의 사용이나 내부 규약으로 인해 어쩔수 없이 사용하는 인자 등의 부분에 대해서 명료한 설명을 위한 주석 또는 결과 값에 대한 결과에 대한 주석 정도는 괜찮다.

 

- 누군가의 공을 달거나 HTML 주석을 위해 사용하거나 근처 코드가 아닌 다른 코드에 대한 주석 등을 다는 이런 코드들은 코드 개선에 시간을 들이는 게 더 낫고 클래스 파일에 바이트나 낭비하지 말아라.

 

 

 

결론

함수

함수는 당연히 나도 의미가 있도록 사용하기 위해서 네이밍에 많은 고민을 하고 있고 같이 일하시는 분들이 잘 이해할 수 있도록 간결하게 만들려고 노력은 하고 있다. 근데 사실 프로젝트가 커지고 하다보면 쉽지 많은 않다. 흑

 

주석

주석은 15년도에 일을 시작했을 때만해도 선배들이나 주변 개발 컨벤션에서 보면 항상 주석을 달라고 되어 있었고 오픈소스로 나와있는 라이브러리들에도 자세한 설명이 기재되어 있었다. 그래서 따라하는 습관을 들였는데 주석이 말한 그대로 코드를 따라가기 어려웠고 어느순간부터는 주석이 도움이 되는게 아니라 오히려 방해가 된다는 생각을 나 또한 들게 되어 지금은 주석대신 코드를 더 명확하게 짜기 위해서 노력하고 있다.

 

 

댓글()

[공유] store procedure를 사용하는 이유

데이터베이스|2018. 7. 13. 23:30

스토어 프로시저를 사용하는 이유에 대해 자세히 기록된 블로그가 있어서 공유하고 나중에 확인해봐야지.

http://genesis8.tistory.com/183?category=167682

댓글()

클래스와 인터페이스 - 규칙 21 전략을 표현하고 싶을 때는 함수 객체를 사용하라.

JAVA/Effective Java|2018. 5. 29. 22:41

호출 대상에 대해 어떠한 작업을 수행하는 것을

전략 패턴이라고 한다.



1
2
3
4
5
class StringCompare {
 public int compare (String s1, String s2) {
   return s1.length() - s2.length();
 }
}
cs



 두 개의 문자열을 받아서 비교하는 클래스를 사용할 수 있는 전략 패턴이다.
비교가 필요할 경우 매번 StringCompare 클래스를 생성하지 말고, 싱글톤 패턴을 정의하여 가져다가 사용하면 더욱 편리하다.

하지만 이 StringCompare 클래스의 경우 객체를 메서드에 전달하기 위해서는 인자의 자료형이 String이어야 한다. 

따라서 Compareator 인터페이스를 정의 하여 이를 StringComapre 클래스가 구현하도록 해야 한다.



1
2
3
4
5
6
7
8
9
10
11
// 인터페이스
public interface Comparator<T> {
  public int compare(T t1, T t2);
}
 
class StringCompare implements Comparator<String> {
  @Override 
  public int compare (String s1, String s2) {
   return s1.length() - s2.length();
  }
}
cs




정리하면,
 함수 객체의 주된 용도는 전략 패턴이다. 전략 패턴을 사용하기 위해서는 인터페이스 (위에서는 Comparator<String>)를 선언하고, 실행가능 전략 클래스 생성 시 저 위에 인터페이스를 구현하도록 해야 한다.

단, 전략 패턴이 한번만 사용할 경우 익명 클래스로 사용할 수 있다.



1
2
3
4
5
6
Arrays.sort(StringArray, new Comparator<String>() {
  @Overide
  public int compare (String s1, String s2) {
    return s1.length() - s2.length();
  }
});
cs



만약 자주 사용 되는 경우에는,
public static final 지시자를 사용하여 외부에 공개 할 수 있다.



1
2
3
4
5
6
7
8
9
10
11
class Host {
  private static Class StringCompare implements Comparator<String>, Serializable {
   public int comapare(String s1, String s2) {
    return s1.length() - s2.length();
   }
  }
 
  // Compare<String>를 구현한 클래스로, 다형성을 이용하여 StringCompare를 받을 수 있다.
  // 외부에서는 Host.STRING_LENGTH_COMPARATOR.compare("dd", "ff"); 방식으로 사용할 수 있다.
  public static final Comparator<String> STRING_LENGTH_COMPARATOR = new StringCompare();
}
cs



출처 : 조슈아 블로크, 『 Effective Java 2/E』, 이병준 옮김, 인사이트(2014.9.1), 규칙21 인용.



댓글()