Clean Code (1)

Clean Code

졸업 작품을 제작하면서 팀원 각자의 진로에 맞춰 파트를 나눴는데 혼자가 되었다. 비록 Android Part에서 협업은 경험하지 못하였으나 만약 누군가 내 코드를 읽는다면 정말 속이 터질 것이다. 개발자는 자신의 실력도 중요하지만 협업 능력이 가장 중요한 것 같다. 그래서 이 책을 지금이라도 읽고 책에 있는 내용대로 코드를 짜고자 공부를 시작한다.

처음부터 큰 규모의 코드를 짜기엔 어려움이 있으므로 BOJ 문제를 풀 때 최대한 고려하여 짜는 연습부터 진행할 것이다.

Clean Code 관련 기록은 코드 작성 보다는 책을 보고 코드 작성요령 대한 요약을 담아야겠다. (책은 여러번 반복해서 읽자)

Chapter1 깨끗한 코드

• 코드는 요구사항을 상세하게 표현하는 수단이다
    코드 작성 : 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업
  
  
• 좋은 코드 작성의 필요성 : 코드를 막 작성하여 버그가 많이 생기고 이로 인해 문닫은 회사가 존재할 정도로 좋은 코드는 중요하다
  
  
• 나쁜 코드로 치르는 대가 : 개발의 속도 및 생산성 저하 (그지같은 코드는 읽다가 짜증이 날 것 같다) -> 마감 기한을 맞추려다가 나쁜코드를 양산할 수 밖에 없다 => 오히려 시간이 더 걸린다
  
  
• 그렇다면 깨끗한 코드는 무엇인가?
  : 여러 전문가의 의견을 통해 알아보자

  • C++의 창시자 바야네
    * 우아하고 효율적인 코드 (보기에 즐거운 코드, 자원낭비가 적은 코드)
    * 논리가 간단해야함
    * 의존성을 최대한 줄여야 유지보수가 쉬워짐
    * 오류는 명백한 전략에 의거해 철저하게 처리 (세세한 내용까지 꼼꼼하게)
    * 성능을 최적으로 유지
    * 깨끗한 코드는 1가지를 제대로 한다
    
    
  • 객체지향 분석 디자인 저자 그래디 부치
    * 단순하고 직접적이다
    * 잘 쓴 문장처럼 읽힌다 (가독성)
    * 설계자의 의도를 숨기지 않는다
    * 명쾌한 추상화와 단순한 제어문으로 가득하다
    
    
  • Eclipse 전략의 대부 데이브 토마스
    * 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다
    * 단위 테스트 케이스와 인수 테스트 케이스가 존재한다
    * 의미있는 이름이 붙는다
    * 특정 목적을 달성하는 방법은 하나만 제공한다
    * 의존성은 최소이고 각 의존성을 명확하게 정의
    * API는 명확하며 최소로
    * 문학적으로 표현해야 한다
    
    
  • 론 제프리스
    * 모든 테스트를 통과한다
    * 중복이 없다
    * 시스템 내 모든 설계 아이디어를 표현한다
    * 클래스, 메서드, 함수 등을 최대한 줄인다

  요약하면 가장 중점적인 부분은
  중복을 피해라 + 1가지 기능만 수행해라 + 제대로 표현해라 + 작게 추상화 해라 ...etc (아직 단위 테스트 코드를 작성할 실력은 안될 것 같다)
  
  주변 코드가 읽기 쉬우면 새 코드를 짜기 쉬워진다 (서둘러 끝내려면 협업하는 사람이 코드를 읽기 쉽게 만들면 된다)
  
  보이스카웃 규칙처럼 캠핑장은 처음 왔을때 보다 더 깨끗하게 만들어야한다 -> 시간이 지날수록 코드는 더 깨끗하게 유지 되어야 한다
  
  미치도록 연습만이 살길이다

Chapter 2   의미있는 이름

