클린코드 리팩토링 차이 - keullinkodeu lipaegtoling chai

Question

TDD, 리팩토링, 클린코드 (1주차 수업)

학습목표

- TDD, 리팩토링, 클린코드

- 순수 자바, 웹 기반으로 객체지향 프로그래밍

- ATDD 기반 웹 애플리케이션 개발

의식적인 연습

- 목적의식 있는 연습에 얼마나 많은 시간을 투자했느냐? (아마추어와 프로의 결정적 차이)

의식적인 연습의 7가지 원칙

1. 효과적인 훈련 기법이 수립되어 있는 기술 연마

2. 개인의 컴포트 존을 벗어난 지점에서 진행, 자신의 현재 능력을 살짝 넘어가는 작업을 지속적으로 시도

3. 명확하고 구체적인 목표를 가지고 진행

4. 신중하고 계획적. 즉 개인이 온전히 집중하고 '의식적'으로 행동할 것을 요구

5. 피드백과 피드백에 따른 행동 변경을 수반

6. 효과적인 심적 표상을 만들어내는 한편 심적 표상에 의존

7. 기존에 습득한 기술의 특정 부분을 집중적으로 개선함으로써 발전시키고, 수정하는 과정을 수반

의식적인 연습 1 - 온라인 코드 리뷰 (단계별 난이도를 높혀가면서 미션 진행)

의식적인 연습 2 - 객체지향 생활 체조 원칙

의식적인 연습 도구 3 - 테스트

객체지향 생활 체조 원칙

객체지향 생활 체조 원칙은 소트웍스 앤솔러지 책에서 다루고 있는 내용으로 객체지향 프로그래밍을 잘하기 위한 9가지 원칙을 제시하고 있다.

규칙 1: 한 메서드에 오직 한 단계의 들여쓰기(indent)만 한다.

규칙 2: else 예약어를 쓰지 않는다.

규칙 3: 모든 원시값과 문자열을 포장한다.

규칙 4: 한 줄에 점을 하나만 찍는다.

규칙 5: 줄여쓰지 않는다(축약 금지)

규칙 6: 모든 엔티티를 작게 유지한다.

규칙 7: 2개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.

규칙 8: 일급 콜렉션을 쓴다.

규칙 9: 게터/세터/프로퍼티를 쓰지 않는다.

객체 지향 연습을 위한 좋은 방법

- 요구사항이 명확한 프로그래밍

- 약간은 복잡한 로직이 있는 프로그래밍

- DB 연동이 없도록 연습

- 특별히 UI에 대한 고려는 하지 않도록 연습

- 웹 프로그래밍은 객체 지향을 연습하기 위한 좋은 시작은 아니다.

좋은 예 : HTTP 웹 서버, 프레임워크 또는 라이브러리 구현해보기, 볼링게임 점수판(단, UI는 콘솔), 체스 게임(단 UI는 콘솔), 지뢰 찾기 게임(단 UI는 콘솔)

좋은 코드 품질을 유지하는 환경 만들기

1단계 : 새롭게 구현하는 코드, Legacy 코드 중 개선하는 코드에 대해 테스트 코드를 구현하고 리팩토링하기. 단위 테스트가 힘들다면 핵심 기능에 대한 인수테스트(Acceptance Test)라도 추가하기

2단계: Jenkins, Travis와 같은 지속적 통합 도구(Continuous Integration, CI)를 적용해 지속ㅈ거으로 테스트 코드를 실행할 수 있는 환경을 구축하기. 테스트 코드를 많이 만든느 것보다 100% 성공하는 환경을 유지하는 것이 더 중요하다.

3단계: sonarqube와 같은 정적 분석 도구를 적용한다.

4단계: 코드 리뷰 문화를 만든다.

Clean Code 가이드

함수(메소드)

- 작게 만들어라

- 한가지만 해라

- 함수 당 추상화 수준은 하나로

- 서술적인 이름을 사용하라

- 함수 인수(함수에서 이상적인 인수 개수는 0개(무항)이다. 다음은 1개이고, 다음은 2개이다)

- side effect를 만들지 마라

- 명령과 조회를 분리하라

- 오류 코드보다 예외를 사용하라

- 반복하지 마라

JUnit 사용법 및 단위 테스트

main method 의 용도

- 프로그램을 시작

- 구현한 프로그램을 테스트

main method 테스트 문제점

- Production code 와 Test Code가 클래스 하나에 존재함. 클래스 크기가 커짐. 복잡도 증가함

