[SW 유지보수성 향상을 위한 Clean Code] Clean Naming (1)

✨ 이 글은 [ 코드프레소 Java 웹 개발 체험단 활동 ] 내용입니다 ✨

💜 코드프레소 이러닝 강의 수강 중 - SW 유지보수성 향상을 위한 Clean Code 💜

😎 아래의 링크를 통해 프리미엄 IT 교육 서비스, 코드프레소를 확인해보세요 😎

https://www.codepresso.kr/

프리미엄 IT 교육 서비스 - 코드프레소

---

왜 Clean Name이 중요할까?

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

 

 

Naming은 쉽지 않다!

• 위는 Quora의 Ubuntu Forum의 설문 결과이다
• 프로그래머의 가장 어려운 Track을 Naming으로 꼽았다

 

 

Clean Naming은 가독성 향상에 가장 중요한 요소이다

• 개발의 대부분은 코드를 이해하고 수정하는 행위이다
• 수십, 수백만 라인의 코드를 읽고 이해하고 수정하는 것은 매우 어려운 일이다
• Clean Naming에 대한 작은 투자는 장기적으로는 팀의 개발 생산성 향상에 크게 기여한다!

 

 

SW의 주요 요소들은 모두 Clean Name이 필요하다

 

 

 

Clean Name이란?

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

 

---

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

 

 

 

Clean Naming 원칙

1. Function, Class 역할이 명확하면 Naming도 명확해진다
2. 불필요한 정보/반복은 제거해야 한다
3. 줄임말(약어)를 사용하지 않는다
4. 규칙과 일관성은 중요하다
5. 동료와 상의해라

 

 

1. Function, Class 역할이 명확하면 Naming도 명확해진다

• Clean Function, Class의 제 1원칙은 명확히 한 가지 역할을 하는 것이다
• 역할이 많으면 이름도 명확하지 않게 된다
  • createAndSaveUserInfo(), validateDataAndSendEmailAndSMS() ...
  • User -> 판매자, 사용자, 구매자, 관리자 등 가능성이 너무 많다
  • GeneralUtil
• 명확한 이름을 짓기 어려울 때는 너무 많은 역할을 하고 있는게 아닌지 고민해야 한다!

 

 

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

• 이름은 이해 가능한 최소한의 정보를 담고 있어야 한다 -> 너무 짧지도, 너무 장황하지도 않아야 한다
• 불필요한 정보 -> UserData, processFunc()

 

 

3. 줄임말(약어)를 사용하지 않아야 한다

• 줄임말은 가독성을 심각하게 저하시킨다
• 누구나 이해할 수 있는 줄임말은 존재하지 않는다
• 나에게 당연한 줄임말도 타인에게는 당연하지 않을수도 있다는 것을 인지해야 한다!
• 줄임말의 예
  • temp, prdt, usr -> temperature, product, user
  • acc(), inc(), procDidCom) -> accelerateSpeed(), increasePrice(), processDirectoryCommand()

 

 

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

• 언어 별, 조직 별 Naming Convention을 일관성있게 지켜야 하낟
• 일관성은 코드를 이해하고 수정하는 노력을 감소시키낟
• 일관성 없는 Naming은 가독성을 저하시킨다
• 언어 별 Naming Standard, Naming Convention이 존재한다
  • Java의 경우 Oracle,
  • Java : 카멜 케이스 -> getUser( )
  • Python, C++ : 스네이크 케이스 -> get_user( )
• 공식 Guide를 조직에 맞게 커스터마이징하여 내부 Guide를 결정해야 한다
  
  • 결정된 Guide를 잘 지키고, 이견이 있을 시 공론화가 필요하다
• 코드 리뷰 시 Naming 등이 Guid를 잘 지키고 있는지 반드시 확인해야 한다

 

 

5. 동료와 상의하라

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

---

Clean Variable Naming

 

 

Clean Variable Naming Example

 

 

 

Clean Variable Naming - With More Information

• 위의 변수 이름도 좋지만, 보다 명확하게 하기 위해 추가적인 정보를 이름에 기입한다

 

 

Clean Variable Naming - Bad Smell

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

 

 

Clean Variable Naming - Bad Smell Example

 

---

Clean Method Name

• Method의 이름은 의도와 기능을 명확하게 표현해야 한다
• 만약 Method의 의도와 기능을 이해하기 위해 내부 코드를 들여봐야 한다면, 그 Method의 이름은 개선해야 될 필요가 있다
• Method의 이름은 어떤 동작(동사)을, 무엇을 대상(명사)으로 할 것인지를 표현한다

 

 

Clean Method

• 좋은 Method는 작고, 한 가지 일만 수행한다
• 작고, 한 가지 일만 수행하는 Clean Method는 Clean Name을 짓기가 쉽다
• Method 이름을 정하기가 어렵다면, Method가 Clean 한 지를 먼저 고민해야 된다

 

 

Clean Method Name

 

 

 

Clean Method Name - Example

 

 

 

Clean Method Name - With More Information

• 위의 변수 이름도 좋지만, 보다 명확하게 하기 위해 추가적인 정보를 이름에 기입한다

 

 

Clean Method Name - Bad Smell

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

 

 

 

Clean Method Name - Bad Smell Example

 

---

Clean Class Name

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

 

 

Clean Class Naming Principle

1. 구체적이고 명확한 이름을 사용하라
2. Convention을 준수하는 일관성 있는 이름을 사용하라
3. 보편 언어를 활용하라

 

 

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

 

 

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

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

 

 

3. 보편 언어를 활용하라

• 도메인 주도 설계의 보편 언어(Ubiquitous Language)
• SW는 복잡한 현실의 문제를 해결하기 위함
  • 은행, 증권, 제조, 물류, 자동차 ...
• SW는 요구사항 도출 -> 분석 -> 설계 -> 구현 -> 테스트 의 반복적인 사이클이다
  • 요구사항 단계에서의 도메인 전문가의 멘탈 모델과 이를 구현하는 엔지니어의 멘탈 모델 사이의 커다란 Gap이 존재한다
  • 이게 바로 유지보수성 낮은 SW가 만들어지는 원인이다
• 엔지니어는 복잡한 현실의 문제(도메인)을 잘 파악한 후 설계와 코드에 반영해야 한다
  • 은행 시스템의 엔지니어는 예금, 대출 등의 은행 업무를 깊게 이해해야 한다
  • 제조 시스템의 엔지니어는 제조 용어, 제조 프로세스 등을 깊게 이해애햐 한다
• 현실은 그렇지 못하다
  • 도메인 전문가와 엔지니어의 업무가 분리되어 있다
  • 커뮤니케이션이 원할하지 못해 서로의 언어 및 모델이 다르다
• 도메인 전문가, SW 아키텍트, 개발자의 언어를 모두 통일해야 한다
• 기준은 도메인 전문가들(사업팀의 사람들)이 사용하는 언어가 된다
• 이 언어는 모든 커뮤니케이션, 설계문서, 실제 코드까지 통일되어야 한다
• 클래스 이름을 도메인 전문가들이 보고 이해할 수 있도록 정해야 한다

---

너무 길어서 다음 내용은 다음 글에!