Clean Code
: 어떤 코드가 좋은 코드 일까?
- 코드의 품질은 매우 주관적인 주제이다
- 개인마다 좋은 코드에 대한 서로 다른 정의와 수준을 가지고 있음
- 코드 품질, SW 품질에 대한 서로 다른 시각은 품질 향상의 걸림돌이다.'
- Claen Code는 개인과 조직의 노력이 동시에 필요로 한다.
Naming | 개발 속도를 위해 약어를 써야 해 Manager와 같은 접미사를 사용해야 해 |
약어는 절대 사용하지말고, 반복적이고 불필요한 단어는 제거해야해 |
Comment | 최대한 상세히 주석을 달아야 해 코드 수정 이력 등도 주석에 적어야 해 |
주석은 Bad Smell 이야 최소로 해야 하고 코드로 표현해야 해 |
Method, Class 크긱 |
너무 작고 많으면 유지보수가 힘들어 | 크기는 가능한 작고 역할을 명확해야 해 |
중복 코드 | 기존 코드를 빠르게 복사해서 개발 속도를 향상하자 | 중복 코드는 무조건 제거되야 해 |
테스트 코드 | 테스트 코드는 코드 기능에 영향을 미치지 않고, 공수가 너무 많이 드는 작업이야 | 중장기적인 유지보수성 향상을 위해서 테스트 코드는 필수적이야 |
- 클린 코드의 목적과 중요성을 이해해야 한다
- 클린 코드의 기준과 방향성을 조직에서 합의해야 한다.
- 클린코드를 위해 지속적으로 개선해야 한다.
- 클린코드란 "이해하기 쉽고, 변경하기 쉬운 Code"를 의미한다.
- 클린코드에 대한 엄격한 정의는 없다.
Clean Code
클린 코드에 대한 정의는 없지만, 중복되게 나오는 정의를 살펴보면 아래와 같다.
- 이해하기 쉽고, 변경하기 쉬운 CODE
- 사람이 읽고 이해하기 쉽고, 명확한 한가지 역할을 하며, 이 역할을 의미 있게 표현하고, 중복이 없고 테스트 케이스가 존재하는 CODE
이를 위해서 앞으로 다룰 Clean Code의 주제는 다음과 같다.
중요하지만 Clean Code의 범위에는 속하지 않는 것
- 자료구조 & 알고리즘
- SW성능 개선
- 신뢰성 , 안정성을 위한 개발 기법
- SW 아키텍처 설계 기법
- 언어 별 programming best practice
Clean Code의 중요성
- SW는 한번 신규 개발되고, 오랜 시간 동안 유지보수 된다.
- 기존 코드에 추가 작업하는 시간이 압도적으로 많은 업무 비중을 차지함.
- 대부분의 시간을 기존 코드를 읽고, 이해하는데 사용된다.
- Code의 품질이 낮으면, 코드의 이해력과 복잡도가 낮아져 수정이 어려워짐
- 테스트 코드가 없어서, 하나를 수정하면 여러 곳에서 Side-effect가 발생한다
- 개인과 조직 모두에게 커다란 비용 Risk가 발생한다.
Clean Naming
Clean Nameing의 중요성
- 좋은 이름을 통해 내부를 보지 않아도 동작과 목적을 쉽게 이해할 수 있다.
- 좋은 이름을 사용하면 코드를 읽는 사람도 인지적 부하를 최소하 할 수 있다.
- 따라서 clean naming은 장기적으로 개발 생산성 향상을 가능하게 함
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
각 변수의 타입마다 변수의 이름을 작명하는 것을 의미한다.
△ 변수 작명의 옳은 예시
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/
'EXTERNAL ACTIVITY > Code Presso -웹개발 트랙 체험단-' 카테고리의 다른 글
. (0) | 2022.01.23 |
---|---|
<코드 프레소 웹개발 트랙> SW 유지보수성 향상을 위한 Clean Code [2] (0) | 2022.01.22 |
<코드 프레소 웹개발 트랙> Java 프로그래밍 초급 [3] (0) | 2022.01.19 |
- (0) | 2022.01.19 |
<코드 프레소 웹개발 트랙> Java 프로그래밍 초급 [2] (0) | 2022.01.18 |