Clean Code 01

기술 부채는 생산성을 저하시킨다.
시작부터 클린한 코드를 유지 해야 한다.
빨리 목표에 다다를 수 있는 방법은 클린코드 이다.
잘 읽혀야 한다.
효율적인 코드 여야 한다.
자잘한 디테일에 신경 써야 한다.
클린한 코드는 한 가지에 집중한다.
다른이가 수정하기 쉬워야 한다.
코드는 간결할 수록 좋다.
중복을 없애라.
클래스/메소드는 한 가지 일만 하게 하라.
일찍 추상화하면 프로젝트 속도를 높일 수 있다.
유지보수를 위해 읽기 쉬운 코드를 작성하라.

Clean Code 02

변수명, 메소드명을 이해하기 쉽게 작성해라.
추후에 코드를 보는 사람이(나를 포함해서) 알아보기 쉽게 이름을 명명하라.
명확하게 이름을 지어라.
헷갈리게 하는 이름은 피해라.
개발자에게 의미 있는 이름을 사용할때도 주의해라.
클래스이름에 info, data와 같은 용어는 쓰지 말자 혼란을 줄 수 있다.
단축어는 사용하지 말아라. 알아보기 어렵다.
자신의 기억력을 맹신하지 말아라.
클래스 이름은 명사/명사구를 이용해라.
메소드 이름은 동사/동사구를 이용해라.
prefix는 get, set, is, has, should등으로 시작해라.
일반적인(대중적인) 이름을 사용해라.
단순 add -> append or insert로 구체적으로 써라.
소프트웨어 공학에서 자주 사용하는 이름들은 모두 쉽게 알아볼 수 있으니 기피 해야 할 단어는 아니다.
메소드로 표현이 어정쩡하다면 클래스로 조금 더 구체적으로 표현해라.

Clean Code 03

메소드를 작게 만들어라
메소드는 한가지 일만 하게 만들어라
한가지 작업만 하게 하려면 메소드 안에서의 작업 레벨도 동일해야 한다.
코드는 소설처럼 위에서 아래로 읽기 쉽게 작성 하라.
메소드의 단계도 하나씩 내려가는것이 좋다.

아래와 같이 말이다.

class CarFactory {
  fun makeSedan() {
    makeBody()
    makeGlass()
    makeWheel()
    makeLoop()
  }

  fun makeBody() {
    makeFrontFrame()
    makeMiddleFrame()
    makeTailFrame()
  }

  fun makeFrontFrame() {
    makeLeftFender()
    makeBonnet()
    makeRightFender()
  }

}

switch/if 문도 동일하다.
서술적인 이름을 사용하라. 서술적 이름은 코드를 이해하기 더 쉽게 해준다.
메소드에서 인자의 숫자는 작게 해라. (많아도 1개가 적당하다.)
boolean 값을 인자로 사용하지 말아라.
여러개 값을 넘겨야 한다면 클래스로 만든 객체 하나를 넘기는 것은 어떠한가?.
잘게 많이 분리하여 테스트를 쉽게 한다.
메소드가 하는 일은 한개 여야 한다.
명령과 조회를 분리 하라.
오류 코드 보다 예외를 사용해서 더 깔끔하게 만들어라.
오류코드를 enum으로 관리 하는것은 새로운 기능 추가시 많은 비용을 발생한다. 예외를 사용하는 것이 더 안전하다.
중복은 없어야 한다.
클린코드는 한번에 만들어 지지 않는다. 만들고 테스트하고 고치고를 반복해서 위 내용들을 받아 들이게 작성하자.

Clean Code 04

주석은 나쁜 코드를 보완하지 못한다.
코드에 모든 의미를 담을 수 있게 코딩 하라.
코드는 수정 해도 주석을 수정하기란 쉽지 않다.

좋은 주석의 종류에는 다음과 같은 것들이 있다.

라이센스등의 법적내용을 표시하는 주석
정보를 제공하는 주석
의도를 설명하는 주석
결과를 경고 하는 주석
TODO 주석
중요성을 강조 하는 주석
Javadocs

나쁜 주석

