<코드 프레소 웹개발 트랙> SW 유지보수성 향상을 위한 Clean Code

 

Clean Code

 : 어떤 코드가 좋은 코드 일까?

• 코드의 품질은 매우 주관적인 주제이다
• 개인마다 좋은 코드에 대한 서로 다른 정의와 수준을 가지고 있음
• 코드 품질, SW 품질에 대한 서로 다른 시각은 품질 향상의 걸림돌이다.'
• Claen Code는 개인과 조직의 노력이 동시에 필요로 한다.

Naming	개발 속도를 위해 약어를 써야 해 Manager와 같은 접미사를 사용해야 해	약어는 절대 사용하지말고, 반복적이고 불필요한 단어는 제거해야해
Comment	최대한 상세히 주석을 달아야 해 코드 수정 이력 등도 주석에 적어야 해	주석은 Bad Smell 이야 최소로 해야 하고 코드로 표현해야 해
Method,  Class 크긱	너무 작고 많으면 유지보수가 힘들어	크기는 가능한 작고 역할을 명확해야 해
중복 코드	기존 코드를 빠르게 복사해서 개발 속도를 향상하자	중복 코드는 무조건 제거되야 해
테스트 코드	테스트 코드는 코드 기능에 영향을 미치지 않고, 공수가 너무 많이 드는 작업이야	중장기적인 유지보수성 향상을 위해서 테스트 코드는 필수적이야

1. 클린 코드의 목적과 중요성을 이해해야 한다
2. 클린 코드의 기준과 방향성을 조직에서 합의해야 한다.
3. 클린코드를 위해 지속적으로 개선해야 한다.
4. 클린코드란 "이해하기 쉽고, 변경하기 쉬운 Code"를 의미한다.
5. 클린코드에 대한 엄격한 정의는 없다.

 

 

Clean Code 

클린 코드에 대한 정의는 없지만, 중복되게 나오는 정의를 살펴보면 아래와 같다.

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

이를 위해서 앞으로 다룰 Clean Code의 주제는 다음과 같다.

Clean Code를 위한 주제

 

중요하지만 Clean Code의 범위에는 속하지 않는 것
- 자료구조 & 알고리즘
- SW성능 개선
- 신뢰성 , 안정성을 위한 개발 기법
- SW 아키텍처 설계 기법
- 언어 별 programming best practice

 

Clean Code의 중요성

 

• SW는 한번 신규 개발되고, 오랜 시간 동안 유지보수 된다.
• 기존 코드에 추가 작업하는 시간이 압도적으로 많은 업무 비중을 차지함.
• 대부분의 시간을 기존 코드를 읽고, 이해하는데 사용된다.
• Code의 품질이 낮으면, 코드의 이해력과 복잡도가 낮아져 수정이 어려워짐
• 테스트 코드가 없어서, 하나를 수정하면 여러 곳에서 Side-effect가 발생한다
• 개인과 조직 모두에게 커다란 비용 Risk가 발생한다.

 

 

 

 

 

 

 

 

Clean Naming

---

Clean Nameing의 중요성

• 좋은 이름을 통해 내부를 보지 않아도 동작과 목적을 쉽게 이해할 수 있다.
• 좋은 이름을 사용하면 코드를 읽는 사람도 인지적 부하를 최소하 할 수 있다.
• 따라서 clean naming은 장기적으로 개발 생산성 향상을 가능하게 함

 

clean name 통해 표현해야 하는 요소들

 

Clean Variable Name	굳이 출력해보지 않아도 내부에 담긴 데이터를 알 수 있음
Clean Function/Method Name	내부 코드를 들여다보지 않아도 동작을 예측할 수 있음  내부 코드를 이해하지 못해도 활용하는 데 문제가 없음
Clean Class Name	이름만으로도 구체적으로 어떤 객체가 생성되는 지 파악 가능

 

 

Clean Naming의 원칙 :

"모두가 보기에 모든 이름은 반드시 그 의미가 명확해야 한다."

 

 

 

[1] Fution/Clas 역할이 명확하면 Naming도 명확해진다.

• Clean Function, Class의 제 1원칙은 명확히 한 가지 역할을 하는 것이다.
• 역할이 많으면 이름도 명확하지 않게 된다.

      - createAndSaveUserInfo() , User , GeneralUtil

• 명확한 이름을 짓기 어려운 경우, 해당 메소드/클래스가 너무 많은 역할을 수행하는지 고려해야함.

 

 

[2] 불필요한 정보/반복은 제거해야 한다.

