Reading Book/Clean Code

[Clean Code]클린코드_10_클래스

[ 클래스 체계 ] 클래스를 정의하는 표준 자바 관례에 따르면, 가장 먼저 변수 목록이 나오낟. 정적 공개 (static public) 상수가 있다면 맨 처음에 나온다. 다음으로 정적 비공개(private) 변수가 나오며, 이어 비공개 인스턴스 변수가 나온다. 공개 변수가 필요한 경우는 거의 없다. 변수 목록 다음에는 공개 함수가 나온다. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 즉 , 추상화 단계가 순차적으로 내려간다. 그래서 프로그램은 신문기사 처럼 읽힌다. -캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다. 때로는 변수나 유틸리니 함수를 protected로 선언해 테스트 코드에 접근을 허용하기도 한다. 우리에게 테스트는 아주 중요하다..

[Clean Code]클린코드_9_단위 테스트

[ TDD 법칙 세 가지 ] 첫째 법칙: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 둘째 법칙: 컴파일은 실패하지 않으면서 실행히 실패하는 정도로만 단위 테스트를 작성한다. 셋째 법칙: 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. [ 깨끗한 테스트 코드 유지하기 ] 실제 코드가 진화하면 테스트 코드도 변해야 한다. 그런데 테스트 코드가 지저분할 수록 변경이 어려워진다. 실제 코드를 변경해 기존 테스트 케이스가 실패하기 시작하면, 지저분한 코드로 인해, 실패하는 테스트 케이스를 점점 더 통과시키기 어려워진다. 그래서 테스트 코드는 계속해서 늘어가는 부담이 되어버린다. 테스트 코드는 실제 코드 못지 않게 중요하다. 테스트 코드는 이류 시민이 아니다. 테스트 코드는 ..

[Clean Code]클린코드_8_경계

시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. 때로는 패키지를 사고, 떄로는 오픈 소스를 이용한다. 때로는 사내 다른 팀이 제공하는 컴포넌트를 사용한다. 어떤 식으로든 외부 코드를 우리 코드에 깔끔하게 통합해야한다. 이때 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교가 있어야한다. [ 경계 살피고 익히기 ] 외부 코드를 사용하면 적은 시간에 더 많은 기능을 출시하기 쉬워진다. 하지만 외부 코드를 익히기는 어렵다. 외부 코드를 통합하기도 어렵다. 두 가지를 동시에 하기는 더 어렵다. 다르게 접근하여 곧바로 우리쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히면 어떨까? 짐 뉴커크(Jim Newkirk)는 이를 학습 테스트 라 부른다. 학..

[Clean Code]클린코드_7_오류 처리

깨끗한 코드와 오류 처리는 연관성이 있다. 상당수 코드 기반은 전적으로 오류 처리 코드에 좌우된다. 여기서 좌우된다는 표현은 코드 기반이 오류만 처리한다는 의미가 아니다. 여기저기 흩어진 오류 처리 코드 때문에 실제 코드가 하는 일을 파악하기가 거의 불가능하다는 의미다. [ 오류 코드보다 예외를 사용해라 ] 앞서 오류 코드보다 예외를 사용했을 때 더 깨끗한 코드가 됨을 설명했다. [ Try-Catch-Finally 문부터 작성해라 ] 예외에서 프로그램 안에다 범위를 정의한다는 사실은 매우 흥미롭다. try-catch-finally문에서 try블록에 들어가는 코드를 실행하면 어느 시점에서든 실행이 중단된 후 catch 블록으로 넘어갈 수 있다. 어떤 면에서 try 블록은 트랜잭션과 비슷하다. try 블록에..

[Clean Code]클린코드_6_객체와 자료 구조

변수를 비공개(private)로 정의하는 이유가 있다. 남들이 변수에 의존하지 않게 만들고 싶어서 이다. 충동이든 변덕이든, 변수 타입이나 구현을 맘대로 바꾸고 싶어서다. 그렇다면 어째서 수많은 프로그래머가 조회(get)함수와 설정(set)함수를 당연하게 공개(public)해 비공개 변수를 외부에 노출할까? [ 자료 추상화 ] 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다. // 구체적인 Point 클래스 public class Point { public double x; public double y; } // 추상적인 Point 클래스 public interface Point { double getX(); double getY(); void s..

[Clean Code]클린코드_5_형식 맞추기

프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야한다. 코드 형식을 맞추기 위한 간단한 규칙을 정하고, 그 규칙을 착실히 따라야한다. 팀으로 일한다면, 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야한다.필요하면 규칙을 자동으로 적용하는 도구를 활용한다. [ 적절한 행 길이를 유지해라 ] 큰 파일보다는 작은 파일이 이해하기 쉬우므로 적절한 행 길이를 유지해야 한다. -신문기사 처럼 작성해야 한다. 신문을 읽을 때 최상단에 기사를 몇 마디로 요약하는 표제가 나온다. 마찬 가지로 이름은 간단하면서도 설명이 가능하게 지어야하고 아래로 내려갈수록 의도를 세세하게 묘사하여야한다. -개념은 빈 행으로 분리해라. 일련의 행 묶음은 완결된 생각 하나를 표현한다. 생각 사이에는 빈 행을 넣어 분리해야 한다. 예를 들어..

[Clean Code]클린코드_4_주석

잘 달린 주석은 그 어떤 정보보다 유용하다. 경솔하고 근거없는 주석은 코드를 이해하기 어렵게 만든다. 오래되고 조잡한 주석은 거짓과 잘못된 정보를 퍼뜨려 해악을 미친다. 사실상주석은 기껏해야 필요악이다. 우리에게 프로그래밍 언어를 치밀하게 사용해 의도를 표현할 능력이 있다면, 주석은 전혀 필요하지 않을 것이다. 우리는 코드로 의도를 표현하지 못해, 그러니까 "실패"를 만회하기 위해 주석을 사용한다. 주석은 언제나 실패를 의미한다. 때때로 주석없이는 자신을 표현할 방법을 찾지 못해 할 수 없이 주석을 사용한다. 프로그래머들이 주석을 엄격하게 관리해야 한다고, 그래서 복구성과 관련성과 정확성이 언제나 높아야 한다고 주장할지도 모르겠다. 하지만 차라리 코드를 깔끔하게 정리하고 표현력을 강화하는 방향으로, 그래..

[Clean Code]클린코드_3_함수

함수를 만드는 규칙은 다음과 같다. [ 작게 만들어라 ] 함수는 작을 수록 더 좋다. 이에 대한 정확한 근거나 자료를 제시하기 어렵지만 많은 프로그래머들이 개발을 하며 오래 시행착오 끝에 작은 함수가 좋다고 생각한다고 한다. if/else문 , while문 등에 들어가는 블록은 한 줄이어야 한다. 대게 여기서 함수를 호출한다. 이 말은 중첩 구조가 생길 만큼 함수가 커져서는 안 된다는 뜻이다. 그래야 함수를 읽고 이해하기 쉬워진다. ( switch문은 기본적으로 작게 만들기가 어렵다. switch문을 완전히 피할 방법은 없다..) [ 한 가지만 해라 ] 함수는 한 가지를 해야한다. 지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 하는 것이다. 함수가 확실히 '..