의미 없이 달리는 주석
코드 내용을 그대로 설명하는 주석 (코드를 보면 알수 있다. )
오해할 여지가 있는 주석
의무적으로 다는 주석
관리 되지 않는 주석은 없으니만 못하다.
이력을 기록하는 주석 (git과 같은 소스 관리 시스템이 존재하므로 불필요)
없어도 되는 의미 없는 주석
주석 대신 소스 코드로 내용을 알기 쉽게 표현하라. 줄수를 줄이는 것만이 좋은 코딩은 아니다.
위치 표시 주석은 아주 가끔 꼭 필요할 때만 사용 하는 것이 좋다.
소스 관리 시스템이 해주는 일들을 의미 없이 소스에 기록 할 필요는 없다.
주석으로 처리한 코드 그냥 삭제해도 소스 관리 시스템이 기억한다. 대신 소스 관리 시스템에서 찾기 쉽게 커밋 설명을 잘 기록하자.
시스템 전반에 걸쳐 있는 값을 기록 할 필요는 없다. 하나를 수정 한다면 모두를 수정 해야 하기 때문이다.
필요하다면 기준이 되는 값만 기록 하라.

Clean Code 05

깔끔하게 작성하면 코드 작성에 공들인 것으로 보인다.
코드 형식을 맞추기 위한 규칙을 정하고 모두가 그규칙을 따라야 한다.
가독성을 좋게 하기 위해서 깔끔한 코드는 중요 하다.
파일당 코드 라인수를 500줄 미만으로 해라.
라인수가 적을 수록 이해하기 쉽다. (너무 짧아도 이해하기 어렵다. 줄이는 것만 신경 써도 안된다.)
점차 자세한 내용을 기술 하듯이 써라. 제목 => 요약내용 => 자세한 내용
줄바꿈을 적절하게 이용해라.
서로 밀접한 개념은 가까이 둬야 한다.
변수 선언은 사용하는 위치에서 최대한 가까운 위치에 선언한다.
인스턴스 변수는 클래스 맨처음에 선언 한다.
코드를 읽기 쉽게 호출하는 메소드아래에 호출 되는 메소드를 배치 한다.
개념적인 친화도가 높은 메소드를 가까이 배치 한다.
한줄 쓰기보다 들여쓰기가 가독성이 더 좋다.
한사람이 짠것 처럼 팀에서는 규칙을 맞춰 작업 해야 한다.

Clean Code 06

구조를 숨기기 위해 추상화를 이용한다.
자료 구조라면 내부를 노출 해도 괜찮다.
자료구조가 아니라면 내부 구조를 숨겨야 한다.
인터페이스 또한 그런 용도 이다.
사용자는 구현을 모르고 핵심을 조작 할 수 있어야 한다.
절차적인 구조와 객체지향 적인 구조를 적절하게 사용 해야 한다.
객체지향적인 코드의 특징과 절차지향적인 코드의 구조에 따라 기능 추가시 변경 추가 해야 하는 주변 파일들이 생기는 장단점을 잘 이해 하고 있어야 한다.
정답은 없다. 상황에 맞게 활용 해야 한다.
한줄로 작성할 수 있는 코드가 때로는 여러줄로 표현하는게 나을때도 있다.
객체는 동작을 공개/자료구조는 데이터를 공개

Clean Code 07

에러 핸들링
예외 처리를 위해서 많은 if 문을 처리하는 것 보다 Exception을 이용하여 처리 하는 것이 낫다.
그러면 코드가 깔끔해지고 보기 쉬워 진다.
try catch문으로 Exception을 활용 하자.
finally는 Exception이 발생해도 꼭 실행 해야 하는 코드를 넣는다. (스트림의 close 같은 처리 말이다. )
득과 실을 따져 처리해야 한다.
Checked Exception (컴파일 과정에서 체크)과 Unchecked Exception (런타임 과정에서 발생) 의 의미를 이해하고 적절하게 사용 해야 한다.
외부 라이브러리로 인한 Exception처리시 Wrapping을 통한 오류처리로 혹시라도 lib가 바뀌게 되면 대응하기 쉽게 해라.
Exception을 대응하는 위치를 고려해라 (캡슐화를 위하여 고민할 필요가 있다.)
Null을 리턴 값으로 사용하지 마라.
Null을 인자 값으로 사용 하지 마라.
Exception을 잘 이용하면 코드가 깨끗해 질 수 있다.

Clean Code 08

외부 코드와의 결합
코드와 더욱 어울리는 결합을 하게 하기 위해서 wrapping을 한다.
외부 패키지가 변경되더라도 소스 수정을 wrapping한 클래스만 하면 된다.
새로운 라이브러리 사용을 위한 test를 작성하라.
추후 라이브러리가 변경되도 test를 통해 기능을 확인 할 수 있다.
아직 개발되지 않은 interface를 위해 별도의 interface를 만들고 새로운 기능이 구현되면 그기능을 wrapping해서 동작하게 만든다. 타인의 개발속도와 상관 없이 개발이 가능 하다.
서드파티 코드를 많이 알지 못하게 해야 캡슐화를 제대로 했다고 할 수 있다.
주객이 전도 되는 상황을 만들지 않기 위해 wrapping을 한다.

