home
Backend
///
home
Backend
Algorithm
Project
///

CleanCode

Search

1. 철학

나쁜 코드가 나쁜 이유

•
생산성 저하
•
클린 코드

창발적 설계 4번째 규칙, 실용적 관점에서 타협한다

•
여러가지 규칙에 극단적으로 심취해 클래스와 메서드를 무수하게 만들지 않는다.
•
결국 좋은 코드를 만드는 이유는 생산성을 올리기 위한 것이다.
•
실용적인 관점에서 타협해야 한다.
15. chap17 - 냄새와 휴리스틱

1. 책 내용 요약

15장 Junit 들여다보기

•
세상에 완벽한 코드는 없다

16장 SerialDate 리팩토링

•
남의 코드를 비판하고, 내 코드의 비판을 듣는 건 편안하게 여겨야 할 활동이다.

2. 오픈 소스 접근법

14. chap15 & chap16 - 라이브러리 분석을 통해 코드를 바라보는 시각 기르기

1. 책의 예제

명령형 인수 구문 분석기

코드 초안
•
모든 로직이 하나의 클래스에 들어가 있다.
•
처음부터 지저분한 코드를 짜려는 생각은 없었고, 코드를 어느 정도 손봤지만 새로운 인수 유형이 들어오면서 문제가 발생했다.
•
이제는 개선해야 할 때라는 걸 깨닫고, 변경 전후 시스템이 동일하게 돌아간다는 사실을 확인하기 위해 테스트들을 작성해두었다.
코드 완성본
•
Args 클래스에서 코드 중복을 최소화하고, ArgsException 클래스를 분리했다. ArgumentMarshaler 클래스를 통해 여러 인수에 대한 추후 확장성을 만들어냈다.
•
코드만 분리해도 설계가 좋아진다. 관심사를 분리하면 코드를 이해하고 보수하기 훨씬 더 쉬워진다.
13. chap14 - 점진적인 개선

1. 동시성 프로그래밍이란

동시성 프로그래밍

•
어플리케이션을 효율적으로 실행하기 위해 멀티코어를 온전히 활용하도록 구현하는 방식
•
외부 서비스의 응답을 기다리면서 아무일도 하지 않으면 CPU 사이클이 낭비됨

동시성 프로그래밍 이해하기

동시성이 구현되지 않은 경우

병렬성을 구현한 경우

12. chap13 - 동시성

1. 창발적 설계란

창발성(Emergence)

하위 계층에는 없는 특성이나 행동이 상위 계층(전체 구조)에서 자발적으로 돌연히 출연하는 현상
•
각각의 개미는 집을 지을 능력이 없지만, 작은 개미들의 상호작용을 통해 집이라는 결과물이 나오는 것처럼 작은 요소들의 상호작용 반복이 전체구조에 영향을 미친다.

창발적 설계

단순한 4가지를 반복하다보면 전체적으로 깨끗한 코드가 만들어진다
1.
모든 테스트를 실행한다.
2.
중복을 없앤다.
3.
프로그래머 의도를 표현한다.
4.
클래스와 메서드 수를 최소로 줄인다(실용적 관점에서 타협한다).
11. chap12 - 창발적 설계로 깔끔한 코드 구현하기

1. 관심사 분리

관심사 분리

construction(생성)과 use(사용)은 아주 다르다
•
소프트웨어 시스템은 (어플리케이션 객체를 제작하고 의존성을 서로 ‘연결’하는) 준비 과정과 (준비 과정 이후에 이어지는) 런타임 로직을 분리해야 한다.
•
객체의 생성과 객체를 사용하는 부분을 분리한다.

시작에 대한 관심사 분리

•
시작 단계는 모든 어플리케이션이 풀어야 할 관심사이다.
•
main 함수에서 시스템에 필요한 객체를 생성한 후 어플리케이션에 넘긴다.
•
어플리케이션은 그저 만들어진 객체를 사용한다.
•
모든 객체가 잘 생성되었다는 가정하에 객체를 이용한 개발에 집중할 수 있다.
10. chap11 - 관심사 분리 패턴들

1. 캡슐화되어야 한다

캡슐화 : 객체의 실제 구현을 외부로부터 감추는 방식

•
클래스를 개발할 때 기본적으로 구현을 감추고, 외부 객체와 상호작용하는 부분만 노출한다.
•
외부의 잘못된 사용을 방지한다.
•
필드를 private으로 제한, get으로 읽는다.
•
수정은 push, pop 메서드를 통해서 일어나도록 제한한다.

