[코드프레소] Java 웹개발 트랙 체험단 - Clean Code
Clean Code 소개
Clean Code란?
이해하기 쉽고 변경하기 쉬운 code.
표준이나 정의는 존재하지 않음
Clean Code의 공통적 의견
사람이 읽고 이해하기 쉽다.
단순한 한가지 역할을 하고 명확한 이름을 갖고 있다.
중복이 없다.
테스트 케이스가 있다.
즉, 사람이 이해하기 쉽고, 명확히 한가지 역할을 하며 이 역할을 의미있게 표현 하고, 중복이 없고 테스트 케이스가 존재하는 코드이다.
Clean Code가 중요한 이유
코드의 품질이 낮아지면 이해하기 어렵고, 수정하기 어렵고, 테스트코드가 없어서 하나를 수정하면 여러곳에서 사이드 이펙트가 발생한다.
이는 개인과 조직 모두에게 비효율적이다.
Clean Code에 대한 공식과 정답은 없다.
Clean Naming
Clean Name이 중요한 이유
좋은 이름은 내부를 들여다보지 않아도 동작과 목적 쉽게 이해 가능
사람의 인지적 부하를 최소화 할 수 있다.
가독성 향상에 가장 중요한 요소이다.
SW의 주요 요소들은 모두 Clean Name이 필요하다.
Clean Naming 원칙
Clean Naming 원칙
모든 이름은 반드시 그 의미가 명확해야 한다.
Function, Class 역할이 명확하면 Naming도 명확해짐
불필요한 정보/반복은 제거
줄임말（약어）를 사용하지 말자
규칙과 일관성은 중요
동료와 상의해라
Variable를 위한 Clean Naming
Method를 위한 Clean Naming
Clean Method Name
Method의 이름은 의도와 기능을 명확하게 표현해야 함
만약 Method의 의도와 기능을 이해하기 위해 내부 코드를 들여봐야 한다면 Method의 이름은 개선 해야 될 필요가 있음
Method의 이름은 어떤 동작（동사）을 무엇을 대상（명사）으로 할 것인지로 표현 함
좋은 메소드는 작고, 한가지 일만 수행한다.
한가지 일만 수행하는 클린 메소드는 클린 네임을 짓기 쉽다.
이름을 정하기 어렵다면, 메소드가 클린한지를 먼저 고민해야 한다.
Class를 위한 Clean Naming
Clean Class Name
클래스의 의해 생성되는 객체를 의미 있게 설명해야 함
Class가 명확한 한 가지 책임을 갖고 있으면, 명확한 이름을 짓기 좋음
명사 또는 명사구를 사용하고, 동사는 사용하지 않음
구체적이고 명확한 이름 사용해라.
Convention을 준수하는 일관성 있는 이름을 사용해라.
보편적인 언어를 활용해라.
Coding Rule
Coding Rule
sw 개발 가이드라인 및 규칙의 모음
SW의 유지보수성 및 신뢰성 등 향상을 위해 준수가 강력히 권장 됨
각 언어 별로 다양한 단체/기업에서 발표
Coding Convention, Coding Standard, Coding Style Guide
Summary
SW 엔지니어는 Code를 읽고 이해하고 수정하는 데 대부분의 시간을 사용
SW 유지보수를 효율적으로 하기 위해서는 높은 가독성이 필수
이해하기 쉬운 좋은 이름은 읽는 사람의 인지적 부하를 최소화 시킴
sw 모든 요소들에 좋은 이름이 필요 • Variable / Constant • Method / Function • Class / File
가장 중요한 것은 "이 이름을 내 동료가 쉽게 이해할 수 있을까? 하는 질문
그리고 동료들과 함께하는 지속적인 개선
Clean Method
Method/Function은 SW에서 가장 기본이 되는 모듈
Method를 호출하는 사람이 사용하기 용이해야 함
Method를 유지보수 하는 사람이 이해하고, 변경하기 용이해야 함
Method를 유지보수 하는 사람이 테스트 하기 용이해야 함
Clean Methods Principles
가능한 한 충분히 작아야 한다
한 가지를 해야 한다. 그 한 가지를 잘 해야 한다
테스트 가능해야 한다
중복이 없어야 한다
Parameter와 Clean Method
파라미터 원칙
Method를 호출하는 사람의 인지적 부하를 최소로 만들어 주어야 함
Method를 호출할 때마다 내부 코드를 보거나 API 문서를 보지 않게끔 해야 함
Parameter의 개수는 가능한 한 적어야 함
Clean Method의 크기
작고 역할이 명확한 메소드는?
읽고 이해하기 용이
기존 코드를 수정하기 용이
단위 테스트하기 용이
재사용성이 높음
중요한 것은 지속적인 개선
라인 수 보다 중요한 것은 자신의 코드에 대한 끊임 없는 질문과 개선
이 함수를 동료가 쉽게 이해할 수 있을까?
충분히 작은가? 더 작게 분할 가능한가?
단위 테스트 코드에 의해 충분히 테스트 되고 있는가?
너무 많은 역할을 하고 있지는 않을까?
Kent Beck's Four Simple Design Rules
- 모든테스트를실행해야한다
- 중복을 없애야한다
- 프로그래머의 의도를 잘 설명해야 한다
- 클래스와 메소드의 크기를 최소한으로 유지한다
메소드의 크기
10 ~ 100 라인 사이가 적절, 그러나 숫자에 집착할 필요는 없음
1개의 Method는 스크롤링을 하지 않고 읽을 수 있어야 함
단위 테스트 케이스를 작성하는 데 어려움이 없어야 함
Method 동작을 설명하기 위해 내부에 주석을 달아야 하면 Bad Smell!
(주석이 필요한 코드들은 새로운 Method로 추출)
한 가지의 명확한 역할
한 가지의 명확한 일을 하는 메소드는?
명확한 네이밍이 가능하고, 이름만으로 기능 이해 가능
복잡도가 낮아질 사능성 높음 (조건문의 복잡한 중첩구조 적음)
메소드의 내부 코드를 이해하고 수정하기 용이하다.
단위 테스트가 용이하다.
하나의 Method는 동일한 추상화의 수준만 가져야 한다
하나의 Method는 동일한 추상화의 수준만 가져야 한다
Method의 이름이 책임지는 범위의 일만 해야 한다
중복 코드
중복 코드란?
일정 라인 수 이상이 다수 중복되어 존재하는 코드
개발자는 복사 / 붙여넣기의 유혹과 갈등하는 경우 있음
기존 메소드/클래스를 수정하기 두려운데 복사/붙여넣기 해서 조금만 수정할까?
중복 코드는 다양한 문제점을 발생 시킴
중복 코드의 문제점
불필요하게 코드 베이스를 크게 만듦
코드를 수정해야 할 때 중복 된 다수의 코드를 모두 수정해야 함
일부 누락될 시 에러 발생 가능
중복 코드에 잠재적 결함이 있을 시, 결함도 같이 중복 됨
중복 코드의 발견
코드 리뷰(수동으로 전체 SW 시스템의 중복을 다 발견하기는 쉽지 않음)
정적 분석(정적 분석 도구 활용 - CPD, Atomiq)
중복 코드의 해결
다양한 Refactoring 전략 및 Design Pattern 적용
Extract Method
• 중복 된 코드를 새로운 Method로 추출
• 기존 중복 코드의 부분에서 새로운 Method를 호출
Extract Superclass
• 서로 다른 클래스에 코드가 중복 될 경우
• 중복 코드 부모 클래스에 위치시키고 기존 클래스들은 해당 클래스를 상속
깨진 유리창 이론과 Clean Code
SW Aging
처음 sw가 설계되고 구현 되었을 때가 가장 품질이 좋음
SW가 오래 유지보수 될 수록 기술 부채가 늘어남
• 코드 품질 저하 • 아키텍처품질 저하 • 실제 SW와 문서 간의 차이 발생
SW를 완전 재개발 해야 되는 상황이 발생
• 기존 코드를 유지보수 하는 비용이 더 큼
깨진 유리창 이론
깨진 유리창을 방치하면 그 장소를 중심으로 범죄가 확산 됨
사소한 문제를 방치하면 빠르게 큰 문제로 번질 가능성이 높음
깨진 유리창 이론과 Long method
작고 명확하게 한 가지 일을 하는 Method는 수정 할 때도 더 신경 쓰게 됨
나 때문에 이 Method의 품질이 낮아지는 건 아닐까?
그러나 200 라인 Method에 10라인 추가하는 것은 죄책감이 들지 않음
심지어 클린 코드의 지식이 있는 경우에도 동일
보이스카우트 법칙과 비자아적 프로그래밍
보이스카우트 법칙
캠프장에 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라
체크아웃 할 때보다 조금이라도 더 깨끗한 코드를 체크인 하라
아주 작은 개선이라도 지속 되면 코드는 나빠 지지 않음
• 조금 긴 함수를 분할 • 중복코드를제거 • 복잡한 if문1개 정리
보이스카우트 규칙의 전제
Clean Code를 장려하는 문화
단위 테스트 코드 필요
지속적인 코드 개선의 걸림돌
엔지니어는 자신의 코드에 자신의 자아를 투영하는 경향 있음
자신이 작성한 코드에 과도한 애착을 갖고, 심각한 방어적 태도 갖는 경우 존재
자신의 코드를 리뷰 받고 수정하는 것에 대한 거부감
자신의 코드를 다른 사람이 수정하는 것에 대한 거부감
비자아적 프로그래밍(Egoless Programming)
엔지니어 개개인의 요소들을 최대한 제거함으로써 전체 SW 품질을 높이는 문화
각자 만든 코드에 개인의 자아를 투영하지 말하야 함
코드에 대한 공동 소유, 공동 책임 철학을 강조해야 함
프로젝트 초기부터의 지속적인 코드 리뷰 또는 페어 프로그래밍으로 달성 가능
비자아적 프로그래밍을 위한 가이드
당신이 실수 할 수 있다는 것을 받아 들여라
당신과 당신이 작성한 코드는 다르다
당신보다 지식이 적은 사람이라도 존중하고 인내를 갖고 대하라
세상에 고정되어 있는 것은 없다 변화를 받아들여라
사람이 아닌 코드를 비판하여라 사람에게는 친절히 대하라
Method 측정 지표
1 Lines Of Code
Method의 길이를 측정
조직에서 Bad Smell의 기준을 정하고 이를 넘는 Method 검출
기존 시스템의 Method들 LOC의 평균/표준편차 등을 측정한 후 Outlier 검출
Cyclomatic Complexity
Method 내부의 복잡도를 측정 하는 지표
Method 내부의 조건문 중첩이 복잡할 수록 높아짐
CC가 높을 수록 테스트가 어렵고, 수정이 어려움
• < 10 권장 됨 • 11-20 유지보수 하기 다소 어려움 • 21 + Refactoring 필요함
Summary: Clean Method
클린 메소드
Method를 호출하는 사람이 사용하기 용이해야 함
Method를 유지보수 하는 사람이 이해하고, 변경하기 용이해야 함
Method를 유지보수 하는 사람이 테스트 하기 용이해야 함
Clean Comment
Comment
Comment는 Code에 대한 사람이 읽을 수 있는 부가 설명
사람이 Code를 더 쉽게 이해할 수 있게 하는 것이 목적
일반적으로 Compiler/Iinterpreter는 Comment를 실행하지 않고 무시
Clean Comment Principle
Comment는 필요악이다
Comment는 대부분의 상황에서 사용하지 말하야 한다
그러나 Comment를 사용해야 하는 몇 가지 예외 상황이 있다
Comment보다 Code 그 자체가 의미가 있어야 함
Comment로 부가 설명이 필요하면 Code가 충분히 의미 있지 못하다는 것
의미 있는 이름, 명확한 Code는 어렵고, Comment는 쉬움
Comment에 의지하기 보다 의미 있는 Code를 작성하는 노력이 필요
Comment는 최신 정보를 담지 못한다
처음 신규 코드를 작성할 때에는 Comment도 정성스럽게 작성
Code가 바뀌면? Comment도 항상 최신 정보로 수정하는가?
Code 변경 시 Comment 변경도 필수인가?
Comment의 정보는 잘못 된, 오래 된 정보를 담고 있을 가능성 높음
Comment는 불필요하고 중복된 정보를 포함
Code로 의미를 표현하고 있는 경우, Comment는 필요 없는 중복 정보 코드의 수정 이력을 표현 하는 Comment : 형상 관리 도구로 충분히 정보를 담을 수 있음
Bad Comment
의미가 모호한 코드를 설명하는 Comment
중복된 정보를 나타내거나 의무적으로 작성하는 Comment
중복된 정보를 나타내거나 의무적으로 작성하는 Comment
Comment 처리 된 Code
이력은 남겨놓은 Comment
대부분의 코멘트는 불필요한 내용이다.
Clean Comment
Comment를 사용하지 않는 것
코멘트가 필요한 예외상황은 많지 않다.
저작권 등을 명시하는 Comment
다수가 사용하는 Open API의 문서화
이름만으로 충분히 의미를 전달하기 어려운 경우
TO DO Comment
Clean Formatting
문학적 프로그래밍
Donald Knuth에 의해 주창 된 개념
코드는 사람이 읽도록 만들어지는 것이 우선
문학 작품을 읽는 것처럼 코드를 읽을 수 있도록 만들어져야 함
프로그래밍이란 컴퓨터가 어떤 동작을 하기 원하는지 "사람에게 설명 " 하는 행
수직적 (Vertical) Formatting
코드의 위에서 아래로 진행된 흐름과 관련 된 코드 작성 규칙
코드 라인간의 간격, 밀접한 관계를 가지는 코드 간 그룹화 등 이 포함됨
수평적(Horizontal) Formatting
하나의 코드 행에서 왼쪽에서 오른쪽으로 진행된 흐름과 관련 된 코드 작성 규칙
들여쓰기, 코드 간 간격, 코드 행의 넓이 등 이 포함됨
Clean Formatting
Formatting은 중요함, 동작에 영향을 미지지 않는다고 해서 무시해서는 안됨
Formatting만 변경되어도 코드의 가독성은 향상 됨
조직 내 Formatting 규칙을 정하고 반드시 모두가 그 규칙을 따라야 함
Clean Formatting의 확인
코드리뷰
정적분석
수직적 Formatting의 목표
수직적 Formatting은 Enter 같은 개행 문자를 이용해 Formatting 하는 것을 의미
마치 신문기사처럼 위에서 아래 쉽게 읽혀 나갈 수 있는 것을 목표로 함
추상화의 수준 순서로 코드를 배치
서로 다른 개념은 분리
유사한 개념은 모아 놓음
관계 있는 내용은 가까운 행에 작성
수평적 Formatting 원칙
수평적 Formatting은 코드 한 줄에 대해서 Formatting 하는 것을 의미
좌우 횡스크롤링 없이 코드를 읽을 수 있어야 함
코드 한 줄을 스크롤의 이동없이 볼 수 있는 것을 목표로 함（약 80자）
최근에는 모니터의 크기가 커져 100자〜120자도 좋음
전략
들여쓰기를 적극적으로 활용
한 줄의 긴 코드를 여러 줄의 짧은 코드로 분리
수평 정렬은 중요하지 않음
Clean Control Structures
Control Structures와 Clean Code
Control Structures 는 코드 복잡도에 가장 큰 영향을 주는 요소 특히 중첩된 Control Structures 는 코드의 가독성 저하, 복잡도 증가, 테스트용이성 저하
Cyclomatic Complexity
소스 코드의 복잡도를 나타내는 지표
1976년 Thomas J. McCabe에 의해 고안
복잡도가 낮을수록 프로그램이 구조적으로 안정되었다는 의미이며, 복잡도가 높을수록 프로그램이 비 구조적이며 불안정하다는 의미
프로그램의 제어 흐름을 node, edge 로 표현한 그래프를 기반으로 계산
Cyclomatic Complexity 의 기준
소프트웨어의 규모, 도메인 특성 등에 따라 Cyclomatic Complexity 기준 달라짐
개발 초기부터 코드 복잡도를 고려한 Control Structures 의 설계가 중요
읽기 쉬운 조건문 Fail Fast! Early Return! 최대한 긍정 조건으로 표현하라
읽기 쉬운 조건문
Control Structures 의 조건문
조건문의 구성
- 비교할 대상이 되는 특정 변수, 특정 값
- 결과가 Boolean(True/False) 이 되는 비교, 논리 연산자
매직 넘버와 가독성
매직 넘버란, 그 의미를 알 수 없는 임의의 수
조건문에서의 매직 넘버는 코드의 가독성을 해치는 주요 원인
코드를 이해하기 위해 별도의 문서와 시간이 필요함
조건문을 구성하는 오른쪽 항의 값은 잘 설명할 수 있는 명확한 상수로 설계되어야 한다.
삼항 연산자와 가독성
삼항연산자를 사용하려면 항상 가독성을 고려해야 한다.
코드의 라인을 최소화하는 것 보다, 코드를 읽고 이해하는 시간을 최소화하는 것이 중요
기본적으로 if-else 로 표현하는 것이 자연스러움
Fail Fast! Early Return!
핵심 로직을 처리 하기 전에 다수의 사전 검증 로직이 필요한 경우
사전 검증 로직과 핵심 로직이 혼재되어 코드의 가독성 낮아짐
검증 영역과 핵심 로직 영역이 분리 됨
Method의 복잡도가 낮아짐
가독성이 향상되고, 테스트가 용이해짐
최대한 긍정 조건으로 표현하라
부정 표현 vs 긍정 표현
긍정적인 표현은 부정적 표현보다 이해하기 상대적으로 용이하므로, 조건문은 긍정 표현을 사용하는 것이 가독성 관점에서 좋다.
Clean Code를 위한 Code Refactoring
Code Refactoring의 개념
Refactoring
sw 품질 향상을 목적으로 기능의 변경 없이, 내부 코드를 변경하는 기술
기존 기능에 변경을 가하지 않는 수준의 아주 작은 코드 개선 작업
하나 하나의 Refactoring은 너무 작아서 큰 의미가 없음
그러나 작은 개선이 쌓이면 의미 있는 품질 향상이 가능
Refactoring은 매일 개발의 일부로 진행하는 것
Refactoring은 특별한 활동이 아님 기능 추가/변경을 위해 코드를 수정
개선이 필요한 코드를 발견
코드 개선
보이스카우트 법칙
Code Bad Smell
Clean 품질을 저해할 수 있는 가능성을 가진 코드가 보내는 경고 싸인
Code Bad Smell은 결함이나 에러는 아님
지속적 코드 개선을 위해서는 Bad Smell을 맡을 수 있는 코가 필요
Martin Fowler가 Refactoring 도서에 22개의 Code Bad Smell의 종류를 정리
Code Refactoring 카탈로그
Code Bad Smell에 대한 다양한 개선 전략들의 모음
Category 별로 정리되어 있음
Refactoring은 아주 작은 개선 활동
너무 당연하다고 판단 될 만한 전략들도 다수 존재
