Naming 규칙
안좋은 코드
- 성능이 나쁜 코드
- 의미가 모호한 코드
- 중복된 코드
위 와 같은 안좋은 코드들이 유지가 될 수록 더 안좋은 코드가 만들어 지도록 합니다.
예를 들어 길거리에 쓰레기가 없다면 아무도 쓰레기를 버리지 않겠지만 쓰레기가 많은 길거리에는 쓰레기를 버리는 사람들이 생겨납니다.
저도 SI업체에서 일하면서 짧은 기한내에 기능을 완성시켜야 하는 업무 특성상 일정이 촉박하므로 나중에 바꿔야지 하면서 손이 가는데로 코딩했던 기억이 있습니다. 하지만 안좋은 코드들로 짜다보니 생산성 저하로 인해 더 일정에 못맞추게 되는 것을 느꼈습니다.
좋은 코드
- 성능이 좋은 코드
- 의미가 명확한 코드(가독성이 좋은 코드)
- 중복이 제거된 코드
Clean Code 책에서의 클린 코드는 위 와 같이 정의하고 있습니다.
비야네 스트롭스트룹(C++창시자)
"
나는 우아하고 효율적인 코드를 좋아한다.
논리가 간단해야 버그가 숨어들지 못한다.
의존성을 최대한 줄여야 유지보수가 쉬워진다.
오류는 명백한 전략에 의거해 철저히 처리한다.
성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다.
깨끗한 코드는 한 가지를 제대로 한다.
"비야네 스트롭스트룹은 위 와 같이 좋은 코드(깨끗한 코드)를 말했습니다.
여기서 마지막 문장인 깨끗한 코드는 한 가지를 제대로 한다. 이 부분이 제일 인상깊었습니다.
객체지향의 설계 5원칙 SOLID중
S(SRP) : 클래스는 하나의 책임만 다 해야하고, 메소드는 하나의 일만 해야한다.
의미가 분명한 이름 짓기
int a;
String b;
//...
System.out.printf("User Requested %s. count = %d", b, a);
위 와 같이 불분명한 변수명은 코드를 보는 개발자를 힘들게 합니다.
구체적인 이름으로 변경해봅시다.
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(purchaseRequest.getItemCode());
System.out.printf("User Requested %s. count = %d", selectedItem.getName(), selectedItem.getCount());통일성 있는 단어 사용
Member / Customer / User
Service / Manager
Repository / Dao
등 같은 의미로 사용되는 단어들을 통일 시켜야 합니다.
변수명 작성
변수명에 타입을 넣지 않는다.
String nameString -> String name
Collection Type은 예외됩니다.
List<Account> accountList or accounts
Map<Account> accountMap
클래스명 작성
UpperCamelCase 대문자로 시작
// 클래스는 명사, 명사구
Character, ImmutableList
// 인터페이스는 명사, 명사구, (형용사)
List, Readable
// 테스트 클래스는 Test로 끝나기
HashTest, HashIntegrationTest
메소드명 작성
LowerCamelCase 소문자로 시작
// 메서드는 동사, 동사구
sendMessage, stop
// JUnit테스트에서는 underscore 사용되기도 함
pop_emptyStack변수, 클래스, 메소드 이름을 짓는 기초적인 내용입니다.
실제 실무로 나가셨다면 많이 보셨을 패턴들입니다.
