SW 유지보수성 향상을 위한 Clean Code

코드프레소 Java 웹 개발 체험단 활동 중

SW 유지보수성 향상을 위한 Clean Code 강좌를 기반으로 작성하였습니다.

코드프레소 URL: https://www.codepresso.kr/

---

 

Clean Code란 무엇인가?

• 이해하기 쉽고, 변경하기 쉬운 Code
• 사람이 읽고 이해하기 쉽고, 명확한 한가지 역할을 하며, 이 역할을 의미 있게 표현하고, 중복이 없고 테스트 케이스가 존재하는 코드

Clean Code가 중요한 이유

• SW는 한번 신규 개발되고, 오랜 기간 동안 유지 보수 됨
• 기존 코드에 추가 작업하는 시간이 압도적으로 많음
• 대부분의 시간을 기존 코드를 읽고, 이해하는 데 사용

---

Clean Naming

• SW의 주요 요소는 이름을 갖고 있다
• 좋은 이름은 내부를 들여다보지 않아도 동적과 목적을 쉽게 이해할 수 있다
• 좋은 이름을 사용하면 코드를 읽는 사람의 인지적 부하를 최소화 할 수 있다

프로그래머의 가장 어려운 task로 naming이 49%

 

1. Clean Naming의 원칙

• Function, Class 역할이 명확하면 Naming도 명확해 집니다
  • Clean Function,Class의 1원칙은 명확히 한 가지 역할을 하는 것
• 불필요한 정보/반복은 제거해야 합니다
  • 이름은 이해가능한 최소한의 정보를 담고 있어야 함
  • ex ) UserData(x)
• 줄임말(약어)를 사용하지 마세요
  • 누구나 이해할 수 있는 줄임말은 존재하지 않음 (줄임말은 가독성을 심각하게 저하 시킴)
• 규칙과 일관성은 중요합니다
  • 일관성은 코드를 이해하고 수정하는 노력을 감소시킴
• 동료와 상의하세요

2. Clean Variable Naming

- Bad Smell

Bad Smell Pattern	Ex
단일 문자로 이루어진 이름	p,x,y,u
줄임말	usr,prc,tmp,acc
불필요한 정보	productInfo,Data,Object
명확하지 않은 이름	data,user,person
숫자 접미사	user2,emp3

3. Clean Method Name

• 좋은 메소드는 작고, 한 가지 일만 수행함

-Bad Smell

• Method가 이름보다 더 많은 기능을 수행 함
• 이름에 and, or, if/else가 포함 되어 있음
• 동일한 동작에 대해 동사 단어가 일관성이 있게 사용되지 않음
• 동사의 의미가 모호함

4. Clean Class Name

• 명사 또는 명사구를 사용하고, 동사는 사용하지 않음

• 구체적이고 명확한 이름을 사용하라
• 컨벤션을 준수하는 일관성 있는 이름 사용하라
  • 보편적 기술 용어를 활용 - Factory, Builder, Observer ,Controller
• 보편 언어를 활용하라
  • 도메인 전문가, SW 아키텍트, 개발자의 언어를 모두 통일 해야 함
  • 기준은 도메인 전문가들이 사용하는 언어가 됨
  • 이 언어는 모든 커뮤니케이션, 설계문서, 실제 코드까지 통일되어야 함
  • 클래스 이름을 도메인 전문가들이 보고 이해할 수 있어야 함

5. Coding Rule

• SW 개발 가이드라인 및 규칙의 모음
• Coding Rule의 종류

• Coding Rule의 준수 여부 확인

 

---

Clean Method

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

1. Parameter와 Clean Method

• Method를 호출하는 사람의 인지적 부하를 최소로 만들어 주어야 함
• Parameter의 개수

• Parameter 개수가 3-4개 이상일때
  • Method를 분할
  • Parameter Data를 저장하는 Object 활용 ( 클래스를 생성하여 객체 사용 )
  • Map의 사용

    

 

 

 

 

 

2. Clean Method의 크기

작고 역할이 명확한 메소드는

• 읽고 이해하기 용이
• 기존 코드를 수정하기 용이
• 단위 테스트하기 용이
• 재사용성이 높음

크기만으로 메소드의 품질을 판단 할 수는 없다

• 중요한 것은 지속적인 개선
  • 라인 수 보다 중요한 것은 자신의 코드에 대한 끊임 없는 질문과 개선

3. 한 가지의 명확한 역할

• 명확한 naming이 가능하고, 이름만으로 기능 이해 가능
• 복잡도가 낮아질 가능성이 높음 - 조건문의 복잡한 중첩구조가 적음
• 내부 코드를 이해하고 수정하기 용이
• 단위 테스트하기 용이

하나의 메소드는 동일한 추상화의 수준만 가져야한다

• 추상화 수준이란?

ex)

높은 추상화 수준의 메소드가 들어가있다

다른 추상화 수준의 메소드들이 같이 있음

4. 중복 코드

