클린코드 - 클린 코드란?,네이밍 가이드

• 나쁜 코드
• 클린 코드
• 의미 있는 이름 짓기
• 네이밍 가이드

---

나쁜 코드

나쁜 코드는 너무 많은 일을 하려 애쓰다가 의도가 뒤섞이고 목적이 흐려진다

• 성능이 나쁜 코드 : 불필요한 연산이 들어가서 개선의 여지가 있는 코드
• 의미가 모호한 코드 : 이해하기 어려운 코드, 네이밍과 그 내용이 다른 코드
• 중복된 코드 : 비슷한 내용인데 중복되는 코드들은 버그를 낳는다

 

나쁜 코드가 나쁜 이유

• 깨진 유리창 법칙 : 나쁜 코드는 깨진 유리창처럼 계속 나쁜 코드가 만들어지도록 한다
• 생산성 저하 : 나쁜 코드는 팀 생산성을 저하시킨다
• 새로운 시스템을 만들어야 한다 : 현시스템을 유지보수하며 대체할 새로운 시스템 개발은 현실적으로 어렵다

 

나쁜 코드를 짜는 이유

• 일정이 촉박해서 : 하지만,나쁜 코드는 생산성을 저하하기 때문에 오히려 일정을 못맞춘다
• 영향 범위가 넓어서 : 영향범위가 넓어서 다른 부분에 버그가 발생할까봐, 하지만 기술부채는 부메랑처럼 돌아온다

 

---

 

클린 코드

깨끗한 코드는 한 가지를 제대로 한다

 

각 함수와 클래스와 모듈은 한길만 걷는다
클린 코드는 다른 사람이 고치기 쉽다
읽기 쉬운 코드와 고치기 쉬운 코드는 엄연히 다르다

 

클린 코드란

• 성능이 좋은 코드
• 의미가 명확한 코드 = 가독성이 좋은 코드
• 중복이 제거된 코드 : 재활용할 수 있도록 설계하는 것이 중요하다. 비슷한 코드가 난발해있는 것이 아니라 중복이 제거돼서 명료한 코드

- 논리가 간단해야 버그가 숨어들지 못한다
- 의존성을 최대한 줄여야 유지보수가 쉬워진다
- 오류는 명백한 전략에 의거해 철저히 처리한다
- 성능을 최적으로 유지해야 코드를 망치려는 유혹에 빠지지 않는다
- 깨끗한 코드는 한 가지를 제대로 한다
-깨끗한 코드는 단순하고 직접적이다
- 깨끗한 코드는 잘 쓴 문장처럼 읽힌다
- 깨끗한 코드는 설계자의 의도를 숨기지 않는다. 명쾌한 추상화와 단순한 제어문으로 가득하다

 

중복 신경쓰기

1. 여러 기능을 수행하는 객체나 메서드를 찾는다
2. 객체가 여러 기능을 수행한다면 여러 객체로 나눈다
3. 메서드가 여러 기능을 수행한다면 메서드 추출 리팩터링 기법을 적용해, 기능을 명확히 기술하는 메서드 하나와 기능을 실제로 수행하는 메서드 여러 개로 나눈다

중복과 표현력만 신경 써도 깨끗한 코드에 성큼 다가선다

 

초반부터 간단한 추상화 고려하기

프로그램을 짜다 보면 어떤 집합에서 특정 항목을 찾아낼 필요가 자주 생긴다. 이때 추상 메서드나 추상 클래스를 만들어 실제 구현을 감싼다

이렇게 하면 여러 가지 장점이 생긴다

1. 실제 기능은 아주 간단한 방식으로, 예를 들어 해시맵으로 구현해도 괜찮다
2. 다른 코드는 추상 클래스나 추상 메서드가 제공하는 기능을 사용하므로 실제 구현은 언제든지 바꿔도 괜찮다. 간단하게 재빨리 구현했다가 나중에 필요할 때 바꾸면 된다
3. 집합을 추상화하면 '진짜'문제에 신경 쓸 여유가 생긴다

 

그릇된 정보는 피하기

코드에 그릇된 단서를 남기면 안된다, 그릇된 코드는 코드 의미를 흐린다.

 