• 이름은 이해가능한 최소한의 정보를 담고 있어야 한다. (짧지도 , 장황하지도 않게 )
• 불필요한 정보는 최대한 제거한다. ( (ex) UserData, processFunc ) 

 

 

[3] 줄임말(약어)를 사용하지 않는다

• 줄임말은 가독성을 심각하게 저하 시킨다.
• 누구나 이해할 수 있는 줄임말은 존재하지 않는다.

      (줄임말의 예)

  - tmep, prdt, usr => tempreature, product, user

  - acc() , inc()   => accelerateSpeed() , increasePrice() 

 

 

[4] 규칙과 일관성은 중요하다.

• 언어 별, 조직 별 Naming Convention은 일관성 있게 지켜야 된다.
• 일관성은 코드를 이해하고 수정하는 노력을 감소 시킴
• 일관성 없는 Naming은 가독성을 저하 시킴
• 언어 별 Naming Standard , Naming Convention이 존재한다.
• 공식 Guide를 조직에 맞게 커스터마이징 하여 내부 Guide를 결정한다.
• 코드 리뷰 시 Naming 등이 Guide를 잘 지키고 있는지 반드시 확인한다.

일관성이 지켜지지 않은 예시 
1. 우리팀은 정보를 조회할 때 get 동사를 사용하기로 약속함
2. User 정보를 조회하는 함수를 찾으려면 => getUser()
3. IDE로 검색 했더니 결과 없음
4. 결국 코드를 뒤져보니, xxx가 fetchUser()로 작성해놓음 

 

 

[5] 동료와 상의하라 !

• 모든 원칙을 적용해도 좋은 이름이 떠오르지 않을 때
• 내가 명명한 이름에 대한 확신이 없을 때
• 동료와 함께하는 리뷰, 브레인스토밍이 가장 좋은 방법이다.

   - 이 이름 괜찮은 것 같나요? 무슨 의미인지 이해가 되나요?? 

 

 

 

 

---

 

[1] Variable Naming for Clean Code

각 변수의 타입마다 변수의 이름을 작명하는 것을 의미한다.

각 타입별 변수에 대한 naming 

 

△ 변수 작명의 옳은 예시

Number , String 변수	listPrice, fixedPrice , discountedPrice
Object 변수	book, movieContent, discountedBundle
Boolean 변수	isFinishedDelivery

 

△ 변수 작명의 나쁜 예시 ( Bad Smell )

Bad Smell Pattern	EX
단일 문자로 이루어진 이름	p, x, y, u
줄임말	usr, prc, tmp, acc, inc
불필요한 정보	productInfo, productData, productObject
명확하지 않은 이름	data, object, user(customer, admin, ..) , person(seller, buyer, .. )
숫자 접미사	user2, emp3

 

 

 

 

[2] Method Naming for Clean Code

• method의 이름은 의도와 기능을 명확하게 표현해야 함
• 만약 method의 의도와 기능을 이해하기 위해 내부 코드를 들여봐야 한다면, 개선될 여지가 있음
• method의 이름은 어떤 동작을 무엇을 대상으로 할 것인지 표현 ( 동사 + 명사 ) 
• 좋은 Method는 작고, 한가지 일만 수행하고 이는 Clean name을 짓기가 쉽다.
• Method 이름을 정하기 어려우면, Metohd가 Clean한지를 먼저 고려해야 한다.

 

메소드의 작명시 고려해야 할 점

 

△ 메소드 작명의 옳은 예시

특정 기능을 수행하는 Method	getProductByCategory() ,  createAdminUser()
Boolean을 체크하는 Method	isValidatePassword() ,  isActivateUser()

 

△ 메소드 작명의 나쁜 예시 ( Bad Smell )

Bad Smell Pattern	EX
Method가 이름보다 더 많은 기능을 수행한다.	createUser() 에서 기존 User 정보 존재 시 Update 행위도 수행 isActivateUser() 에서 false 시 새로운 로그인 세션이 생성됨
이름에 and, or, if/else가 포함되어 있음	saveUserAndSendEmail() , createNormalUserOrAdminUser()
동일한 동작에 대해 동사 단어가 일관성 있게 사용되지 않음	retrieveProduct(), getUser(), fetchCategori(), findStock()
동사의 의미가 모호함	process(), do(), check(), handle()

 

 

 

[3] Class Naming for Clean Code

• 클래스에 의해 생성되는 객체를 의미 있게 설명해야 한다.
• Class가 명확한 한 가지 책임을 갖고 있으면, 명확한 이름 짓기가 수월하다.
• 명사 또는 명사구를 사용하고, 동사는 사용하지 않는다. ( CreateUser, PData (x) )

 

