book/clean code

[Clean Code] 9. 단위 테스트

TDD 법칙 세 가지 첫째 법칙: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 둘째 법칙: 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 셋째 법칙: 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 이렇게 하면 실제 코드를 전부 테스트하는 테스트 케이스가 나온다. 하지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다. 깨끗한 테스트 코드 유지하기 만약 테스트 코드가 더럽다면, 실제 코드를 변경해 기존 테스트 케이스가 실패했을 때, 지저분한 코드로 인해 변경하기 어려워진다. 테스트 코드는 실제 코드 못지 않게 중요하다. 테스트 케이스가 있으면 변경이 두렵지 않다. 테스트 케이스가 없다면 모든 변경이 잠..

[Clean Code] 8. 경계

외부 코드 사용하기 인터페이스 제공자는 더 많은 환경에서 돌아가야 더 많은 고객이 구매하니까 적용성을 최대한 넓히려 애쓴다. 반면, 인터페이스 사용자는 자신의 요구에 집중하는 인터페이스를 바란다. 이런 긴장으로 인해 시스템 경계에서 문제가 생길 소지가 많다. 한 예로, java.util.Map을 살펴보자. Map이 제공하는 기능성과 유연성은 확실히 유용하지만 그만큼 위험도 크다. 예를 들어, 프로그램에서 Map을 만들어 여기저기 넘긴다고 가정하자. 넘기는 쪽에서는 아무도 Map 내용을 삭제하지 않으리라 믿겠지만, Map에는 clear() 메서드가 있고, 누구나 Map 내용을 지울 권한이 있다는 말이다. 또 다른 예로, 설계 시 Map에 특정 객체 유형만 저장하기로 결정했다고 하자. 그렇지만 Map은 객체..

[Clean Code] 7. 오류 처리

오류 코드보다 예외를 사용하라 예외를 사용하지 않고 오류 플래그를 설정하는 등의 방식은 코드를 복잡하게 만든다. 오류가 발생하면 예외를 던지는 편이 낫다. 그래야 코드가 깔끔해진다. 논리가 오류 처리 코드와 뒤섞이지 앟는다. Try-Catch-Finally 문부터 작성하라 예외가 발생할 코드를 짤 때는 try-catch-finally 문으로 시작하는 편이 낫다. 그러면 try 블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워진다. 미확인 예외를 사용하라 자바 첫 버전이 확인된 예외를 선보였던 당시는 확인된 예외가 멋진 아이디어로 여겨졌다. 메서드를 선언할 때는 메서드가 반환할 예외를 모두 열거했다. 그러나 C#, C++, 파이썬, 루비는 확인된 예외를 지원하지 않음에도 불구하고 안정적인..

[Clean Code] 6. 객체와 자료 구조

자료 추상화 두 예제의 차이를 살펴보자. 두 예제 모두 2차원 점을 표현하다. 그런데 한 클래스는 구현을 외부로 노출하고, 다른 클래스는 구현을 완전히 숨긴다. class Point { public double x; public double y; } ---------------------------------------------- interface Point { double getX(); double getY(); void setCartesian(double x, double y); double getR(); double getTheta(); void setPolar(double r, double theta); } 아래 예제는 점이 직교좌표계를 사용하는지 극좌표계를 사용하는지 알 길이 없다. 그럼에도 ..

[Clean Code] 5. 형식 맞추기

형식을 맞추는 목적 코드 형식은 중요하다! 코드 형식은 의사소통의 일환이다. 오늘 구현한 기능이 다음 버전에서 바뀐다 하더라도 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 적절한 행 길이를 유지하라 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다. 반드시 지킬 엄격한 규칙은 아니지만 바람직한 규칙으로 삼으면 좋겠다. 큰 파일보다 작은 파일이 이해하기 쉽다. 신문 기사를 떠올려 보자. 최상단에 기사를 몇 마디로 요약하는 표제가 나온다. 첫 문단은 전체 기사 내용을 요약한다. 쭉 읽으며 내려가면 세세한 사실이 조금씩 드러난다. 소스 파일도 신문 기사와 비슷하게 작성한다. 이름은 간단하면서도 설명이 가능하게 짓는다. 소스 파일 첫 부분은 고차원 개념을, 아래로..

[Clean Code] 4. 주석

주석은 나쁜 코드를 보완하지 못한다 코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다. 코드가 지저분하면 주석을 달게 아니라 코드를 정리해야 한다! 깔끔하고 주석이 거의 없는 코드가, 복잡하고 주석이 많이 달린 코드보다 훨씬 좋다. 코드로 의도를 표현하라! 많은 경우 주석으로 달려는 설명을 코드로 대다수 의도를 표현할 수 있다. 좋은 주석 어떤 주석은 필요하거나 유익하다. 몇 가지를 소개한다. 때로는 회사가 정립한 구현 표준에 맞춰 법적인 이유로 특정 주석을 넣으라고 명시한다. 예를 들어, 각 소스 파일 첫 머리에 주석으로 들어가는 저작권 정보와 소유권 정보는 필요하고도 타당하다. 다음은 FitNess에서 모든 소스 파일 첫 머리에 추가한 주석이다. // Copyright (C) 200..

[Clean Code] 3. 함수

작게 만들어라! 함수를 만드는 첫째 규칙은 '작게!'다. 함수를 만드는 둘째 규칙은 '더 작게!'다. if문, while문 등에 들어가는 블록은 한 줄이어야 한다. 대개 여기서 함수를 호출한다. 블록 안에서 함수 이름을 적절히 짓는다면, 코드를 이해하기도 쉬워진다. 그러므로 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안 된다. 한 가지만 해라! 함수는 한 가지만을 해야 한다. 여기서 그 '한 가지'는 어떻게 알 수 있을까? 지정된 함수 이름 아래 추상화 수준이 하나이면 된다. 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다. 한 가지 작업만 하는 함수는 자연스럽게 섹션으로 나누기 어렵다. 여러 섹션으로 나눠진 함수는 여러 작업을 한다는 증거다. 함수 당 추상화..

[Clean Code] 2. 의미 있는 이름

들어가면서 소프트웨어에서 이름은 어디나 쓰인다. 변수, 함수, 클래스, 패키지 등 이름을 붙인다. 그래서 이름을 잘 지으면 여러모로 편하다. 이 장에서는 이름을 잘 짓는 규칙을 몇 가지 소개한다. 의도를 분명히 밝혀라 변수의 존재 이유는? 수행 기능은? 사용 방법은? 이에 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. int d; // 경과 시간(단위: 날짜) int elpasedTimeInDays; 이름 d는 아무 의미도 드러나지 않는다. elapsedTimeInDays처럼 측정하려는 값의 단위를 표현하는 이름이 필요하다. 그릇된 정보를 피하라 프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다. 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다. 예를 들어, h..