Clean Code 09

TDD 법칙 3가지

실패하는 단위 테스트를 작성할때 까지 실제 코드는 작성하지 않는다.
컴파일은 실패 하지 않으면서 실행이 실패하는정도로 단위 테스트를 작성한다.
실패하는 테스트를 통화할 정도의 실제 코드를 작성한다.

위 법칙을 따르면 테스트코드와 실제 코드가 같이 나온다.
여러개를 하나로 묶는 것이 아닌 하나를 여러개로 쪼개어 테스트 한다.
테스트 코드는 깨끗하게 유지 해야 한다.
테스트 코드를 깨끗하게 유지 하려면 가독성을 좋게 만들어야 한다.
이해하기 쉽게 만들어야 한다.
이해하기 쉽게 만들기 위해 메소드를 사용 한다.
하나의 메소드에 많은 테스를 구현하는것이 아니라 메소드 별로 하나의 테스트만 확인 할수 있도록 작성해서 가독성을 높이고 코드를 읽기 쉽게 만든다. 여기서 테스트 하나란 개념적인 갯수 이다.
중복되는 assert코드는 가독성을 떨어뜨린다.

테스트의 규칙 FIRST

F. ast 빠르게 - 테스트는 빠른 실행을 보장해야 한다. 그래야 자주 돌려볼수 있다.
I. ndependent 독립적으로 - 테스트는 독립적으로 테스트의 순서에 구애 받지 않고 실행할 수 있어야 한다.
R. epeatable 반복가능하게 - 언제 어디에서나 반복 가능해야 한다. 환경에 구애 받지 않고 테스트 할 수 있어야 테스트에 대한 핑계가 사라진다.
S. elf validating - 테스트는 성공과 실패만이 존재 한다. 테스트 만으로 결과를 확인 할 수 있어야 한다.
T. imely 적시에 - 적절한 타이밍에 작성해야 한다. 실제 코드를 작성하기 전에 작성해야 한다.

Clean Code 10

테스트를 위한 클래스의 공개는 최후의 수단이다. (접근제한자의 공개)
클래스는 작아야 한다.
소스코드의 여러줄 묶음은 하나의 생각을 표현하는 것이다. 줄이 바뀌면 생각의 주제가 바뀌는 것이다.
단일책임의 원칙을 지키기 위해서는 클래스를 작게 만들어야 한다.
자동차 클래스 안에는 바퀴, 엔진, 운전대, 라디오, 시트 등등등 여러가지 오브젝트들로 이루어져 있다. 이런식으로 자동차를 구현하는데 클래스가 복잡해 진다면 안에 존재하는 여러 다른 오브젝트를 이룰수 있는 정보들을 새로운 클래스로 분리 하여 클래스를 더 작게 쪼갤 수 있다.
이렇게 더 작은 클래스들로 쪼개면 수정이 발생하거나 기능추가가 발생할 때 맡은 책임에 따라 분리된 클래스 일부분만 수정 하면 된다. 이는 OOP의 장점을 효율적으로 사용할 수 있는 방법이기도 하다.
메소드의 인자 갯수가 늘어난다는 것은 분리해야할 클래스가
프로그램을 하면서 메소드의 인자 갯수가 늘어나면 이는 하나의 클래스로 응집 시킬수 있는 정보인지 확인 하고 클래스를 분리, 분리된 클래스로 만든 오브젝트를 인수로 이용 해야 한다.
상세한 구현에 의존하는 코드는 테스트가 어렵다.
추상화를 통해 테스트가 가능할 정도로 시스템의 결합도를 낮춤으로 유연성과 재사용성이 높아 진다.
결합도가 낮다는 말은 시스템의 여러 요소가 서로 긴밀하지 않아 변경으로 부터 자유롭다는 뜻이다.
ex) 클래스가 외부로 부터 받는 인자를 인터페이스로 구현하면 테스트는 가능하고 실제 구현되는 구현 클래스는 시스템과 응집력이 떨어지는 클래스가 된다. 이는 테스트를 편리하게 한다.

