Clean code #01~02 코드에 관하여

  zero-base의 '한달한권 | 클린코드' 강의를 수강하면서 요약한 내용

나쁜 코드

나쁜 코드가 되기 위한 3가지 기준

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

나쁜 코드는 왜 나쁠까?

 

1. 깨진 유리창의 법칙

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

(깨진 유리창의 법칙 : 깨진 유리창 하나를 방치해 두면, 그 지점을 중심으로 범죄가 확산되기 시작한다는 이론)

 

2. 생산성 저하

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

 

3. 추가 비용이 발생한다.

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

 

그렇다면 나쁜 코드를 짜지 않으면 되지 않을까? 나쁜 코드는 왜 만들어질까?

 

1. 일정이 촉박해서

    일정 안에 새로운 기능을 완성해야 해서 일단 구현하고 넘어가는 식으로 반복이 되다 보면

    결국엔 나쁜 코드가 될 가능성이 높다 하지만 나쁜 코드는 생산성을 저하하기 때문에 오히려

    일정을 맞추기가 더 어려워진다.

 

2. 영향 범위가 넓어서

    생각보다 영향 범위가 넓어서 건드렸다가 다른 부분에 버그가 발생할 것 같은 두려움 때문에

    개선하지 못하고 넘어가는 경우가 있다. 하지만 기술 부채는 부메랑처럼 우리에게 돌아온다.

 

그래서  Clean code?

 

클린 코드

  깨끗한 코드는 단순하고 직접적이다.
깨끗한 코드는 잘 쓴 문장처럼 읽힌다.
깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다.
오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.
그래디 부치(객체지향 대가)

 

 

클린 코드가 되기 위한 3가지 기준

• 성능이 좋은 코드
• 의미가 명확한 코드 (가독성이 좋은 코드)
• 중복이 제거된 코드

클린 코드 작성을 위한 방법들

 

1. 의미가 분명한 이름 짓기

//남들이 알아 볼 수 없는 의미가 불분명한 이름 짓기

int a; 
String b;​
class ab{
  ItemCode code;
  String name;
  int count;
}

//의미가 분명하게 이름을 지어준다.

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

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

//i를 사용한 루프
for (int i = 0; i < messages.size(); i++){
//..
}

//혹은

//의미를 가진 이름을 사용한 루프
for (String message: messages){
//..
}

//i,j,k대신 맥락에 맞는 이름을 사용 ex) i,j,k -> row,col,depth / width,height,weight 등

//lambda를 사용
messages.stream().forEach(message -> //.. )

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

3. 통일성 있는 단어 사용하기

    Memeber / Cusomer / User

    Service / Manager

    Repository / Dao

 

4. 변수명에 타입 넣지 않기

String nameString(bad) -> name// 타입이 있기 때문에 굳이 변수명에 String을 넣을 필요 없음
Int itemPriceAmount(bad) -> itemPrice //Price와 Amount 중복

Account[] accountArray(bad) -> accounts /
List<Account> accountList(okay) -> accounts, accountList // 리스트와 맵 같은 경우
Map<Account> accountMap(okay) // 대체를 해줄 말이 없기 때문에 타입 유추 가능한 이름은 좋음

public interface IshapeFactory(bad) -> ShapeFactory //과거에 interface 객체에 I를 붙임
public class ShapeFactoryImpl(상황에 따라 다름) -> CircleFactory //Impl

5. Google JAva Naming Guide (https://google.github.io/styleguide/javaguide.html#s5-naming)

• Package Naming Guide : All lower case, no underscores
• Class Naming Guide: UpeerCamelCase(대문자로 시작) e.g, HashText, List, Character
• Method Naming Guide: LowerCamelCase(소문자로 시작) e.g, sendMessage