- Clean Class Naming Principle -

1. 구체적이고 명확한 이름을 사용하라 

Bad EX	Good EX
DataObj , PEnitiy	Product
DatabaseManager, URIHandler	DatabaseConnector, URIBuilder
DBCnct	DBConnector

 

 

2. Convention을 준수하는 일관성 있는 이름 사용하기

• 조직내부에서 특정 개념에 대한 용어를 정의하고 일관성 있게 사용하라
• 보편적 기술 용어를 활용하라 ( Factory, Builder, Observer, Controller ) 

  

  조직이나 보편적 기술을 통해서 일관성 있는 클래스 작명의 예시

3. 보편적 언어를 활용하라

• 도메인 주도 설계의 보편언어(Ubiquitous Language)
• SW는 복잡한 현실의 문제를 해결하기 위한 것이다
• SW는 요구사항, 분석, 설계, 구현, 테스트의 반복 사이클이다.
• 요구사항 단게의 도메인 전문가와 엔지니어의 멘탈 모델 사이 Gap으로 인해 유지보수성 낮은 SW가 개발
• 따라서 엔지니어는 현실의 문제(도메인)을 잘  파악한 후 설계와 코드에 반영해야 한다.
• ex) 은행 시스템의 엔제니어는 예금, 대출 등 은행 업무를 깊게 이해 해야한다.

(도메인 주도 설계 개발)
도메인 전문가 , SW 아키텍쳐 , 개발자 언어를 통일한다.
기준은 도메인 전문가들이 사용하는 언어를 추천한다
이 언어는 모든 커뮤니케이션, 설계문서, 실제 코드까지 통일되어야 함
클래스 이름을 도메인 전문가들이 보고 이해할 수 있어야 함

도메인 전문가와 엔지니어의 언어 에시

도메인 전문가와 엔지니어 사이의 서로 간의 반복적인 커뮤니케이션이 가장 중요하다.

도메인 전문가의 요구사항 변경 시 , 시스템에 잘 반영할 수 있게 된다.

서로 보편적 언어를 통해서 각 작업 상황과 변화에 대한 변경에 대한 이해가 효과적이다.

 

 

 

[4] Coding Rule 

 

• SW 개발 가이드라인 및 규칙의 모음
• SW의 유지보수성 및 신뢰성 등 향상을 위해 준수가 강력히 권장
• 각 언어 별로 다양한 단체/기업에서 발표
• Coding style + Coding ldoim
• Java의 경우 Google java style Guide, Oracle Code Convention 등이 있다.

 

Coding Style		Coding Idiom
- 유지보수성 , 가독성을 높이기 위한 스타일 - SW 동작에는 큰 영향을 미치지 않음		- 신뢰성, 안정성을 높이기 위한 규칙 - SW 기능에 영향을 끼침
> 이름에 CamleCase를 사용 > Class 이름은 대문자로 시작 > 한 줄에 100글자를 넘기지 말 것		> 객체 사용 전 Null 체크 할 것 > 자원 할당 후 반드시 해제 > 예외는 반드시 명확하게 핸들링 할 것

 

Coding Rule 의 예시 

• Block은 2개의 Space를 사용하여 Indentation
• Column 제한은 100글자
• 모든 변수 선언은 변수 하나 식 선언
• 클래스 내부는 논리적 흐름에 따라 순서 배정 ( 시간 순서 X )
• 줄 바꿈 규칙
• 네이밍 규칙

 

Coding Rule의 준수 여부 확인

 - Coding Rule이 잘 지켜지고 있는지 확인하는 방법 

Code Review	Static Analysis
작성 된 Code를 작성자 외의 리뷰어가 읽어 다양한 피드백 제공이 가능하다.	SW를 정적 타임 또는 빌드 타임에 분석하는 기술이다
Code및 SW 산출물에 대한 리뷰는 품질 향상을 위한 강력한 활동이다.	Coding Rule 위반, 잠재 결함, 모듈간 의존성 등을 분석한다.
Coding Rule 뿐만 아니라, Best Practice, 더 나은 해결책 등의 논의가 가능하다.	언어 별, 무료/유료 정적 도구 존재한다.
Static Analysis와 같이 진행하면 더욱 효율적인 리뷰가 가능하다.	Free : IDE, CppCheck, CheckStyle, PMD .. Commercial : Coverity , Klockwork , QAC

 

 

 

---

- 코드프레소  Java  웹  개발  체험단  활동  중    
- 코드프레소  웹개발 트랙의 "SW 유지보수성 향상을 위한 Clean Code" 내용입니다.
- 코드프레소  URL: https://www.codepresso.kr/