지금까지 이야기한 내용은 SOLID에 대한 내용입니다.
S - 단일 책임만 가져야 한다.
O - 확장에는 열려있어야 하고 변경에는 닫혀있어야 한다.
L - 상속을 이용한 클래스 구현으로 클래스가 변경되더라도 같은 클래스를 상속받고 있는 객체라면 소스 수정이 없어야 한다.
I - 인터페이스는 하나의 기능만 해야한다. (의미없는 인터페이스는 코드를 복잡하게 만든다.)
D - 다른 클래스에 의존적인 코드를 만들면 변경에 취약하게 된다. 추상클래스를 사용하라.

Clean Code 11 시스템

의존적인 코드에서 벗어나야 한다. 시스템이 특정클래스에게 의존적인 코드를 가진다면 이는 코드를 유지 보수 하는데 많은 비용을 초래 할 수 있다.
이를 방지 하기 위해 의존성을 생각하면 코딩 해야 한다.
사용과 제작을 분리하는 3가지 방법 -> main 분리, 팩토리, 의존성 주입
main 분리 - main함수에서 필요한 객체를 생성 후 이를 실제 어플리케이션에 주입
팩토리 - 객체 생성 시점을 어플리케이션이 결정할 필요가 있을때 추상 팩토리 패턴을 사용하여 생성 코드를 감춘다.
의존성 주입 - 이는 마치 배터리를 교체 할수 있는 휴대폰과 같다. 배터리 일체형의 휴대폰의 경우 배터리의 성능이 저하되면 휴대폰을 교체하거나 서비스 센터에 가서 배터리 교체 및 교체 공임을 지불해야한다. 하지만 배터리를 분리할수 있는 휴대폰의 경우 배터리를 쉽게 교체 할 수 있기 때문에 서비스센터의 방문도 교체에 들어가는 비용도 필요 하지 않다.
이는 배터리가 휴대폰의 일부 처럼 하나가 되었을때 생기는 문제점을 주입이라고 하는 의존성 분리로 인해 응집성을 낮춰 준다. 단지 배터리를 주입하는 타이밍이 문제이다. 이는 팩토리를 통해 휴대폰에 맞는 배터리를 주입 받을 수 있다.
안드로이드로 치자면 koin, dagger 라이브러리가 주입의 역할을 한다.
스케일링 - 시스템은 우리가 고려했던거랑 다르게 진화 및 성장한다. 시스템을 설계할때 앞으로의 일을 예측할 수 없기때문에 현재에 주어진 요구사항에 맞게 시스템을 설계 하고 구성할 수 밖에 없다. 그러므로 추후 발생할 수 있는 확장 및 추가를 위해 클린코드가 더욱 필요하다.
스케일링의 방법으로는 프록시 패턴(자바의 리플렉션을 이용)을 이용하여 실제 클래스와 클래스의 기능을 분리하는 방법이 있다. 이는 추후 기능이 추가 되었을때에도 프록시 클래스만 변경 하면 된다.
이는 스프링의 Bean을 사용 하는 방법과도 같다.
아키텍처와 분리가 가능한 도메인논리는 테스트 주도 아키텍처 구축이 가능하다.
단순한 아키텍처를 필요에 따라 복잡한 아키텍처로 키울 수 있다.
효과적으로 분리한 논리는 확장이 가능하다.
표준이 항상 답은 아니기때문에 이득이 있다고 판단되는 경우 사용하라. (프로그래밍에 답은 없다.)
아키텍처는 깨끗해야 한다.
추상화 단계에서의 의도는 명확해야 한다.

POJO
구현 관심사를 분리 책을 읽어봐야 할 필요가 있다 너무 줄여놔서 무슨말인지...

Clean Code 12 창발성

창발성 - 자발적으로 떠올라 출현하는 성질 (떠오름 현상)
프로그램에서의 창발성은 어떤 좋은 규칙과 원칙에 따라 설계하면 그것들이 모여 좋은 거시적 설계가 된다라는 뜻
여기서 말하는 좋은 설계 4가지는 다음과 같다.

모든 테스트를 실행한다.
중복을 없앤다.
프로그램의 의도를 표현한다.
클래스와 메서드 수를 최소로 줄인다.

좀 더 자세하게 그내용을 살펴 보면

모든 테스트를 실행 하라.