1. 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해서는 안된다
2. 서로 흡사한 이름 사용에 유의한다
3. 일관성이 떨어지는 표기법은 그릇된 정보다

그릇된 정보를 제공하는 이름 예시

소문자 L이나, 대문자 O 변수가 그 예시이다. 소문자 L은 숫자 1처럼 보이고 대문자 O는 숫자 0처럼 보인다.

int a = l;
if ( O == l)
a = 01;
else
l = 01;

 

의미있게 구분하기

이름이 달라야 한다면 의미도 달라져야 한다

 

연속된 숫자를 덧붙이거나 불용어(noise word)를 추가하는 방식은 적절하지 못하다.

 

예를 들면, Product라는 클래스가 있다고 가정하자. 다른 클래스를 ProductInfo 혹은 ProductData라고 부른다면 개념을 구분하지 않은 채 이름만 다르게 한 경우다. Info나 Data는 a,an,the처럼 의미가 불분명한 불용어다 물론 의미가 분명히 다르다면 사용해도 무방하다.

 

"읽는 사람이 차이를 알도록 이름을 지어야 한다"

 

의미 있는 맥락 추가하기

맥락을 개선하면 함수를 쪼개기가 쉬워지고, 알고리즘도 좀 더 명확해진다

 

클래스,함수,이름 공간에 맥락을 부여한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.

 

예를 들어, firstName,lastName,street,city,state라는 변수가 있다. 변수를 훑어보면 주소에 관한 것이라는 것을 알 수 있다.

하지만, 어느 메서드가 state라는 변수 하나만 사용한다면, 변수 state가 주소의 일부라는 것을 알기 어렵다.

addr라는 접두어를 추가해 addrfirstName,addrLastName,addrState라고 쓰면 맥락이 좀 더 분명해진다.

여기서 Address라는 클래스를 생성하면 더 좋다. 그러면 변수가 좀 더 큰 개념에 속한다는 것이 컴파일러에게도 분명해진다. 

 

불필요한 맥락 없애기

짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서

 

예를 들어, Introduction to famous meat restaurants라는 앱을 만든다고 했을 때 모든 클래스 이름을 ITFMR으로 시작하겠다는 생각은 바람직하지 않다. IDE에서 I를 입력하면 IDE는 모든 클래스를 열거한다. 매우 좋지 않다

 

accountAddress와 customerAddress는 Address 클래스 인스턴스로는 좋은 이름이나 클래스 이름으로는 적합하지 않다.

Address는 클래스 이름으로 적합하다.

 

 

 

---

 

의미 있는 이름  짓기

 

의미가 분명한 이름 짓기

좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다

 

의도가 분명한 이름은 정말 중요하다

이름은 다음의 질문에 모두 답해야 한다 - 존재 이유는? 수행 기능은?  사용방법은?

코드 맥락이 코드 자체에 명시적으로 드러나야 한다

 

• 구체적인 내용을 넣어서 변수명을 지어줘야 한다
• 클래스를 사용해서 의미를 명확하게 묶어줄 수 있다
• 루프 속 i, j, k 사용하지 않기(최소화)
• 통일성 있는 단어 사용하기
• 변수명에 타입 넣지 않기
• 발음하기 쉬운 이름 사용하기
• 검색하기 쉬운 이름 사용하기
• 한 개념에 한 단어 사용하기

 

의미가 분명하지 않은 이름

int a;
String b;

System.out.printf("User Requested %s. count = %d", b, a);

이름 a,b는 아무 의미도 드러나지 않는다

 

의미가 분명한 이름

int itemCount;
String itemName;

System.out.printf("User Requested %s. count = %d", itemName, itemCount);

 

클래스를 사용해서 이름의 의미를 명확하게 묶어준 코드

class SalesItem {
    ItemCode code;
    String name;
    int count;
}

SalesItem selectedItem = salesItemRepository.getItemByCode(PurchasRequest.getItemCode());

System.out.printf("User Requested %s. count = %d", selectedItem.getName(), selectedItem.getCount());

 

루프 속 i ,   j,  k 사용하지 않기

i, j, k대신 맥락에 맞는 이름이 있다, 명확하게 의미를 찾아서 쓰는 게 좋다

 

인덱스 값이 필요하지 않다면 advanced for문이나 lamda를 사용해서 처리할 수 있다

