♻️[클린코드] #1 깨끗한 코드와 의미 있는 이름

 

 

---

♻️ 나쁜 코드

 - 나쁜코드가 무엇일까?

1. 성능이 나쁜 코드 : 불필요한 연산이 존재한다.

2. 의미가 모호한 코드 : 이해하기 어려우며, 네이밍과 그 내용이 일치하지 않는다.

3. 중복된 코드 : 비슷한 내용인데 중복된 코드들은 버그를 낳으며 불필요하게 공간을 차지한다.

 

 - 나쁜 코드가 나쁜 이유 

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

생산성 저하 : 나쁜코드가 쌓일수록 기술 부채가 쌓인다. 팀 생산성을 저하시킨다. 기술부채를 만들어 기존 코드 수정을 더 어렵게 한다.

* 기술부채 : 

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

생산성 저하 : 나쁜 코드가 쌓일 수록 기술 부채가 쌓인다.

 

 - 나쁜 코드를 짜는 이유 

일정이 촉박해서 : 일정 안에 새로운 기능을 완성해야하기때문에 구현에만 집중해서 나쁜 코드를 짜게 된다. 하지만 결국 생산성을 저하하기 때문에 오히려 일정을 못맞추게된다.

영향 범위가 넓어서 : 생각보다 영향 범위가 넓어 건드렸다가 다른 부분에 버그가 발생할까봐 두려워서 나쁜 코드를 짜게 된다. 하지만 기술부채는 부메랑처럼 우리에게 돌아온다.

---

♻️ 클린 코드

 - 비아네 스트롭스트룹 (C++창시자) 

우아하고 효율적인 코드
논리가 간단 (버그가 숨어들지 못하는 코드)
의존성을 최대한 줄인 코드 (유지보수 쉬워짐)
오류는 명백한 전략에 의거해 철저히 처리
성능을 최적으로 유지 (사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않음)
깨끗한 코드는 한 가지를 제대로 한다. 

* SRP : 단일 책임 원칙

 

 -그래디 부치 (객체지향 대가 ) 

깨끗한 코드는 단순하고 직접적이다.
깨끗한 코드는 잘 쓴 문장처럼 읽힌다.
깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다.
오히려 명쾌한 추상화와 단순한 제어문으로 갇그하다.

 - 클린 코드

1. 성능이 좋은 코드

2. 의미가 명확한 코드 = 가독성이 좋은 코드

3. 중복이 제거된 코드

 

보이스카우트 룰 : 건들기 전보다 더 깨끗한 코드로 만든다

---

♻️ 의미 있는 이름 짓기

 - 의미가 분명한 이름 짓기 

변수 네이밍 (ex. int a;는 변수명만 봤을 때 기능을 알 수 없음)

구체적인 이름을 넣어서 변수를 네이밍한다. (ex. int itemCount;)

 

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

배열 순회 : index가 굳이 필요하지 않다면 값에 접근할 때 index를 의미하는 i를 사용하지 않고 대체가능.

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

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

 

i, j, k 대신 맥락에 맞는 명확한 이름을 사용 -> row, col, depth 또는 width, height

i, j, k -> row, column, depth

 

 - 통일성 있는 단어 사용하기 

중복된 의미라면 팀원들끼리나 혹은 자신이 통일된 하나의 단어를 사용하기로 한다.

ex) Member/Customer/User 3가지 단어는 비슷하므로 3가지 중 하나로 통일한다.

 

 - 변수명에 타입 넣지 않기 

String nameString -> String name

Int itemPriceAmount -> int itemPrice

    -> Amount 의미가 이미 내포되어있으므로 빼준다.

 

Account[] accountArray -> Account[] accounts

List<Account> accountList, Map<Account> accountMap

    -> List나 Map같은 경우는 변수명에 타입을 넣어 사용하기도 한다.

 

public interface IShapeFactory -> public interface ShapeFactory

    -> interface 앞에 I를 붙이기도 하지만 붙이지 않는 것을 권장한다.

public class ShapeFactoryImpl -> public class CircleFactory 

    -> Impl을 써도 되지만, 구현체의 이름을 명확하게 쓰기도 한다.

 

* 네이밍은 다른 사람들과 함께 이해하기 위해 지키는 규칙이므로, 팀원들과 함께 상의해서 정하고 지키는 것을 추천한다.

 

---

♻️ Google Java Naming Guide

현업에서 많이 참고하는 가이드. 구글에서 제한하는 네이밍 가이드.

 

 - Package Naming Guide 

모두 소문자로 하고(카멜케이스X) 언더스코어(_)를 사용하지 않는다.

ex) com.example.deepspace

 

 - Class Naming Guide 

UpperCamelCase (대문자로 시작하는 카멜케이스)

 

1. 클래스는 명사, 명사구로 네이밍 가능

    ex) Character, ImutableList

2. 인터페이스는 명사, 명사구, 형용사로 네이밍 가능

    ex) List, Readable

3. 테스트 클래스는 Test로 끝나기

    ex) HashTest, HashIntegrationTest

 

 - Method Naming Guide 

LowerCamelCase (소문자로 시작하는 카멜케이스)

 

1. 메서드는 동사, 동사구로 네이밍 가능. 반드시 동사로 시작한다.

    ex) sendMessage, stop

2. jUnit 테스트에 underscore 사용하기도 함 :(methodUnderTest)_(state) 패턴 (테스트 대상이 되는 메서드)_(상태) 패턴

    ex) pop_emptyStack

---