2. 단일 책임 원칙

클래스는 작아야 한다

9. chap10 - 클래스 잘 설계하기

1. 테스트코드의 중요성

•
테스트 코드는 실수를 바로잡아준다.
•
테스트 코드는 반드시 존재해야 하며, 실제 코드 못지 않게 중요하다(테스트 코드 짜는 연습을 많이 해야 함)
•
테스트 케이스는 변경이 쉽도록 해야 한다. 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위테스트이다. 테스트 케이스가 있으면 변경이 두렵지 않다. 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다. 테스트 커버리지가 높을수록 버그에 대한 공포가 줄어든다.
•
지저분한 테스트 코드는 테스트를 안하는 것만도 못하다.
•
테스트는 자동화되어야 한다.

2. 테스트의 종류

8. chap09 - 깨끗한 테스트 코드

1. 경계란

•
오픈소스, 라이브러리를 안쓰는 프로젝트는 없다.
•
우리가 만든 코드에 외부에서 들어온 코드를 병합해야 한다.
•
외부 코드는 외부에서 만든 코드인데, 외부 시스템과 호출하거나 단순히 외부에서 만들어진 코드일 수 있다.
•
우리 코드와 외부 코드를 깔끔하게 통합시키기 위해 경계를 잘 지어야 한다.

2. 경계 짓기 - (1) 우리 코드를 보호하기

•
캡슐화(Encapsulation) - 객체의 실체 구현을 외부로부터 감추는 방식
7. chap08 - 경계

1. 예외 처리 방식

•
오류 코드를 리턴하지 말고, 예외를 던져라
•
예외를 던지고 처리하는 방식

2. Unchecked Exception을 사용하라

•
Exception 가계도
•
Checked vs Unchecked Exception
•
[Effective Java] Exception에 관한 규약
6. chap07 - 오류 처리

1. 자료구조 vs 객체

•
예시 - Shape
상황에 맞는 선택을 하면 된다
•
자료구조를 사용하는 절차적인 코드는 기본 자료구조를 변경하지 않으면서 새 함수를 추가하기 쉽다.
•
그러나 절차적인 코드는 새로운 자료구조를 추가하기 어렵다. 그러려면 모든 함수를 고쳐야 한다.
•
객체지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.
•
객체지향 코드는 새로운 함수를 추가하기 어렵다. 그러려면 모든 클래스를 고쳐야 한다.
5. chap06 - 객체와 자료구조

1. 포맷팅이 중요한 이유

•
가독성에 필수적이다

2. 클린코드 포맷팅

적절한 길이 유지 : ~ 200 lines, < 500 lines
•
200 라인
•
밀접한 개념은 가까이

3. Java Class Declarations

4. chap05 - 형식 맞추기

1. 주석을 최대한 쓰지 말자

주석은 나쁜 코드를 보완하지 못한다
•
코드에 주석을 추가하는 이유는 코드 품질이 나쁘기 때문이다. 자신이 저지른 난장판을 주석으로 설명하지 말고 개선하는데 시간을 보내야 한다.
•
코드로도 의도를 표현할 수 있다.
주석은 방치된다
•
코드의 변화에 따라가지 못한 채 주석은 방치된다.
•
코드는 컴파일되어 호출되나 주석은 그저 주석이다. 그 자리에 방치되고 결국 의미없는 텍스트가 된다.

2. 좋은 주석

3. chap04 - 코드를 보조하는 주석

1. SOLID

객체지향 설계의 5가지 원칙

1.1 SRP : 단일 책임 원칙

한 클래스는 하나의 책임만 가져야 한다.
•
클래스는 하나의 기능만 가지며, 어떤 변화에 의해 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.
•
SRP 책임이 분명해지면, 변경에 의한 연쇄작용에서 자유로워질 수 있다.
•
가독성 향상과 유지보수가 편해진다.
•
실전에서는 쉽지 않지만 항상 상기하며 작업해야 한다(정말 쉽지 않음).

1.2 OCP : 개방-폐쇄 원칙

소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
•
변경을 위한 비용은 가능한 줄이고, 확장을 위한 비용은 가능한 극대화 해야 한다.
2. chap03 - 함수

1. 나쁜 코드

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

1. 1 나쁜 코드가 나쁜 이유

1.
깨진 유리창의 법칙
2.
생산성 저하
3.
새로운 시스템을 만들어야 한다

1.2 나쁜 코드를 짜는 이유

1.
일정이 촉박해서
1. chap01 & chap02 - 깨끗한 코드, 의미 있는 이름