TIL (Today I Learned)

2022.05.19

오늘 읽은 범위

11. 시스템

---

책에서 기억하고 싶은 내용을 써보세요.

• 시스템 제작과 시스템 사용을 분리하라 (p.194) SW는 준비 과정과 런타임으로 로직을 분리해야 한다.
  • 준비 과정: 애플리케이션 객체를 제작하고 의존성을 서로 ‘연결’ 하는 로직
  • 런타임: 준비 과정 이후에 이어지는 로직

• 관심사 분리

• 초기화 지연Lazy Initialization (계산 지연Lazy Evaluation) 기법

  1. 실제로 필요할 때까지 객체를 생성하지 않으므로 불필요한 부하가 걸리지 않는다.
  2. 애플리케이션을 시작하는 시간이 그만큼 빨라진다.
  3. 어떤 경우에도 null 포인터를 반환하지 않는다.

• Main 분리

  • 생성과 관련한 코드: main이나 main이 호출하는 모듈로 이동.
  • 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정.

    

    애플리케이션은 main이나 객체가 생성되는 과정을 전혀 모른다.

• 팩토리
  • 때로는 객체가 생성되는 시점을 애플리케이션이 결정할 필요 有.
  • 생성시점은 결정가능하나, 생성하는 코드는 애플리케이션이 알 수 없음.

    

• 의존성 주입 (DI, Dependency Injection)
  • 제어역전) 한 객체가 맡은 보조 책임 → 새로운 객체에게 전적으로 떠넘긴다. (SRP 지켜짐)
  • 의존성 관리) 맥락에서 객체는의존성 자체를 인스턴스로 만드는 책임은 지지 않는다. 대신에 이런 책임을 다른 ‘전담’ 메커니즘에 넘겨야만 한다.
• 확장
  • 성장할지 모른다는 기대로 비용을 정당화할 수 있을까? → NO.
  • ‘처음부터 올바르게’ 시스템을 만들 수 있다는 믿음은 미신이다.

    오늘 주어진 사용자 스토리에 맞춰 시스템을 구현해야 한다. 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다.
    ⇒ 이것이 반복적이고 점진적인 애자일 방식의 핵심.

  • 시스템 아키텍처는 사전 계획이 필요하지 않을까. → ‘단순한 아키텍처를 복잡한 아키텍처로 조금씩 키울 수 없다’는 맞는 말 아닌가? NO. → 시스템은 수명이 짧아, 점진적으로 발전할 수 있다. YES.
    

• 자바 프록시

  • 단순한 상황에 적합
  • ex. 개별 객체나 클래스에서 메서드 호출을 감싸는 경우
  • 단점1) 코드가 상당히 많고 복잡함. → 깨끗한 코드 작성 어려움
  • 단점2) 시스템 단위로 실행 ‘지점’을 명시하는 메커니즘도 제공하지 않음. (AOP 위반)

• POJO 장점

  • (엔터프라이즈)프레임워크 & 도메인에 의존하지 않음.
  • 테스트가 개념적으로 더 쉽고 간단.
  • 상대적으로 단순하기 때문에 사용자 스토리 구현 쉬움.
    → 미래 스토리에 맞춰 코드를 보수하고 개선하기 편리.

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

• BDUF (Big Design Up Front) → Not GOOD.

  • 정의) 구현을 시작하기 전에 앞으로 벌어질 모든 사항을 설계하는 기법.
  • 단점) 처음에 쏟아 부은 노력을 버리지 않으려는 심리적 저항으로 인해, 그리고 처음 선택한 아키텍처가 향후 사고 방식에 미치는 영향으로 인해, 변경을 쉽사리 수용하지 못함.

• ‘아주 단순하면서도’ 멋지게 분리된 아키텍처로 소프트웨어 프로젝트를 진행해 결과물을 재빨리 출시한 후, 기반 구조를 추가하며 조금씩 확장해 나가도 괜찮다.

• 프로젝트를 시작시 생각할 것

  • 일반적인 범위,
  • 목표, 일정
  • 결과로 내놓을 시스템의 일반적인 구조도
  • 변하는 환경에 대처해 진로를 변경할 능력도 반드시 유지.

