2022-03-19 클린코드 11~14

11.

시스템 제작과 시스템 사용을 분리하라

관심사를 분리해야됨.

 

준비과정과 런타임 로직을 섞어버리면 테스트도 힘들고, 런타임 로직이 준비과정 로직에 의존성이 생겨버림.

 

의존성이 생기면 뭐가 안좋냐?

준비과정에서 쓰이는 객체를 사용 안하는 경우에도 의존성을 케어해줘야함

 

생성과 사용을 분리하는 여러 방법이 있는데

1. 메인 분리

생성은 main, main이 호출하는 모듈에서 처리함.

 

제어흐름

1. main 함수가 필요한 객체를 생성하고 앱에 넘김

2. 앱은 그냥 객체 사용만 함

 

main함수 -> 앱으로 의존성이 걸리며 앱은 객체 생성과정을 전혀 몰라도 됨.

 

팩토리

객체 생성 시점을 앱이 결정해야할 떄도 있음.

 

팩토리 메서드 패턴은 분기에 따른 객체의 생성을 팩토리라는 클래스에 위임하여 이 클래스가 대신 생성하도록 하는 방식임.

 

팩토리인 이유는 객체 찍어내는 공장이라는 의미.

https://victorydntmd.tistory.com/299

[디자인패턴] 팩토리 메서드 패턴 ( Factory Method Pattern )

https://victorydntmd.tistory.com/300

[디자인패턴] 추상 팩토리 패턴 ( Abstract Factory Pattern )

팩토리 같은 경우에도 의존성은 main -> 앱으로 유지되고 필요한 경우에는 앱에서만 사용하는 생성자 인수도 넘길수 있음.

 

사용과 제작 분리하는 강력한 메커니즘 중 하나가 의존성 주입임.

 

의존성 주입은 제어 역전 기법을 의존성 관리에 적용한 메커니즘

 

제어 역전 기법은?

메서드 객체 호출 작업을 개발자가 아니라 프레임워크가 필요할떄 갖다 쓰게 하는거

 

의존성 주입은

직접 객체 생성/제어하는게 아니라 특정 객체를 객체 외부에서 갖다 쓰는거

 

필자가 말하는 진정한 의존성 주입

클래스 의존성 해결 x, 클래스는 수동적

대신 setter 메서드, 생성자 메서드등을 제공.

 

확장

처음에 작게 만들고 나중에 크게 만들때 진작 크게 만들걸하는건 당연한 생각이지만 멍청한 생각임.

 

처음부터 올바르게 시스템 만드는건 될리가 없음.

 

건물같은 물리적인 것은 총 크기를 계산하는건 어쩔 수 없지만, 소프트웨어에서는 관심사를 정확히 분리한 작은 모듈들을 합쳐 확장하는 것이 불가능하지 않고, 좋음.

 

테스트 주도 시스템 아키텍쳐 구축

 

의사결정 최적화

가끔은 마지막 순간까지 결정을 미루는것이 최선일떄도 있음.

 

최대한의 정보를 모아 최선의 결정을 내리는게 불충분한 지식으로 성급히 결정하는것보다 훨씬 낫다.

 

표준을 현명히

단순히 표준이라서가 아니라 가치가 분명한 표준인지를 따져보자

 

시스템은 도메인 특화언어가 필요함

 

 

12. 창발성

창발성의 뜻은 하위 계층에 없는 특징들이 상위 계층에 자발적으로 나타는것

영어로는 emergent인듯?

 

여기서 말하는것은 아마 계층의 구분을 나누어 하위 계층에서 역할을 하면 그거 따라서 상위 계층에서 추가적인 일을 할 수 있는 그런 느낌인거 같다.

 

창발성을 촉진하는 우수하고 단순한 설계 규칙들

 

1. 모든 테스트 실행해야됨

테스트 가능한 시스템 = 검증 가능한 시스템

테스트를 작성하려면 자연스레 결합도가 낮은 코드를 짜야하고 설계 품질 UP

 

2. 리팩터링

코드 점진적으로 리팩터링하면서 좋은 코드를 만듦.

테스트 코드가 있으니 변화에 두렵지 않아요!

 

3.중복 NO

중복 = 추가 작업, 추가 위험, 불필요한 복잡도

 

4. 표현해요

의미적인 표현을 사용해서 이해하기 쉬운 코드를 짜면 유지비용이 줄어들고 결함도 덜함.

1. 좋은 이름

2.함수랑 클래스 크기 줄이기

3.표준 명칭 사용

4. 단위 테스트 케이스 꼼꼼히 작성

5. 노오력하기

 

5. 클래스와 메서드 수 최소로 줄이기

그전까지 단원에서 클래스와 메서드는 최대한 잘게 나누랬으면서 뭔 소린가 했더니 무의미한 규칙 때문에 의미없이 클래스와 메서드 수가 늘어나는 것은 막아야한다는 느낌인듯.

 

독단적인 견해는 멀리하고 실용적인 방식을 택하라는 말은 꼭 틀에 갇혀 코드를 짜지 말고 생각을 하란 의미같다.

 

13. 동시성

동시성은 효율적이고 꼭 필요한 상황들이 있음. 근데 동시성을 위한 코드는 복잡하고 오류 터질떄도 많음. 이것들을 잘 따져서 잘 작성해야함.

 

동시성 방어원칙

 

• 단일 책임 원칙.

동시성은 복잡성 하나만으로 따로 분리해야할 이유가 충분함. 분리하자.

 

• 자료 범위 제한

 

두 스레드가 서로 간섭하므로 의도치 않은 결과 내놓는 경우 많음. 코드의 임계 영역을 synchronized 키워드로 보호하라고 권장하는데 제일 베스트는 임계 영역을 줄여버리는거.

 

• 사본 사용하기

공유 자료를 사용하니까 문제가 생기는건데 아예 공유 안하고 사본을 쓰면 굿임. 문제는 객체 복사해서 사본 만드는 코스트인데 실측해볼 필요가 있음. 사본으로 동기화 피할수 있으면

lock 거는거 없애 줄인 시간 vs 사본생성 + 가비지 컬렉션에 드는 부하

상쇄할 가능성 큼.

 

• 스레드는 최대한 독립적으로

공유가 언제나 문제임

 

• 동기화하는 메서드사이 의존성 이해

동기화하는 메서드 사이에 의존성이 있으면 찾기 어려운 버그가 생김.

 

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

synchronized사용하면 lock하는데, 락 걸리면 스레드가 지연되고 부하가 가중됨.

 

• 올바른 종료 코드는 구현 어려움

시간을 투자해 꼼꼼히 올바르게 구현하기

 

• 스레드 코드 테스트하기

테스트가 정확성 보장하진 않는데 스레드는 특히 그럼.

말도 안되는 곳에서 에러 터지면 스레드 문제일 가능성이 높음.

 

먼저 순차코드 잘 작동하는지 보는게 우선이고,

 

• 스레드 개수 상황에 맞게 조율할 수 있도록 작성하고

 

• 다른 플랫폼에서 돌려보고

 

• 강제로 실패 일어나는 코드 작성해보고

 

14. 점진적 개선은 책의 코드를 보세요.

 

필자가 어떻게 점진적으로 코드를 고쳐나가는지 과정을 설명한거임