클린 코드와 그 첫걸음 네이밍 #1

목차

• 나쁜 코드
• 클린 코드
• 의미 있는 이름 짓기
• Google Java Naming Guide

나쁜 코드

성능이 나쁜 코드  - 불필요한 연산이 들어가서 개선의 여지가 있는 코드

 

의미가 모호한 코드 - 이해하기 어려운 코드 네이밍과 그 내용이 다른 코드

 

중복된 코드 - 비슷한 내용인데 중복되는 코드들 버그를 낳는다.

 

나쁜 코드가 나쁜 이유

깨진 유리창 법칙 - 나쁜 코드는 유리창처럼 계속 나쁜 코드가 만들어지록 한다.

생산성 저하 - 나쁜 코드는 팀 생상선을 저하시킨다. 기술부채를 만들어 수정을 더 어렵게 한다.

새로운 시스템을 만들어야 한다. - 현시스템을 유지 보수하며 대체할 새로운 시스템 개발은 현실적으로 매우 어렵다.

나쁜 코드를 짜는 이유

일정이 촉박해서

일정 안에 새로운 기능을 완성해야 한다.

하지만 나쁘 코드는 생산성 저하하기 때문에 오히려 일정을 못 맞춘다..

 

영향 범위가 넓어서

생삭보다 영향범위가 넓어서 건드렸다가 다른 부분에 버그가 발생할까 봐

하지만 기술 부채는 부메랑처럼 우리에게 돌아온다.

---

클린 코드

나는 우아하고 효율적인 코드를 좋아한다.

논리가 간단해야 버그가 숨어들지 못한다.

의존성을 최대한 줄여야 유지보수가 쉬어진다

오류는 명백한 전략에 의거해 철저히 처리한다.

성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다.

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

 

깨끗한 코드는 단순하고 직접적이다

깨끗한 코드는 잘 쓴 문장처럼 읽힌다.

깨긋한 코드는 결코 설계자의 의도를 숨기지 않는다.

오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.

요약

• 성능이 좋은 코드
• 의미가 명백한 코드 = 가독성이 좋은 코드
• 중복이 제거된 코드

보이스카우트 룰

전보다 더 깨끗한 코드로 만든다.

---

의미가 분명한 이름 짓기

int a;
String b;

//..

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

// Console Output
// User Request book. count = 3

 

의미가 모호한 변수명을 구체적이고, 직관적인 이름으로 수정해야 한다.

=> 내가 아닌 다른 사람이 봐도 한 번에 알 수 있어야 한다.

 

int itemCount;
String itemName;

//..

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

// Console Output
// User Request book. count = 3

 

조금 더 나아가 연관된 변수들을 하나의 클래스로 묶어주어 의미를 더욱 명확하게 할 수 있다.

 

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

// ..

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

System.out.printf("User Request %s. count = %d", 
				selectedItem.getName(), selectedItem.getCount());
                
// Console Output
// User Request book. count = 3

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

배열을 순회할 때 index를 의미하는 i를 사용하지 않고, advanced for문으로 대체할 수 있다.

 

for (int i = 0; i < messages.size(); i++) {
	// ..
}


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

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

 

만약 인덱스 값이 사용되어야 한다면 i, j, k 대신 맥락에 맞는 이름으로 대체한다.

 

i, j => row, col  또는 width, height

i, j, k => row, col, depth

통일성 있는 단어 사용하기

Member / Customer / User

Service / Manager

Repository / Dao

 

네이밍 룰을 정하여 하나의 단어로 통일하자!

변수명에 타입 넣지 않기

String nameString 		=> name
int itemPriceAmount		=> itemPrice

Account[] accountArray 		=> accounts
List<Account> accountList 	=> accounts, accountList
Map<Account> accountMap

public interface IShapeFactory	=> ShapeFactory
public class ShapeFactoryImpl 	=> CircleFactory

 

List, Map 같은 경우는 변수명에 타입을 넣어서 써줘도 괜찮다. 특히 Map 같은 경우는 대체할 단어가 업기 때문에 변수명에 Map 붙여서 변수명을 보고 어떤 타입인지 유추할 수 있게 해 준다.

 

또한 ShapeFactoryImpl 같은 경우도 현업에서 아직까지 많이 사용하고 있는 패턴이다. 또한 구체적으로 인터페이스의 구현체를 구체적으로 써주는 것도 괜찮다. => 보통 팀의 네이밍 룰을 따라간다.

---

Google Java Naming Guide

Package Naming Guide

All lower case, no underscores

 

// Good!
com.example.deepspace

// Bad
com.example.deepSpace
com.example.deep_space

Class Naming Guide

UpperCamelCase (대문자로 시작)

 

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

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

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

Method Naming Guide

LowerCamelCase (소문자로 시작)

 

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

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