Clean code(03)

함수를 만드는 규칙작게 만들어라.더 작게 만들어라.If 문/ else 문/ while 문에 들어가는 블록은 한 줄로함수에서 들여쓰기 수준은 1이나 2단으로 한다.

함수는 한 가지만 해야 한다.그 한 가지를 잘 해야 한다.여기서 한 가지만 이란 같은 추상화 수준을 의미한다.한 가지 작업을 수행하는 함수는 섹션으로 분할하기 힘들다.

추상화 수준 높음getHtml() String pagePathName = PathParser.render(pagePath); .append(“\n”);낮음추상화 수준이 같지 않으면읽기가 어렵다.깨진 창문 효과로 인해 코드가 계속해서 나빠질 수 있다.

switch문은 N가지 작업을 처리한다.하지만 불행히도switch문을 피할 수는 없다.switch문은 일반적으로 다음과 같은 문제점을 가진다. SRP 위반

코드 중복해결책은 ?다형성을 이용하라!

작은 함수는 서술적인 이름을 고르기 쉽다.긴 서술적인 이름 > 짧고 어려운 이름IDE를 이용하라.replace 기능을 이용해서 이런저런 이름을 시도해 보라.서술적인 이름은 코드 개선에도 도움을 준다.이름을 지을 때 일관성이 중요하다.

함수의 인수는 적을수록 좋다.인수가 많으면 테스트 케이스를 작성하기 어렵다.출력 인수는 입력 인수보다 이해하기 어렵다.반환값을 기대하지 출력 인수를 기대하지 않는다.

booleanfileExists(“MyFile”)과 같은 조회InputStreamfileOpen(“MyFile”)과 같은 명령두 형식은 단항 함수가 당연하다.시스템의 상태를 바꾸는 이벤트 함수도 단항 함수로 괜찮다.

플래그 인수는 추하다.함수가 여러 가지를 처리한다고 공표하는 것과 같다.renderForSuit()renderForSingleTest()<render(booleanisSuite)

writeField(name) vswriteField(outputStream, name)어느 쪽이 이햐하기 쉬운가?이항 -> 단항으로 변환을 할 수 있다면 그렇게 하자.이항 인수가 적절한 경우도 있다.EX) Point p = new Point(0, 0) vs Point p = new Point(0)만약 두 인수가 한 가지 값을 표현하거나 자연적인 순서가 있다면 OKassertEquals(expected, actual)과 같이 당연한 이항 함수도 자연적인 순서가 존재하지 않아서실수를 유발한다.

Difficulty삼항 함수 >이항 함수assertEqual(message, expected, actual)첫 번째 인수가 expected라고 예상하지 않았나?예외)assertEqual(1.0, amount, 0.001)이해하기는 어렵지만, 부동소수점의 정밀도를 고려하면 가치는 있다.

Circle makeCircle(double x, double y, double radius);vsCircle makeCircle(Point center, double radius);같은 개념의 인수를 새로운 객체로 합칠 수 있는지? 확인하자!

String.format, printf와 같이가변 인수가 필요한 경우가 있다.가변 인수를 한 개의 인자로 생각할 때마찬가지로 함수의 인자 수가 삼항을 넘으면 안된다.

함수의 의도를 표현하기 위해서 좋은 이름은 필수적이다.단항 함수는 함수와 인수 -> 동사/명사로EX) write(name), writeField(name)또 함수 이름에 키워드를 추가할 수도 있다.EX)assertEquals < assertExpectedEqualsActual(expected, actual)이렇게 함으로써 인수의 순서 문제를 해결할 수 있다.

부수 효과는 함수가 한 가지 일만 수행한다는 원칙을 위배한다.부수 효과로 인해 일시적인 결합이나 순서 종속성이 생긴다.때로, 일시적인 결합이 필요하다면 함수 이름에 명시하자.물론 함수가 한 가지만 한다는 규칙을 위반하지만 말이다.

출력 인수를 피하라!출력 인수는 코드 읽기의 흐름을 망해한다.OOP이전에는 출력 인수가 필요했다.하지만 OOP에선 this가 출력 인수를 대신한다.

If( set(“username”, “unclebob”) )/*…*/확인 or 설정 ?If( attributeExists(“username”) ){setAttribute(“username”, “unclebob”);/*…*/}명령과 조회를 구분하자.

오류 코드를 반환하는 함수도 명령/조회의 규칙을 위반한다.EX)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;}

예외를 사용하면 오류 처리 코드가 원래 코드에서 분리된다.EX)try{deletePage(page);registry.deleteReference(page.name);configKeys.deleteKey(page.name.makeKey());}catch(Exception e){logger.log(e.getMessage());}

오류 처리도 한 가지 작업이므로try/catch 블록을 별도의 함수로 뽑아내면 코드가 더 보기 좋아진다.EX)public void delete(Page page){try{deletePageAndAllReference(page); }catch(Exception e){logError(e);}}

오류 코드도 OCP를 위반한다.오류 코드를 추가하려면 코드를 수정해야 한다.DRYDon’t Repeat Youself. 반복을 하지 말자!중복은 오류의 원천이다.

함수를 만드는 작업은일련의 제련 과정이다.첫 술에 배부르랴!점차적으로 Refactoring하자.하지만테스트가 없다면 이런 과정은 불가능하다.

Clean code(03)

More Related Content

What's hot (20)

Viewers also liked (14)

Similar to Clean code(03) (20)

Clean code(03)