🌊 Clean Code

※ 이 글은 코드프레소 체험단 활동을 하면서 만들어졌습니다.
※ SW 유지보수성 향상을 위한 Clean Code 강의입니다.
※ 코드프레소 바로가기

Clean Code 과정의 목표

• 유지보수성 높은 SW의 중요성을 인식한다
• 유지보수성 높은 SW를 개발하기 위한 고민거리를 제공한다
• 유지보수성을 떨어뜨리는 Bad Smell에 대한 감을 익힌다

Clean Code 의 공통적 의견

• 사람이 읽고 이해하기 쉽다
• 단순한 한 가지 역할을 하고, 명확한 이름(표현)을 갖고 있다
• 중복이 없다
• 테스트 케이스가 있다
• 이해하기 쉽고, 변경하기 쉬운 코드

Clean Naming

왜 Clean Naming이 중요할까?

• 우리는 개발의 약 75%의 시간을 코드를 읽고 이해하는데 사용
• 변수, 상수, 함수, 클래스, 파일 등 SW의 주요 요소는 이름을 가짐
• 좋은 이름은 내부를 들여다보지 않아도 동작과 목적을 쉽게 이해할수 있음
• 좋은 이름을 사용하면 코드를 읽는 사람의 인지적 부하를 최소화 가능

Clean Naming 원칙

• Funtion, Class 역할이 명확하면 Naming도 명확해 집니다
• 불필요한 정보/반복은 제거해야 함
• 줄임말(약어)를 사용하지 마세요
• 규칙과 일관성을 중요합니다
• 동료와 상의

Clean Code : Summary

• SW엔지니어는 Code를 읽고 이해하고 수정하는데 대부분의 시간을 사용
• SW 유지보수를 효울적으로 하기 위해서는 높은 가독성이 필수
• 이해하기 쉬운 좋은 이름은 읽는 사람의 인지적 부하를 최소화 시킴
• SW 모든 요소들에 좋은 이름 필요
  - Variable / Constant
  - Method / Function
  - Class / File
• 가장 중요한 것은 "이 이름이 내 동료가 쉽게 이해 할수 있을까?" 라는 질문
• 동료들과 함께하는 지속적인 개선

Clean Method

Clean Method

• Method / Function은 SW에서 가장 기본이 되는 모듈
• Method를 호출하는 사람이 사용하기 용이 해야 함
• Method를 유지보수 하는 사람이 이해하고, 변경하기 용이해야 함
• Method를 유지보수 하는 사람이 테스트 하기 용이해야 함

Clean Method Principles

• 가능한 충분히 작아야 한다
• 한 가지를 해야한다. 그 한가지를 잘해야 한다
• 테스트 가능해야 한다
• 중복이 없어야 한다

Clean Method Parameter 원칙

• Method를 호출하는 사람의 인지적 부하를 최소로 만들어 주어야 함
• Method를 호출할 때마다 내부 코드를 보거나 API 문서를 보지 않게해야함
• Parameter의 개수는 가능한 적어야 함

Clean Method : Summary

• Method를 호출하는 사람이 사용하기 용이해야 함
• Method를 유지보수 하는 사람이 이해하고, 변경하기 용이해야 함
• Method를 유지보수 하는 사람이 테스트 하기 용이해야 함

Clean Method Principles : Summary

• 가능한 충분히 작아야 한다
• 한 가지를 해야한다. 그 한가지를 잘해야 한다
• 테스트 가능해야 한다
• 중복이 없어야 한다

Clean Method를 위해서 : Summary

• 적은 Parameter 개수
• 명확한 Clean Name
• 작은 크기
• 명확한 역할
• 중복 없는 상태
• 높은 테스트 커버리지, 테스트 용이서

Clean Method는 하루아침에 만들어지지 않는다 : Summary

• 충분히 좋은지에 대한 지속적인 의심, 질문 그리소 개선
• 좋은 Method의 기준에 대한 열린 토론과 그로 만들어지는 컨센서스
• 모든 동료들이 함께하는 코드 품질 개선 문화

Clean Comment

Comment

• Comment는 Code에 대한 사람이 잀을 수 있는 부가 설명
• 사람이 Code를 더 쉽게 이해할수 있게 하는 것이 목적
• 일반적으로 Compiler/Interpreter는 Comment를 실행하지 않고 무시

Clean Comment Principle

• Comment는 필요악이다
• Comment는 대부분의 상황에서 사용하지 말아야 한다
• 그러나 Comment를 사용해야 하는 몇가지 예외상황이 있다

Comment보다 Code 그 자체가 의미가 있어야 함

• Comment로 부가 설명이 필요하면 Code가 충분히 의미 있지 못하다는것
• 의미있는 이름, 명확한 Code는 어렵고, Comment는 쉬움
• Comment에 의지하기 보다 의미있는 Code를 작성하려는 노력이 필요

Comment는 최신 정보를 담지 못함

• 처음 신규 코드를 작성할때는 Comment도 정성스럽게 작성
• Code 가 바뀌면? Comment도 항상 최신 정보로 수정하는가?
• Comment의 정보는 잘못된, 오래된 정보를 담고 있을 가능성 높음

