[클린코드]11.시스템

이번 장은 시스템 전반에 대해서 다루고 있어서, 깊은 내용을 다루지는 않았지만 기존에 알지 못하는 내용들이 있어서 많은 자료를 찾아가며 공부했다. 코드 단위를 넘어서 시스템 아키텍처의 내용 또한 중요하다는 사실을 알게 되었다.
《클린 아키텍처》 책도 가지고 있는데, 《클린코드》를 다 공부한 이후에 공부해봐야겠다.

📆TIL(Today I Learned) 날짜

2022.04.15

📑오늘 읽은 범위

11.클래스

✍🏻책에서 기억하고 싶은 내용

시스템 제작과 시스템 사용을 분리하라
제작(construction)은 사용(use)과 아주 다르다는 사실을 명심한다.
Main 분리 : 생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다.
팩토리 : 때로는 객체가 생성되는 시점을 애프리케이션이 결정할 필요도 생긴다. (…) 이 때는 ABSTRACT FACTORY 패턴을 사용한다.
의존성 주입 : 사용과 제작을 분리하는 강력한 메커니즘 하나가 의존성 주입(Dependency Injection, DI)이다. 의존성 주입은 제어 역전(Inversion of Control, IoC) 기법을 의존성 관리에 적용한 메커니즘이다.

확장 : ‘처음부터 올바르게’ 시스템을 만들 수 있다는 믿음은 미신이다. 대신에 우리는 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현해야 한다. 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다. 이것이 반복적이고 점진적인 애자일 방식의 핵심이다. 테스트 주도 개발(TDD), 리팩터링, (TDD와 리팩터링으로 얻어지는) 깨끗한 코드는 코드 수준에서 시스템을 조정하고 확장하기 쉽게 만든다.

횡단(cross-cutting) 관심사 : 핵심적인 기능이 아닌 중간중간에 삽입 되어야 할 기능(관심)들. ex) 로깅, 보안, 트랜젝션 처리 등

테스트 주도 시스템 아키텍처 구축 : 애플리케이션 도메인 논리를 POJO로 작성할 수 있다면, 즉 코드 수준에서 아키텍처 관심사를 분리할 수 있다면, 진정한 테스트 주도 아키텍처 구축이 가능해진다.

의사 결정을 최적화하라
우리는 때때로 가능한 마지막 순간까지 결정을 미루는 방법이 최선이라는 사실을 까먹곤 한다. 게으르거나 무책임해서가 아니다. 최대한 정보를 모아 최선의 결정을 내리기 위해서다. 성급한 결정은 불충분한 지식으로 내린 결정이다.

시스템을 설계하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자.

❓궁금한 내용, 잘 이해되지 않는 내용

• 팩토리(Factory)란? 팩토리는 “새로운 것”으로 가정되는 어떤 메서드를 호출부터 다양한 프로토타입이나 클래스의 객체를 반환하는 함수 또는 메서드다. 즉, 다른 객체를 만들기 위한 객체이다.
• 제어의 역전(Inversion of Control)이란? 오브젝트 생성, 관계 설정, 사용, 제거 등 오브젝트 전반에 걸친 모든 제어권을 애플리케이션이 갖는게 아니라 프레임워크의 컨테이너에게 넘기는 개념을 말한다.
  이는 객체지향 원칙을 잘 지키기 위해 필요하다. 객체를 관리해주는 프레임워크와 내가 구현하고자 하는 부분으로 역할과 관심을 분리해 응집도를 높이고, 결합도를 낮추며, 이에 따라 유연한 코드를 작성할 수 있는 구조가 될 수 있기 때문에 제어를 역전한 것이다.