• 소프트웨어에서 이름은 변수, 함수, 클래스, 패키지, 디렉터리, 파일 등 어디서나 쓰인다 그러므로 이름을 잘 지으면 편한 부분이 많다
  
  

  • 의도를 분명히 밝혀라 (코드가 무엇을 함축하고 있는지)
    - 좋은 이름을 지을때 시간이 걸릴 수 있으나 좋은 이름으로 인해 절약할 수 있는 시간이 더 많다.
    - 존재 이유, 수행 기능, 사용 방법 등의 질문에 이름으로 답할 수 있으여 한다
      (만약 주석이 있다면 의도를 분명히 드러내지 못했음을 의미)
    
    
  • 그릇된 정보를 피하라
    - 그릇된 단서는 코드의 의미를 흐린다.  ex) List라는 단어는 함부로 쓰면 안된다.
    - 서로 흡사한 이름을 사용하지 않도록 주의해라
        But 일관성을 위해 유사한 개념은 유사한 표기법 사용
    
    
  • 의미 있게 구분해라
    - 단순 컴파일 통과만을 생각하고 코드를 작성하지 마라
       (연속된 숫자나 불명확한 용어 사용하지 말기)
    ex) Student라는 class가 존재할 때 다른 class 이름을 StudentInfo, StudentData 와 같이 지어서는 안된다.
         변수 이름에 variable라는 이름을 절대 쓰지 말아라 (중복)
    
    
  • 발음하기 쉬운 이름을 사용해라
    
    
  • 검색하기 쉬운 이름을 사용해라
    - 문자 하나를 사용하거나 변수에 단순 숫자만 부여하여 차이를 두면 검색 시 어려움을 겪을 것이다.
    
    
  • 인코딩을 피하라
    - 인코딩 언어까지 익히는 것은 매우 힘들 것이며 발음하기 어렵고 오타가 생기기 쉽다
    (기존에 사용하던 헝가리식 표기법을 사용하거나 멤버 변수 접두어 같은 것을 표기할 필요없다)
    But 인터페이스 클래스와 구현 클래스를 구분하기 위해 인코딩이 필요한 경우도 있다.
    
    
  • 자신의 기억력을 자랑하지 마라
    - 자신만이 이해하거나 기억할 수 있는 이름을 짓지 말고 상대방이 이해하기 쉽도록 이름을 지어라    ex) int a; int arr[3]; etc..
    
    
  • 클래스(객체) 이름 : 명사나 명사구가 적합
  • 메서드 이름 : 동사나 동사구가 적합 (접근자 : get, 변경자 : set, 조건자 : is)
    
    
  • 기발한 이름은 피해라
    
    
  • 한 개념에 한 단어를 사용하라
    - 추상적인 개념 하나에 단어를 선택하여 고수하라
    ex) 똑같은 기능을 하는 메서드를 클래스마다 get, fetch 등으로 제각각 부르면 혼란스럽다.
    
    
  • 말장난을 하지마라
    - 한 단어를 두가지 목적으로 사용하지 마라 (다른 개념에 같은 단어 사용 금지)
    ex) add라는 단어가 기존 값 2개를 더하는 것인데 집합에 값 하나를 추가하는 메서드를 add로 짓는다면 맥락이 달라 혼란을 준다
    
    
  • 해법 영역에서 가져온 이름을 사용하라
    
    
  • 문제 영역에서 가져온 이름을 사용하라
    
    
  • 의미 있는 맥락을 추가해라
    - 의미가 분명하게 이름 짓지 못한다면 최후의 수단으로 접두어를 붙인다
    
    
  • 불필요한 맥락을 없애라
    

BOJ 문제를 풀면서 숏코딩으로 다른 분들이 짠 코드를 볼 때 이름이 대충 지어져 있는 코드는 이해하는데 더 오랜시간이 걸리곤 한다.
코드를 짤 때 의식적으로 변수명을 잘 짓는 연습을 해야할 것 같다.