Comment는 불필요하고 중복된 정보를 포함

• Code로 의미를 표현하고 있는 경우
• 코드의 수정 이력을 표현하는 Comment
  - 형상 관리 도구로 충분히 정보를 담을 수 있음

Clean Comment

• Comment를 사용하지 않는것
• 저작권 등을 명시하는 Comment
• 다수가 사용하는 Open API의 문서화
• 이름만으로 충분히 의미를 전달하기 어려운 경우
• To Do Comment

Clean Comment : Summary

• Comment는 기본적으로 Bad Smell
  - Code로 충분히 의미를 설명하지 못함
  - 불필요한, 중복적인 정보를 제공
  - 잘못된 정보를 제공
• Comment를 가급적 피하고 Code로 의미를 표현해야 함
• Clean Comment 예외 상황에는 적절한 Comment사용필요

Clean Formatting

문학적 프로그래밍

• Donald Knuth에 의해 주장된 개념
• 코드는 사람이 읽도록 만들어지는 것이 우선
• 문학 작품을 읽는 것처럼 코드를 읽을수 있도록 만들어져야 함
• 프로그래밍이란 컴퓨터가 어떤 동작을 하기 원하는지 "사람에게 설명"하는 행위

Code Formatting 이란?

• Code Formatting은 코드의 가독성과 이해도를 높여주는 일련의 작업
• 수직적 Formatting과 수평적 Formatting 원칙으로 분류됨

수직적(Vertical) Formatting

• 코드의 위에서 아래로 진행된 흐름과 관련 도니 코드 작성 규칙
• 코드 라인간 간격, 밀접한 관계를 가지는 코드 간 그룹화 등이 포함
• 추상화의 수준 순서대로 코드를 배치
• 서로 다른 개념은 분리
• 유사한 개념은 모아 놓음
• 관계있는 내용은 가까운 행에 작성

수평적(Horizontal) Formatting

• 하나의 코드 행에서 왼쪽에서 오른쪽으로 진행된 흐름과 관련된 코드 작성 규칙
• 들여쓰기, 코드 간 간격, 코드 행의 넓이 등이 포함
• 들여쓰기를 적극적으로 활용
• 한줄의 긴 코드를 여러줄의 짧은 코드로 분리
• 수평정렬은 중요하지 않음

Clean Formatting : Summary

• 좋은 코드는 문학 작품과 같이 읽을수 있어야함
• Formatting은 동작에는 영향을 미치지 않으나 가독성에는 크게 영향을 미침
• 조직 내 규칙을 정햐야 하고, 모든 개발자는 규칙에 따라 Formatting해야함
• 코드 리뷰와 정적 분석 도구를 활용하여 Formatting을 지속적으로 확인해야 함

Clean Control Structures

Control Structures란?

• 조건 루프, 흐름은 제어하는 선언문

Control Structures 와 Clean Code

• Control Structures는 코드 복잡도에 가장 큰 영향을 주는요소
• 특히 중첩된 Control Structures는 코드 가독성, 테스트 용이성 떨어지고, 복잡도는 올라감

Clean Control Structures

• 개발 초기부터 코드 복잡도를 고려한 Control Structures의 설계가 중요
  - 읽기 쉬운 조건문
  • Fail Fast!, Early Return!
  • 최대한 긍정으로 표현하라

Clean Control Structures : Summary

• Control Structures는 신경 쓰지 않으면 복잡도를 증가시킴
  - 가독성을 심각하게 저해하고
  • 테스트를 어렵게 만듬
• Control Structures 최대한 이해하기 쉽고 중첩이 적은 방향으로 설계, 작성
• Fail Fast!, Early Return!또는 Method 추출 기법으로 가독성 향상이 가능한지 항상 확인해야함

Clean Code를 위한 Code Refactoring

Refactoring

• SW품질 향상을 목적으로 기능의 변경 없이, 내부 코드를 변경하는 기술

Refactoring 철학

• 티끌모아 태산
• 기존 기능에 변경을 가하지 않는 수준의 아주 작은 코드 개선 작업
• 하나 하나의 Refactoring은 너무 작아서 큰의미 없음
• 작은 개선이 쌓여 의미있는 품질향상이 가능

Code Bad Smell

• Clean 품질은 저해 할수 있는 가능성을 가진 코드가 보내는 경고 싸인
• Code Bad Smell은 결함이나 에러는 아님
• 22개의 Code Bad Smell 종류

Refactoring 카탈로그

• Code Bad Smell에 대한 다양한 개선 적략들의 모음
• Refactoring은 아주 작은 개선 활동
• 너무 당연하다고 판단 될만한 전략들도 다수 존재

Code Refactoring : Summary

• ReFacoring 은 매일 지속적으로 수행하는 작은 코드 개선 작업
• 티끌모아 태산
• 개선해야할 코드의 Bad Smell을 맡는 민감한 코를 갖도록 훈련해야함
• 정리된 Code Bad Smell과 Refactoring Catalog를 참고하는건 좋은 습관