클린 코드를 읽고 나서

안녕하세요.

방구석 개발자입니다.

클린 코드를 사서 열심히 읽었는데요.

너무 좋은 책이라서 추천 드리려고 합니다. (2회독을 했지만 아직도 어려운 부분이 많긴해요.. ㅎㅎ)

후기 

이 책을 읽고 나서는 제 자신이 부끄러웠습니다. 그동안 쓰레기 코드를 양산하는게 아닐까 싶은 생각도 들었습니다. 특히 저는 예전에 boolean을 매개변수로 가지는 함수를 만든 적이 있는데 이 책을 읽고 다신 그렇게 하지 말아야한다는 것을 알게 되었습니다.

특히 동시성부분에서 멀티스레드 코드를 정말 지독하게 테스트 해야 되는 구나를 알게 되었습니다.

최근에 쓰레드를 직접 객체 생성하도록 작성한 스케줄링 코드를 개선한 적이 있는데 스프링에서 주워지는 비동기 코드라던지 의존성주입을 통해 제어했으면 어땠을까? 라는 생각과 조금 일찍 이 책을 봤다면 하는 아쉬움이 있었습니다.

다형성과 enum을 이용하면 확장에 개방적이고 수정에 폐쇄적인 쉬운 코드가 된다는 것을 알게 되었습니다.

개선할 부분이 많아서 더 성장 할 수 있구나 라는 생각도 들었습니다. 쉬운책이 아니라서 2번을 읽었지만 그래도 어려운 부분이 있었고 특히 13장, 부록 챕터 동시성은 정말 어려워서 한자 한자 읽었습니다. 누군가 개발자책 추천해달라고 하면 클린코드를 추천할거 같습니다. 거기다가 계속해서 코드에 책 내용을 녹여내는 연습도 필요한거 같습니다. 저 또한 

개발 중에 클린코드의 내용을 부단히 채워보겠습니다.

정리

10장부터는 정리하는게 도움이 될거 같아서 따로 메모를 하였습니다.

10장 클래스

클래스는 작아야 한다. 작게가 기본 규칙이다.

클래스는 맡은 책임이 작아야 한다.

메서드가 5개인 클래스도 책임이 많으면 안된다. *단일책임원칙(SRP)

클래스는 인스턴스 변수 수가 작아야 한다.(함수를 작게 매개변수 목록을 짧게)

큰 함수를 작은 함수 여럿으로 나누기만 해도 클래스 수가 많아진다.

클래스 일부에서만 사용되는 메소드는 코드를 개선 할 잠재적인 여지를 시사한다.

클래스에 손대는 순간 설계를 개선하려는 고민과 시도가 필요하다.

OCP : 확장에 개방적이고 수정에 폐쇄적이어야 한다는 원칙

결합도를 최소로 줄이면 자연스럽게 또 다른 클래스 설계 원칙인 'DIP'를 따르는 클래스가 나온다.

DIP : 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙이다.

11장 클래스

모듈성을 깨서는 절대 안된다.

사용과 제작을 분리하는 강력한 매커니즘 : 의존성 주입이다.

진정한 의존성 주입은 여기서 한 걸음 더 나아가 클래스가 의존성을 해결하려 시도 하지 않는다. 클래스는 완전히 수동적이다.

의사결정의 최적화 : 가장 적합한 사람에게 책임을 맡기자.

가능한 마지막 순간까지 결정을 미루는 것이 최선일 때도 있다.

12장 창발성

단순한 설계 네가지 : 소프트웨어 품질을 크게 높여준다 - 켄트 백-

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

위 목록은 중요도 순이다.

놀락게도 '테스트 케이스를 만들고 계속 돌려라'라는 간단하고 단순한 규칙을 따르면 시스템은 낮은 결합도와 높은 응집력이라는 객체지향방법론이 지향하는 목표를 저절로 달성한다.

templat method pattern : 고차원의 중복을 제거하는 패턴

소프트웨어 프로젝트 비용 중 대다수는 장기적인 유지보수에 들어간다.

그러므로 코드는 개발자의 의도를 분명히 표현해야 한다.

1. 우선 좋은 이름을 선택한다.
2. 함수와 클래스 크기를 가능한 줄인다.
3. 표준 명칭을 사용한다.
4. 단위 테스트 케이스를 꼼꼼히 작성한다.

표현력을 높이는 가장 중요한 방법은 노력이다.

가능한 독단적인 견해는 멀리하고 실용적인 방식을 택한다.

13장 동시성

동시성과 깔끔한 코드는 양립하기 어렵다. 깨끗한 동시성은 책 하나를 할당할 정도로 복잡한 주제이다.

동시성이 필요한 이유?

1. 무엇과 언제를 분리하는 프로그램
2. 응답시간, 처리량으로 분리가 필요할때

동시성은 때로 성능을 높여준다.(항상x)

동시성은 시스템의 구조가 크게 달라진다.

동시성은 잘못된 설계, 구조 개발로는 결과가 의도에 맞지 않게 된다.

동시성방어원칙!

동시성은 복잡성 하나만으로도 따로 분리할 이유가 충분하다. 동시성 코드는 다른 코드와 분리하라.

따름정리 : 자료범위를 제한하라(임계영역을 synchronized 키워드로 보호하라.)

자료를 캡슐화 하라. 공유 자료를 최대한 줄여라.

자료 사본을 사용하라. 스레드는 가능한 독립적으로 구현하라.

라이브러리를 이해하라

스레트 환경에 안전한 컬렉션을 사용한다.

executor 프레임워크를 사용한다.

java.util.current 패키지는 스레드에 안전한 구조다.

동기화 하는 부분을 작게 만들어라

깔끔하게 종료하는 다중스레드 코드를 짜야한다면 올라보 구현하길 바란다.

스레드 코드 테스트 하기 : 충분한 테스트는 위험을 낮춘다. 자주 돌려라. 테스트가 실해하면 원인을 추적하다.

시스템실패를 '일회성'이라 치부하지 마라

스레드 환경 밖에서 코드를 올바로 돌려라

흔들기 기법으로 오류를 찾아내라.

결론 : 각별히 깨끗하게 코드를 짜야한다.

14장 점진적인 개선

점신적으로 개선하다 : TDD는 시스템을 망가뜨리는 변경을 허용하지 않는다.

결론 : 코드는 언제나 최대한 깔끔하고 단순하게 정리하자.