- Test Code가 실 서비스에 같이 배포됨

- main method 하나에서 여러 개의 기능을 테스함. 복잡도 증가

- method 이름을 통해 어떤 부분을 테스트하는지에 대한 의도를 드러내기 힘듬

- 테스트 결과를 사람이 수동으로 확인

JUnit

- main method를 활용해 테스트할 때 발생하는 문제점을 해결하기 위해 등장한 도구가 JUnit.

클린코드와 코드 리팩토링

Clean Code & Code Refactoring

# Clean Code란?

"깨끗한 코드는 한 가지를 제대로 한다." - 비야네 스트롭스트룹"깨끗한 코드는 절대로 설계자의 의도를 숨기지 않는다. 단순하고 직접적이다." - 그래디 부치"코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행하는 코드" - 워드 커닝엄
"중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기, 내게는 이 세가지가 깨끗한 코드를 만드는 비결이다." - 론 제프리"모든 팀원이 이해하기 쉽도록 작성한 코드"

반대로 나쁜 코드란, “대충 짰는데 돌아가는 코드”를 말한다. 코드를 짤 때 “대충 짜고 나중에 고치지 뭐.”라고 생각하고는 한다. But, 나중은 절대 오지 않는다.

"Later is Never"
- Leblanc’s Law -

# 클린코드가 왜 필요한가?

10 : 1
코드를 읽는 시간 : 코드를 짜는 시간

프로그래밍을 할 때 우리가 코드를 읽는 시간 : 코드를 짜는 시간의 비율이 10 : 1이라고 한다. 이직이 잦은 개발자들은 기존 사람이 남기고 간 코드를 읽고 수정하는 일이 잦다. 즉, 기존 코드를 읽어야 새 코드를 짜기 때문에 읽기 쉽게 만들면 새 코드를 짜기도 쉽다.

# 클린코드의 주요 원칙

Follow Standart Convention
Coding 표준, 아키텍처 표준 및 설계 가이드를 준수하라.
Keep it simple, Stupid
단순한 것이 효율적이다. 복잡함을 최소화해라.
Boy Scout Rule
참조되거나 수정되는 코드는 원래보다 clean해야 한다.
Root Cause Analysis
항상 근본적인 원인을 찾아라. 그렇지 않으면 반복될 것이다.
Do not multiple language in one source file
하나의 파일은 하나의 언어로 작성하라.

# 디자인 원칙(Class Design)

Simple Responsibility Principle(SRP)

하나의 클래스는 하나의 책임만 가져야 한다.

Open/Close Principle(OCP)

클래스는 확장에 대해 열려 있어야 하고, 변경에 대해서는 닫혀 있어야 한다.

의존성과 관련된 문제이다. 즉, 함수를 수정했을 때 의존성으로 인해 다른 변경사항이 생겨서는 안된다.

Liskov Substitution Principle(LSP)

파생클래스의 메소드는 기반 클래스의 메서드를 대체하여 사용될 수 있어야 한다.

즉, 서브 클래스는 상위 클래스에 기반을 두고 더 구체화하는 방식을 만들어야 한다.

Interface Segregation(ISP)

클라이언트가 사용하지 않는 메소드에 의존하지 않아야 한다. 즉, 의존성을 줄여야 한다.

DDependency Inversion Principle(DIP)

추상클래스에 구체적인 사항(하위 클래스의 내용)이 들어가서는 안된다.

ex) Super - 동물, Sub - 강아지, 고양이, … 를 포함하는 동물 클래스를 추상클래스로 정의할 때

동물 클래스에는 강아지 클래스에만 해당하는 내용이 들어가서는 안된다.

그 외 클린 코드를 위한 고려사항들.

의미 있는 변수명
- 의도가 분명한 네이밍. 발음하기 쉬운 이름을 선택한다.
명확하고 간결한 주석
- 함수의 주요 세부사항은 주석으로 남기기(함수 선언으로는 알 수 없는 내용들)
- 보기 좋게 배치하고 꾸미기(여러 개의 그룹-문단으로 나누기) + 열 정렬
읽기쉽게 흐름제어 만들기
- 삼항 연산자는 꼭 필요하거나 간단한 경우에만 이용하기.
- do-while 문은 피해라.
- 부정이 아닌 긍정문 사용하기.
```
if(a != 0){
	//부정문 보다는
}
if(a == 0){
	//긍정문 사용하기
}
```
함수는 가급적 작게. 하나의 작업만 수행하도록.