[원티드][1주차] 누구나 읽기 쉬운 깨끗한 코드 작성법 1

클린코드가 필요한 이유

우리는 혼자 일하지 않고 동료와 함께 일한다. 우리는 코드를 읽는 독자일 경우가 많다.

편하게 이해하고 빠르게 고칠 수 있도록 하기 위해 클린코드가 필요하다.

 

 

## 의미있는 이름

1. 의도를 분명히 밝혀라.

- 이름으로 의도가 올바르게 파악돼야 한다.

- 변수의 이름이 길어지면 어떡하나?

  => 이름이 길어도 직관적인게 좋다고 생각한다.

       변수 아무리 귀찮고 힘들어도 의미가 정확하지 않으면 명확하게 수정해줬으면 좋겠다.

       - 회사마다 용어사전이 있고 메타데이터가 있다.

         => 이러한 문화가 있다면 따르고, 이것보다는 되도록 명확한 이름이 있으면 좋겠다.

2. 그릇된 정보를 피하라.

- 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하지 말자.

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

3. 의미 있게 구분하라.

4. 발음하기 쉬운 이름으로 정하자.

5. 검색하기 쉬운 이름을 사용하라.

- 개발을 하다가 오류가 발생하면 로그에서 검색하는 경우가 많다.

6. 타입과 관련된 문자열을 넣지 말아라.

- 타입이 변할 수 있기 때문이다.

7. 한 개념에 한 단어를 사용하라.

8. 의미 있는 맥락을 추가하라.

9. 불필요한 맥락을 없애라.

 

 

 

## Function : 한 가지만 하자.

1. 작게 만들어라. (SRP)

- 한 가지만 해라.

- 함수 내부가 자연스럽게 쪼갤 수 있다면 여러 작업을 하고 있다는 의미이다.

- 추상화 수준이 한 단계씩 낮아져야 한다.. => 이게 무슨 말이지?

  => 반복해서 사용하지 않아도 함수로 만드는 것이 좋다.

 

```

if (!Optional.ofNullable(service.getTest().execute().body()).isPresent())

```

 

 

 

2. Switch문

- 왠만하면 쓰지 말아라.

- 문제점 

 1) 함수가 길다.

 2) 한 가지 일만 하지 않는다.

 3) SRP를 위반한다.

 4) OCP를 위반한다.

- 해결방법

1) Switch를 쓸 때는 Controller, Service단이 아니라 꽁꽁숨겨서 사람들이 못보게 한다.

  => 핸들러를 만들어 사용한다.

 

3. 함수의 인수 종류와 개수

- 최대한 없는 것이 좋다. => 1~2개가 적당하다.

- 인수는 input 관련 (requestbody, requestparam, 고객입력값) 값을 넣어준다.

 

4. 명령과 조회를 구분해라.

 

5. 오류코드보다 예외를 사용하라! ( if else로 오류처리 하지말아라!! )

- Try-Catch 문으로 예외처리를 하는 것이 좀 더 현명하다.

- Try-Catch VS throws ?

--- try-catch는 왠만하면 Controller에서 사용

--- throws는 왠만하면 Service에서 사용

--- 비즈니스 로직은 Service의 함수들이 합쳐져서 실행된 결과들을 가지고 작업을 수행한다. 때문에 한 곳에 모으자.

     => 이건 답이 없다.

 

 

## 리팩토링

- 멤버객체를 private으로 선언했으나 getter로 접근한다. => 은닉화 위반.

- 내부 구현이 노출되고 있다.

- getter, setter는 인스턴스를 호출하는 것이다.

- public으로 행위를 하도록 하는 것이 좋다.

 

캡슐화

- 외부에 노출시킬 수 있는 인터페이스를 만들고 (비즈니스 로직)

- 내부 구현은 인스턴스 변수들이 동작하는 것. => 외부에 노출되어 직접적으로 이 기능을 사용하게하면 안된다.

  -- 마음대로 사용할 수 없고, 변경할 것들이 많아진다.

- public은 생성자와 행위

 

- 내부의 구현 : 인스턴스 변수를 숨기고 직접적으로 다뤄지는 것들은 private. 비즈니스 로직(다른 클래스의 객체가 요청했을 때 응답해야하는 경우, getter와 setter가 명백하게 필요한 경우에 사용.)

---> getter, setter를 써도 되는 경우는 DTO