테스트가 가능한 시스템을 만들려고 노력하면 시스템의 품질이 높아진다. 크기가 작고 목적이 분명한 클래스가 나온다.
결합도가 높으면 테스트 케이스를 작성하기 어렵다. 의존성 주입, 하나의 목적을 가지고 만든 클래스, 인터페이스, 추상화 등의 도구를 이용하여 결합도를 낮춘다. 테스트가 가능하면 객체지향 방법론이 지향하는 목표를 달성하게 되고 이는 설계 품질향상으로 이어진다.
코드 중복을 줄여라 간단한 메소드라도 코드가 반복되고 있다면 반복되는 코드를 메소드로 대체 할 수 있다.
반복되는 코드를 메소드로 만들고 나면 클래스와 어울리는 기능인지 아닌지 확인 할 수 있다. 만약 어울리지 않는 기능이라면 새로운 클래스로 만들 수 있다. 이는 단일 기능 원칙과 일맥상통한다.
클래스 안의 메소드 내용이 비슷하다면 탬플릿 메소드 패턴을 이용해 클래스를 분리할 수 있다.
처음 개발자가 프로그램 할때에는 프로젝트에 집중하고 있기 때문에 합리적이라고 생각했던 코드의 구멍이 시간이 지나서 내가 혹은 다른 누군가가 그 코드에 기능 추가 혹은 수정을 해야 한다고 한다면 더욱더 커져있고 어려움으로 다가갈 것이다. 코드 변경 시 버그의 싹을 심지 않게 하려면 개발자의 의도를 분명하게 표현해야 한다. 짧은 코드는 개발자의 의도를 분명하게 한다.

좋은 이름을 선택한다.
클래스와 메소드의 크기를 줄인다.
표준명칭(패턴을 이용하여 모두가 알아볼수 있는 이름)을 이용한다.
테스트 케이스를 꼼꼼하게 작성한다.

Clean Code 13 동시성

동시성 (concurrency)은 무엇을 할것인가?, 언제 끝날것인가?간의 의존성을 해소 시켜준다. 처리량과 구조개선에 도움을 줄 수 있다.
쓰레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다.
무엇과 언제를 분리하여 다중쓰레드로 만들면 어플리케이션의 구조 및 효율이 높아 진다.
두개의 쓰레드가 같은 데이터를 공유 한다고 하면 데이터의 무결성을 보증하기 어렵다.
동시성 코드가 일으키는 문제로 부터 시스템을 방어하는 원칙과 기술

단일 책임의 원칙
자료 범위를 제한 - 공유 자료를 줄여라. 많을 수록 문제를 야기한다.
자료 사본을 사용 - 공유 하지 않는게 최선!!
쓰레드는 가능한 독립적으로 구현하라 - 공유하는 자원 없이 독자적으로 돌아가게 처리

동시성은 무조건 성능향상을 가져오지 않는다. 알맞는 조건에서만 성능향상이 이루어 진다.
무엇과 언제를 분리하는 작업은 시스템에 많은 영향을 준다.
Web, EJB와 같은 컨테이너를 사용하는 시스템은 동시성 사용이 주가 된다.
동시성을 만드는것은 오버헤드를 일으킨다.
동시성을 방어하기 위해서는 코드를 분리해야 한다.
synchronized 키워드로 공유 객체의 무결성을 보장 할 수 있다.
공유자원의 경우는 복사해서 사용해라.
쓰레드는 독립적으로 작성 해라.
쓰레드 환경에 안전한 클래스들을 이용하자.
쓰레드를 이용하면서 주의 해야 할 상황 deadlock, livelock, 처리량 문제, 효율성 저하 문제
synchronized 키워드가 만능은 아니다. 한클래스가 두개의 synchronized를 가지고 있다면 문제를 일으킬 수 있다. 또한 락으로 인해 한번에 한쓰레드만 실행 가능하므로 전체적으로 부하가 될 수 있다. 임계영역수를 줄이고자 임계영역을 늘리면 쓰레드간의 경쟁으로 프로그램 성능이 저하 된다.
공유된 객체에서 두가지 이상의 메소드를 사용하는것을 피해라.
위 상황을 피할수 없는 상황이라면 다음을 이용해 해결해보자.

클라이언트 기반 잠금 - 공유객체를 사용하는 코드에서 공유 객체를 잠근다. 공유객체를 사용하는 모든 곳에서 lock을 걸어야 하기 때문에 비효율적이다.
서버 기반 잠금 - 서버를 잠그고 동작수행 후 클라이언트에게 새로운 메소드를 제공한다.
중계된 서버 - 잠금을 수행하는 중계자를 작성한다. 기존 서버를 변경할 수 없는 경우사용한다.

종료 코드를 개발 초기부터 고민해야 한다.
다중 쓰레드 관련 테스트 하기