배열의 하나하나의 값들이 중요하지 순서의 중요도가 없다면 값 자체에 접근하기 때문에 i의 사용빈도는 낮다

 

i 가 아닌  advanced for 문  사용

for (String message : messages) {
  // ..
}

 

i 가 아닌 lamda사용

messages.stream().forEach(
  message -> //..
)

 

통일성 있는 단어 사용하기

똑같은 의미에 대해서는 똑같은 단어를 사용하는 게 중요

 

유저를 Member / Customer / User 이렇게 각기 다르게 표현하면 안되며 하나로 정하는 게 좋다

서로 흡사한 이름을 사용하지 않도록 주의한다

 

변수명에 타입 넣지 않기

List,Map같은 경우에는 끝에 List다,Map이다 라고 써둬서 네이밍만 보고도 타입을 유추할 수 있게 많이 쓰는 편이다

String nameString (👎) -> name
//Price,Amount가 중복된 내용
Int itemPriceAmount (👎) -> itemPrice

Account[] accountArray (👎) -> accounts
List<Account> accountList (👌) -> accounts,accountList
Map<Account> accountMap (👌)

//요즘은 interface의 약자 I를 붙이지 않는다
public interface IShapeFactory (👎) -> ShapeFactory
//ShapeFactory의 구현체가 circle이라면 CircleFactory라고 명확하게 이름을 지어주는 것이 좋다
public class ShapeFactoryImpl (🔺) -> CircleFactory

 

발음하기 쉬운 이름 사용하기

발음하기 쉬운 이름은 중요하다 프로그래밍은 사회 활동이기 때문에

 

검색하기 쉬운 이름 사용하기

이름을 의미있게 지으면 함수가 길어진다. 하지만 찾기가 매우 쉬워진다

 

문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다.

예를 들어 e라는 문자는 변수 이름으로 적합하지 못하다 e는 영어에서 자주 쓰이기 때문에 e가 들어가는 파일 이름이나 메서드,클래스등이 모두 검색된다. 검색이 되었지만 의도가 다른 경우도 있으며, 버그가 있을 때 수정하기도 어렵다 즉, 검색이 어렵다는 거다.

 

이런 관점에서 긴 이름이 짧은 이름보다 좋다. 검색하기 쉬운 이름이 상수보다 좋다

 

 

한 개념에 한 단어 사용하기

독자적이고 일관적이여야 하며, 똑같은 것을 제각각 다르게 부르면 안된다

 

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다. 예를 들어, 똑같은 메서드를 클래스마다 제각기 다르게(fetch,retrieve,get) 부르면 혼란스럽다. 메서드 이름은 독자적이고 일관적이어야 한다. 그래야 주석을 뒤져보지 않고 올바른 메서드를 선택한다

이름이 다르면 당연히 클래스도 다르고 타입도 다르다고 생각한다

 

한 단어를 두 가지 목적으로 사용하면 안된다, 같은 맥락이 아닌데도 '일관성'을 고려해 단어를 선택한다면 안된다 예를 들면, 여러 클래스에 add메서드가 있고 모두가 기존 값 두개를 더하는 기능이다. 새로 작성하는 메서드는 집합에 값 하나를 추가한다. 이 메서드를 add메서드라고 부르면 맥락이 다르기 때문에 안된다. insert나 append라는 이름이 적당하다

 

집중적인 탐구가 필요한 코드가 아닌, 대충 봐도 이해할 코드 작성이 목표다

 

 

---

 

네이밍 가이드

 

Package Naming Guide

All lower case, no underscores

com.example.deepspace (👍)
com.example.deepSpace (👎)
com.example.deep_space (👎)

 

Class Naming Guide

UpperCamelCase(대문자로 시작)

//클래스는 명사,명사구
Character,ImmutableList

//인터페이스는 명사,명사구(형용사)
List,Readable

//테스트 클래스는 Test로 끝나기
HashTest, HashIntegrationTest

 

Method Naming Guide

LowerCamelCase(소문자로 시작)

//메서드는 동사,동사구
sendMessage,stop

//jUnit테스트에 underscore사용되기도 함
//<methodUnderTest>_<state>패턴
pop_emptyStack