Intro
- 의도를 분명히 표현하는 함수를 어떻게 구현할 수 있을까?
- 함수에 어떤 속성을 부여해야 처음 읽는 사람이 프로그램을 직관적으로 파악 할 수 있을까?
작게 만들어라!
- 함수를 만들 때 첫째 규칙은 '작게!', 둘째 규칙은 '더 작게!' 이다.
- 함수가 작을수록 좋다는 증거나 자료를 제시하신 어렵지만, 짧을 수록 각 함수가 명백하고 하나의 동작을 한다.
- 예시 1
// Before
public static String renderPageWithSetupsAndTeardowns( PageData pageData, boolean isSuite) throws Exception {
boolean isTestPage = pageData.hasAttribute("Test");
if (isTestPage) {
WikiPage testPage = pageData.getWikiPage();
StringBuffer newPageContent = new StringBuffer();
includeSetupPages(testPage, newPageContent, isSuite);
newPageContent.append(pageData.getContent());
includeTeardownPages(testPage, newPageContent, isSuite);
pageData.setContent(newPageContent.toString());
}
return pageData.getHtml();
}
// After
public static String renderPageWithSetupsAndTeardowns( PageData pageData, boolean isSuite) throws Exception {
if (isTestPage(pageData)) {
includeSetupAndTeardownPages(pageData, isSuite);
}
return pageData.getHtml();
}블록과 들여쓰기
- 중첩구조(if/else 문, while 문 등)에 들어가는 블록은 한 줄이어야 한다.
- 각 함수 별 들여쓰기 수준이 2단을 넘어서면 안된다.
- 그래야 함수는 더욱 읽고 이해하기 쉬워진다.
한가지만 해라!
- 함수는 한가지를 해야 한다. 그 한가지를 잘 해야 한다. 그 한가지만을 해야 한다.
- 지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 하는 것이다.
- 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출 할 수 있다면 해당 함수는 여러작업을 하는것이다.
추상화 : 복잡한 자료, 모듈, 시스템등으로 부터 핵심적인 개념 또는 기능을 간추려 내는 것
함수 내 섹션
- 함수를 여러 섹션으로 나눌 수 있다면 그 함수는 여러작업을 한다는 증거다.
함수 당 추상화 수준은 하나로!
- 함수가 '한가지' 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 된다.
- 만약 한 함수 내에 추상화 수준이 섞이게 된다면 읽는 사람이 헷갈린다.(근본 개념인지 세부사항인지 헷갈리므로)
- 근본 개념과 세부사항을 뒤섞기 시작하면, 깨진 창문처럼 함수에 세부사항을 점점 추가하게 된다.
위에서 아래로 코드 읽기:내려가기 규칙
- 코드는 위에서 아래로 이야기처럼 읽혀야 좋다.
- 위에서 아래로 읽으면 함수 추상화 부분이 한번에 한단계씩 낮아진다. (내려가기 규칙)
Switch 문
- switch 문은 작게 만들기 어렵다. (if/else 의 연속도 포함)
- 다형성을 이용하여 switch 문을 abstract factory에 숨겨 다형적 객체를 생성하는 코드 안에서만 switch를 사용하도록 한다.
- 다만 불가피하게 switch문을 써야될 상황도 생긴다.
- 예제 1
- 함수가 길다
- 한가지 작업만 수행하지 않는다.
- SRP(Single Responsibility Principle) 위반
- OCP(Open Closed Principle) 위반
// Bad
public Money calculatePay(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);
}
}
// Good
public abstract class Employee {
public abstract boolean isPayday();
public abstract Money calculatePay();
public abstract void deliverPay(Money pay);
}
-----------------
public interface EmployeeFactory {
Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType;
}
-----------------
public class EmployeeFactoryImpl implements EmployeeFactory {
public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType {
switch (r.type) {
case COMMISSIONED:
return new CommissionedEmployee(r) ;
case HOURLY:
return new HourlyEmployee(r);
case SALARIED:
return new SalariedEmploye(r);
default:
throw new InvalidEmployeeType(r.type);
}
}
}서술적인 이름을 사용하라!
“코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다” - 워드 커닝햄(Ward Cunningham)
- 함수가 작고 단순할수록 서술적인 이름을 고르기 쉬워진다.
- 겁먹을 필요없다, 길고 서술적인 이름이 짧고 어려운 이름보다 좋다.
- 이름을 정하느라 시간을 들여도 괜찮다. 이런저런 이름을 넣어 코드를 읽어보면 더 좋다.
- 서술적인 이름을 사용하면 머릿속에서 설계가 뚜렷해지므로 코드를 개선하기 쉬워진다.
- 일관성 있게 이름을 붙여야 한다.
함수 인수
- 함수에서 이상적인 인수 개수는 0개 (무항).
- 인수는 코드 이해에 방해가 되는 요소이므로 최선은 0개이고, 차선은 1개뿐인 경우다.
- 테스트 관점에서도 인수가 많아지면 인수조합을 검증하는 테스트 케이스 작성도 어려워진다.
- 출력인수(함수의 반환 값이 아닌 입력 인수로 결과를 받는 경우)는 코드를 재차 확인하게 만드므로 쓰지 않는것이 좋다.
많이 쓰는 단항 형식
- 인수에 질문을 던지는 경우
- boolean fileExists("MyFile");
- 인수를 뭔가로 변환해 결과를 변환하는 경우
- InputStream fileOpen("MyFile");
- 이벤트 함수일 경우 (이 경우에는 이벤트라는 사실이 코드에 명확하게 드러나야 한다.)
- 위의 예가 아니라면 단항함수는 가급적 피한다.
- 예시 1, 입력 인수를 변환하는 함수라면 변환결과는 반환값으로 돌려준다. 출력인수 사용 X.
// Bad
void transform(StringBuffer out);
// Good
StringBuffer transform(StringBuffer in);플래그 인수
- 플래그 인수는 추하다. 쓰지마라, boolean 값을 넘기는 관례는 정말로 끔찍하다.
- bool 값을 넘기는 것 자체가 그 함수는 한꺼번에 여러가지 일을 처리한다고 공표하는 것과 마찬가지다.
이항 함수
- 단항 함수보다 이해하기가 어렵다.
- Point 클래스의 경우에는 이항 함수가 적절하다. 2개의 인수간의 자연적인 순서가 있어야함 Point p = new Point(x,y);
- 당연하게 여겨지는 assertEquals(expected, actual) 에서도 인수를 바꿔 넣는 경우가 많은 것처럼 인위적으로 순서를 기억해야한다.
- 무조건 나쁜 것은 아니지만, 인수가 2개이니 만큼 이해가 어렵고 위험이 따르므로 가능하면 단항으로 바꾸도록 애써야 한다.
삼항 함수
- 이항 함수보다 이해하기가 훨씬 어렵다.
- 위험도 2배 이상 늘어난다. 삼항 함수를 만들 때는 신중히 고려하라.
- 예시 1, 인수가 많아질 수록 안좋다.
assertEquals(expected, actual);
assertEquals(message, expected, actual)인수 객체
- 인수가 많이 필요할 경우, 일부 인수를 독자적인 클래스 변수로 선언할 가능성을 살펴보자.
- 객체를 생성해 인수를 줄이는 방법이 눈속임이라 여결지 모르지만 그렇지 않다. 개념을 표현할 수 있게 해준다.
- 예시 1
Circle makeCircle(double x, double y, double radius);
Circle makeCircle(Point center, double radius);인수 목록
- 때로는 인수 개수가 가변적인 함수도 필요하다. String.format 메서드가 좋은 예.
- 가변 인수 전보를 동등하게 취급하면 List 형 인수 하나로 취급할 수 있다.
- 예시 1, String.format 은 사실상 이항 함수다.
public String format(String format, Object... args);동사와 키워드
- 단항 함수는 함수와 인수가 동사/명사 쌍을 이뤄야한다.
- write(name) 보다는 writeField(name);
- 함수이름에 키워드(인수 이름)을 추가하면 인수 순서를 기억할 필요가 없어진다.
- assertEquals 보다는 assertExpectedEqualsActual(expected, actual);
부수 효과를 일으키지 마라!
- 부수효과는 거짓말이다.
- 함수에서 한가지를 하겠다고 약속하고는 남몰래 다른 짓을 하는 것이므로, 한 함수에서는 딱 한가지만 수행할 것!
- 예시 1
- Session.initialize(); 호출은 부수 효과다.
- 이러한 부수효과는 시간적 결합을 초래 한다. 세션을 지울수있는 특정 상황에서만 호출 가능하므로
- 하단 메서드는 checkPasswordAndInitializeSession 이라는 이름이 맞지만 이는 함수가 '한 가지' 만한다는 규칙을 위반한다.
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;
}
}출력인수
- 일반적으로 출력 인수는 피해야 한다.
- 함수에서 상태를 변경해야 한다면 함수가 속한 객체 상태를 변경하는 방식을 택하라.
- 예시 1
// Bad
appendFooter(report);
// Good
report.appendFooter();명령과 조회를 분리하라!
- 함수는 뭔가 객체 상태를 변경하거나, 객체 정보를 반환하거나 둘 중 하나다. 둘 다 하면 안된다.
- public boolean set(String attribute, String value); 같은 경우에는 속성 값 설정 성공 시 true 를 반환하므로 괴상한 코드다.
- 예시 1
// Bad
if (set("username", "unclebob"))...
// Good
if (attributeExists("username")) {
setAttribute("username", "unclebob");
}오류코드보다 예외를 사용하라!
- 명령 함수에서 오류 코드를 반환하는 방식은 명령/조회 분리 규칙을 위반한다.
- 예시1, if (deletePage(page) == E_OK)
- try/catch 를 사용하면 오류 처리 코드가 원래 코드에서 분리되므로 코드가 깔끔해 진다.
Try/Catch 블록 뽑아내기
- try/catch 블록은 원래 추하다.
- 정상 동작과 오류 처리 동작을 섞는다. 그러므로 try/catch 블록을 별도 함수로 뽑아내는것이 좋다.
- 예시 1
// Bad
if (deletePage(page) == E_OK) {
if (registry.deleteReference(page.name) == E_OK) {
if (configKeys.deleteKey(page.name.makeKey()) == E_OK) {
logger.log("page deleted");
} else {
logger.log("configKey not deleted");
}
} else {
logger.log("deleteReference from registry failed");
}
} else {
logger.log("delete failed"); return E_ERROR;
}
// Good
try {
deletePage(page);
registry.deleteReference(page.name);
configKeys.deleteKey(page.name.makeKey());
} catch (Exception e) {
logError(e);
}
// Better
public void delete(Page page) {
try {
deletePageAndAllReferences(page);
} catch (Exception e) {
logError(e);
}
}
private void deletePageAndAllReferences(Page page) throws Exception {
deletePage(page);
registry.deleteReference(page.name);
configKeys.deleteKey(page.name.makeKey());
}
private void logError(Exception e) {
logger.log(e.getMessage());
}오류처리도 한가지 작업이다.
- 함수는 '한 가지' 작업만 해야하며, 오류 처리도 '한 가지' 작업에 속한다.
- 그러므로 오류 처리 함수는 오류만 처리해야 마땅하다.
- 함수에 try 키워드가 있다면 try 문으로 시작해 catch/finally 문으로 끝나야 한다.
Error.java 의존성 자석
- 오류를 처리하는 곳곳에서 오류코드를 사용한다면 enum class를 쓰게 되는데 이런 클래스는 의존성 자석이다.
- 새 오류코드를 추가하거나 변경할 때 관련 클래스 전부를 다시 컴파일하고 다시 배치해야한다.
- 그러므로 예외를 사용하는 것이 더 안전하다.
public enum Error {
OK,
INVALID,
NO_SUCH,
LOCKED,
OUT_OF_RESOURCES,
WAITING_FOR_EVENT;
}반복하지 마라!
- 중복은 모든 소프트웨어에서 모든 악의 근원이므로 늘 중복을 없애도록 노력해야한다.
- 구조적 프로그래밍, AOP, COP 모두 어떤면에서 중복 제거 전략이다.
구조적 프로그래밍
- 다익스트라의 구조적 프로그래밍의 원칙을 따르자면 모든 함수와 함수 내 모든 블록에 입구와 출구가 하나여야 된다.
- 즉, 함수는 return문이 하나여야 되며, 루프 안에서 break나 continue를 사용해선 안된며 goto는 절대로, 절대로 안된다.
- 그런데 구조적 프로그래밍의 목표와 규율은 공감하지만 함수가 작다면 위 규칙은 별 이익을 제공하지 못한다.
- 함수가 아주 클 때만 상당한 이익을 제공한다. 그러므로 함수를 작게 만든다면 간혹 return, break, continue를 사용해도 괜찮다.
- 오히려 때로는 단일 입/출구 규칙보다 의도를 표현하기 쉬워진다.
함수를 어떻게 짜죠?
- 소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다.
- 처음에는 길고 복잡하고, 들여쓰기 단계나 중복된 루프도 많다. 인수목록도 길다.
- 하지만, 이 코드들을 빠짐없이 테스트하는 단위 테스트 케이스도 만들고, 코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한다.
- 처음부터 탁 짜내지 않는다. 그건 아무도 안된다.
결론
- 대가 프로그래머는 시스템을 (구현할) 프로그램이 아니라 (풀어갈) 이야기로 여긴다.
- 여기서 설명한 규칙을 따른다면 길이가 짧고, 이름이 좋고, 체계가 잡힌 함수가 나온다.
- 하지만 진짜 목표는 시스템이라는 이야기를 풀어가는 데 있다는 사실을 명심해야한다.
- 작성한 함수가 분명하고 정확한 언어로 깔끔하게 같이 맞아 떨어져야 이야기를 풀어가기 쉬워진다.
Backend Developer