엉뚱한 실패는 잠정적인 쓰레드 문제이다.
다중 쓰레드가 아닌 순차적인 코드 부터 정상적으로 만들자
다중 쓰레드를 쓰는 부분을 다양한 환경에서 사용할 수 있게 쓰레드 코드를 구현하라
다중 쓰레드를 사용하는 부분을 상황에 맞게 조율 할 수 있게 작성하라.
프로세스보다 많은 쓰레드를 돌려보아라
다른 플랫폼에서 돌려 보아라 - 운영체제 별로 상이한 쓰레드 정책을 가지며 멀티 쓰레드 실행에 영향을 미치기 때문에 실행환경에 따라 다르게 동작한다. 실제 배포 환경에서 테스트가 필수 이다.
코드에 보조코드 instrument를 넣어 강제 실퍠를 만들어 보아라. - 쓰레드 코드는 오류를 찾기 힘들다 이유는 동시 실행으로 인해 재현이 어렵기 때문이다. 흔들기 기법으로 오류를 찾아라.

다중쓰레드를 올바르게 구현하기는 어렵다.

*TODO - 예제 더 찾아볼 필요 있음 *

Clean Code 14 점진적 개선

한번에 코드를 완벽하게 작성할 수 없다.
코드는 원래 고치고 또 고치는 것이다.
우선 원하는 기능을 코딩하고 그안에서 클린코드가 이야기 하는 바들을 적용 시켜 나가는 것으로 연습하고 익혀 나가면 머지 않아 고치는 횟수가 적어 질수 있도록 코드의 퀄리티가 달라 질것이다.

Clean Code 결론 (요약)

---

주석 없이도 읽기 쉽게 간결하고 알아보기 쉬워야 한다. 이는 유지 보수와 직결된다.
클래스 메소드를 작게 만들면 SRP도 지킬수 있고 소스도 읽기 쉬워진다. 테스트 하기도 쉬워 진다.
메소드를 작게 만드는 과정은 중복을 없애는 과정과도 같다.
메소드 이름은 조금 더 구체적으로 써라 예를 들면 add 보다는 append, insert가 더 구체적이다.
메소드 안에서 다른 메소드를 호출한다면 같은 레벨을 유지 해야 한다. 그래야 읽기 쉽고 구분 하기 쉽다.
메소드의 인자는 작게 해라. 많아야 한다면 클래스를 새로 만들어야 하는게 맞을지 모른다.
명령과 조회를 분리하라.
오류 확인 코드 보다 예외를 사용해서 코드를 깔끔하게 만들어라.
팀내에서의 규칙도 중요하다. 모두 같은 형태를 가져가면 공동 작업에도 유리 하다.
자료 구조가 아니라면 내부를 노출 하지 말아라.
null 값은 리턴값으로도 인자값으로도 사용하지 말아라.
외부코드를 프로젝트와 어울리게 하기 위하여 wrapping 하라.
테스트의 법칙 FIRST (빠르게, 독립적으로, 반복가능하게, 테스트만으로 확인가능하게, 적시에 )
줄바꿈을 적절히 이용하자.
SOLID를 적용해서 개발하자. (하나의 책임만, 확장은 용이하게 변경은 닫혀있게, 상속을 통해 부모와 자식클래스간의 동작은 동일하게, 사용하지 않는 인터페이스는 없게, 의존성의 최소화 하면서 )
의존적인 코드를 벗어나야 한다. 의존성을 주입하는 방법으로 해결해라 (Factory 패턴)
객체 생성단계도 고민해봐야 한다.
추후 일어날 확장을 고려해서 클린 코드를 유지해야 한다.
스케일링방법으로 자바의 리플렉션을 이용한 프록시 패턴이 있다.
클린코드를 유지하면서 프로젝트를 진행하면 그런것들이 모여 거시적 설계가 된다.
모든 테스트를 실행하라. 테스트 가능한 시스템을 만들면 시스템 품질이 높아진다.
쓰레드를 잘사용하기란 쉽지 않다. 공유데이터는 피해야 한다.
쓰레드는 무엇을 언제 하느냐가 중요 하다.
다중쓰레드 관련 테스트는 어렵기 때문에 여러 조건을 인위적으로 만들어서 테스트 해야 한다.
좋은 코드는 한번에 나오는것이 아니다. 계속 관심을 가지고 좋은 코드를 유지하기 위해 노력해야 한다.
원하는 기능을 머리속에서 나오는대로 구현하고 클린코드의 조건들을 충족시키는 코드로 변형 해야 한다.

MonsterB

객체지향 프로그램 Clean Code (클린 코드)