• 의사 결정을 최적화하라

• 때때로 가능한 마지막 순간까지 결정을 미루는 방법이 최선이다.

  • 최대한 정보를 모아 최선의 결정. / 성급한 결정은 불충분한 지식으로 내린 결정
  • 너무 일찍 결정하면 고객 피드백을 더 모으고, 프로젝트를 더 고민하고, 구현 방안을 더 탐험할 기회가 사라진다.

• 관심사를 모듈로 분리한 POJO 시스템은 기민함을 제공한다.

  • 기민성, 기민함 in 시스템 p.211) 최신 정보에 기반해 최선의 시점에 최적의 결정을 내리기가 쉬움. and 결정의 복잡성도 줄어든다. p. 213) 기민성이 떨어지면, 생산성이 낮아져 TDD 제공하는 장점이 사라진다.
    

• 시스템은 도메인 특화 언어가 필요하다.

  • 추상화 수준을 코드 관용구나 디자인 패턴 이상으로 끌어올린다.
  • 개발자가 적절한 추상화 수준에서 코드 의도를 표현.

---

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

• Java 관련 배경지식이 이 챕터를 이해하기에는 너-무 부족했었다. 모르는 것들 검색하면서 읽는시간 절반이상 쓴 것 같다. (휴.. 🤷‍♀️) 그중에서도 관점이라는 개념이 잘 와닿지 않아서 애먹었는데, 이해 될까 하다가도 뒤돌면 다시 까먹는것 같다.. 😹

• 이번 주 읽은 부분에서는 기민성, 지엽적, 창발.. 라는 단어가 나왔었는데, IT랑 전혀 상관없는 단어가 오히려 더 이해가 안됬다. 개발 공부하려면 국어공부도 같이 해야되나보다. (0개국어설..)
  

---

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• 자바 생명주기
  https://minnnne.tistory.com/110

• XML 배포기술자 (deployment descriptors)
  • 책) 영구 저장소에서 객체와 관계형 자료가 매핑되는 방식, 원하는 트랜택션 동작방식, 보안 제약조건이 들어감..
  • 스프링 옛날 버전(스프링 부트 안 쓸 때) 배포를 어떤식으로 되게 할 건지 정의하는 거

• 엔티티 빈
  • 데이터베이스로 부터 읽어드린 테이블의 데이터를 담는 빈
    Entity Bean

• InvocationHandler
  • 프록시 패턴으로 구현할 때 쓰는거.

• POJO (Plain Old Java Object)
  

• 프록시
  • 원래 로직을 유지하면서 뭔가 더 공통적인 처리를 추가하는 방식.
    (↓ 내가 이해 하려고 첨부한 초간단 예제 코드 )
    

• 관점 지향 프로그래밍 AOP, Aspect-Oriented Programming

  
  횡단관심: 로깅, 보안, 트랜잭션 등등 다수의 모듈에서 반복적으로 나타나는 부분.

  참고: https://expert0226.tistory.com/200 [여름나라겨울이야기]

• 관심사 분리 (SOC, separation of concerns)

  • 관심사: 컴퓨터 프로그램 코드에 영향을 미치는 정보의 집합.
  • Easy.ver) 프로그램을 기능 면에서 되도록 중복이 아닌 여러 모듈로 명확히 나누는 것.
  • 모듈식 (== 관심사의 분리)는 정보를 잘 정의된 인터페이스가 있는 코드 부분 안에 캡슐화시킴으로써 달성함.

• 기민성, 기민함 in 시스템

  • p.211) 최신 정보에 기반해 최선의 시점에 최적의 결정을 내리기가 쉬워진다. 또한 결정의 복잡성도 줄어든다.
  • p. 213) 기민성이 떨어지면, 생산성이 낮아져 TDD 제공하는 장점이 사라진다.

• 지엽적인 관리
  : 소스코드 중에서 비즈니스 로직 상 중요한 거랑 아닌거랑 나뉘는거.