특히 1단어 짜리 변수는 짧은 반복문 안에서 int i, j, k; 와 같이 반복문 내부에서만 사용하고 e:Exception와 같이 에러 변수에만 사용하도록 노력해야겠다.

Chapter 3    함수

• 어떤 프로그램이든 가장 기본적인 단위가 함수다.
  

  • 작게 만들어라
    - if/else/while 문 등에 들어가는 블록은 1줄이어야 한다. (대게 함수 호출)
      들여쓰기 수준은 1단이나 2단을 넘어서면 안된다.
    
    
  • 한 가지만 해라
    - 함수는 한가지를 잘 해야하거나 그 한 가지만을 해야한다
    (함수를 만드는 이유는 큰 개념을 여러 단계로 나눠 수행하기 위함)
    
    
  • 함수 당 추상화 수준은 하나로
    - 한 가지 작업만 하려면 모든 문장의 추상화 수준이 동일해야 한다.
    (Ref. 내려가기 규칙 : 코드는 위에서 아래로 자연스럽게 읽혀야 좋다
    -> 한 함수다음에는 추상화 수준이 한 단계 낮은 함수가 온다)
    
    
  • Switch 문
    - Switch 문은 작게, 한가지 작업한 하도록 만들기는 어렵다
    
    
  • 서술적인 이름을 사용하라
    - 함수가 작고 단순할수록 서술적인 이름을 고르기 쉽다
    (길이 상관x, 여러 단어가 쉽게 읽히는 명명법 사용, 일관성 있게 짓기)
    
    
  • 함수 인수
    - 함수에서 가장 인상적인 인수 개수는 0개이다
    (인수가 2개이상 넘어가면 이해 및 테스트하기 어렵다)
    
    단항 형식의 인수 (아래가 아닌 경우 피하는 것이 좋다)
    1. 인수에 질문 던지기
    2. 인수를 뭔가로 변환해 결과를 반환하는 경우
    
    플래그 인수
    - 함수에 bool 값을 넙기는 것은 끔찍한 일이다 (여러 가지를 처리한다는 의미)
    
    이항 함수
    - 단항 함수보다 이해하기 어렵다
    But. Point(x,y) 처럼 2개가 묶여 의미를 갖는다면 적절한 경우도 있다
    
    삼항 함수
    - 만들기 전에 다른 방식을 고려해봐라
    
    인수 객체
    - 인수가 여러개 필요하다면 독자적인 클래스 변수로 선언해야할 가능성을 생각
    
    
  • 부수 효과를 일으키지 마라
    - 함수로 넘어온 인수나 시스템 전역변수 수정 등 부수 효과를 일으키면 안된다
    (EX. 비밀번호를 체크하는 함수에서 세션 초기화를 하는 등)
    
    
  • 명령과 조회를 분리하라
    
    
  • 오류 코드보다 예외를 사용해라
    - 오류 코드를 반환하면 오류 코드를 곧바로 처리해야는 문제점에 봉착
    (예외를 사용하면 오류 처리 코드가 분리 되므로 코드가 깔끔해진다)
      -> 오류 처리도 한 가지 작업이므로 try/catch 블록도 별도의 함수로 뽑아 내어 오류 처리만 하도록 하는 것이 좋다
    
    
  • 반복하지 마라
    - 중복은 소프트웨어에서 모든 악의 근원이다
    
    
  • 구조적 프로그래밍
    - 모든 함수 내 모든 블록에 입구와 출구가 하나만 존재해야한다
    (return 문이 하나여야한다)
    But 작은 프로그램에서 goto는 지양하고 break, continue 등은 사용해도 OK
    
    

• 그렇다면 함수를 어떻게 짜야할까?
  코드를 다듬고 함수를 만들고 이름을 바꾸고 중복을 제거하며 메서드를 줄이고 순서를 바꿔가며 계속 신경을 써야 한다

  Result : 프로그램을 짜는 것은 코드로 이야기를 써내려가는 것이다

  
  최대한 위의 설명에 맞게 함수를 구현하도록 노력해봐야겠다