• 일정 라인 수 이상이 다수 중복되어 존재하는 코드
• 문제점
  • 불필요하게 코드 베이스를 크게 만듦
  • 코드를 수정해야 할 때 중복 된 다수의 코드를 모두 수정해야 함
  • 중복 코드에 잠재적 결함이 있을 시, 결함도 같이 중복 됨
• 중복 코드의 해결
  • 중복된 코드를 새로운 메소드로 추출
  • 서로 다른 클래스에 코드가 중복 될 경우 : 중복 코드를 부모 클래스에 위치시키고 기존 클래스들은 해당 클래스를 상속
  • Template Method Pattern - 알고리즘의 일부가 중복되는 경우

5. 깨진 유리창 이론과 Clean Code

• 깨진 유리창을 방치하면 그 장소를 중심으로 범죄가 확산 됨
• 깨진 창문이 일정 수준 이상 많아지면 개발자들은 자포자기 함 
• 창문을 깨지지 않게, 깨진 창문도 정상화는 조직 차원의 문화가 형성 되어야 함

6. 보이스카우트 법칙과 비자아적 프로그래밍

보이스카우트 법칙

• 캠프장에 처음 왔을 때 보다 더 깨끗하게 해놓고 떠나라
• 체크아웃 할 때보다 조금이라도 더 깨끗한 코드를 체크인 하라
  • 전제 : Clean Code를 장려하는 문화 & 단위 테스트 코드

비자아적 프로그래밍

• 엔지니어 개개인의 요소들을 최대한 제거함으로써 전체 SW 품질을 높이는 문화
• 각자 만든 코드에 개인의 자아를 투영하지 말아야 함
• 코드에 대한 공동 소유, 공동 책임 철학을 강조해야 함

7. Method 측정 지표

• Lines Of Code
  • Method의 길이를 측정
  • 조직에서 Bad Smell의 기준을 정하고 이를 넘는 메소드 검출
  • 기존 시스템의 메소드들 LOC의 평균/표준편차 등을 측정한 후 Outlier 검출

    

• Cyclomatic Complexity
  • Method 내부의 복잡도를 측정하는 지표

---

Clean Comment

• Comment는 Code에 대한 사람이 읽을 수 있는 부가 설명
• Code를 더 쉽게 이해할 수 있는 데 목적

1. Clean Comment의 원칙

• Comment는 필요악이다
• 대부분의 상황에서 사용하지 말아야 한다

• Comment에 의지하기 보다 좋은 Code를 위해 노력해야 함
• Commet는 최신 정보를 담고 있지 못함, 불필요하고 중복된 정보를 포함

2. Bad Comment

• Code 자체로 충분히 명확한 표현이 안될 때 가독성 향상을 목적으로 Comment를 작성하지만 이럴 때는 Code 자체를 개선해야 함
• 중복된 정보를 나타내거나 의무적으로 작성하는 Comment - 중복은 제거해야 마땅함
• Comment 처리 된 Code : 필요 없지만 없애기 아까운 Code는 형상관리도구로 관리
• 이력을 남겨놓은 Comment : 형상관리 도구에서 관리
• Comment는 Code Bad Smell이라는 점 기억

3. Clean Comment

Comment를 사용하지 않는 것이 최고의 Clean Comment

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

• TO DO Comment

---

Clean Formatting

• 코드의 가독성과 이해도를 높여주는 일련의 작업

1. 수직적 Formatting 원칙

• 메소드를 추가 할 대는 시간적 순서가 아닌 논리적인 관련성에 따라 배치해야 함

2. 수평적 Formatting 원칙

• 수평적 Foramatting은 코드 한 줄에 대해서 포맷팅하는 것을 의미
• 좌우 횡스크롤링 없이 코드를 읽을 수 있어야 함

---

Clean Control Structure

• Control Structures : 조건, 루프, 흐름을 제어하는 선언문 / 코드 복잡도에 가장 큰 영향을 주는 요소

1. 읽기 쉬운 조건문

• 연산자를 기준으로

• 매직 넘버와 가독성
  • 조건문을 구성하는 오른쪽 항의 값은 잘 설명할 수 있는 명확한 상수로 설계되어야 한다
• 삼항 연산자
  • 사용시 항상 가독성을 고려해야 함

2. Fail Fast, Early Return

• 사전 검증 로직과 핵심 로직이 혼재되면 코드의 가독성이 낮아짐

검증 영역과 핵심 로직 영역이 분리되어 복잡도가 낮아짐, 테스트 용이

 

중첩 제거

3. 최대한 긍정 조건으로 표현하라

• 조건문은 긍정 표현을 사용하는 것이 가독성 관점에서 좋다

!를 사용하는 조건은 긍정을 표현하는 Method로 치환

---

Code Refactoring

• SW 품질 향상을 목적으로 기능의 변경 없이, 내부 코드를 변경하는 기술
• Refactoring은 특별한 활동이 아닌 매일 개발의 일부로 진행하는 것

Refactoring 카탈로그 - examples

Primitive Obsession