복잡성은 죽음이다.
도시를 세운다면
👉 소프트웨어 팀도 도시처럼! 시스템 수준에서도 깨끗함을 유지하는 방법을 알아보자.
- 도시가 돌아가는 또 다른 이유는 추상화와 모듈화 때문이다.
- 큰 그림을 이해하지 못할지라도 개인과 개인이 관리하는 구성요소는 효율적으로 돌아간다.
시스템 제작과 시스템 사용을 분리하라
👉 소프트웨어 시스템은 애플리케니션 객체를 제작하고 의존성을 서로 '연결'하는 준비과정과 이후 런타임 로직을 분리해야 한다. 분리 방법에 대해 알아보자.
- 제작은 사용과 다르다.
- 관심사 분리를 진행하라!
Main 분리
- 생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮기고 모든 의존성이 연결된 상태이다.
- 애플리케이션은 main이나 객체가 생성되는 과정을 모른다.
모든 화살표가 main → 애플리케이션
팩토리
- 때론 객체가 생성되는 시점을 애플리케이션이 결정할 필요도 있다.
- OrderProcessing 애플리케이션은 LineItem이 생성되는 구체적인 방법을 모른다.
main → OrderProcessing
의존성 주입
- 제어 역전 기법(IoC:Inversion of Control)을 의존성 관리에 적용한 메커니즘이다.
- 참고하기 https://pks424.tistory.com/entry/IoC-DI%EB%9E%80
확장
👉 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다.
- 애자일 방식의 핵심, 반복적 + 점진적
- 참고하기 https://www.redhat.com/ko/devops/what-is-agile-methodology
- 시스템 조정과 확장을 용이하게 한다.
- 횡단(cross-cutting) 관심사
EJB2아키텍쳐는 일부 영역에서 관심사를 거의 완벽하게 분리해냈다. 이는 AOP (관점 지향 프로그래밍)을 예견했다.- 영속성 프레임워크와 도메인 논리를 독자적을 모듈화할 수 있는데, 이 두 영역이 세밀하게 겹치는 부분이 생긴다.
자바 프록시
👉 프록시 사용, 주의하자!!
- 단순한 상황에 적합하다. EX) 개별 객체 / 클래스에서 메서드 호출을 감싸는 경우
- 프록시를 사용하면 깨끗한 코드를 작성하기 어렵다.
(시스템 단위로 실행 지점을 명시하는 메커니즘 제공 안함)
순수 자바 AOP 프레임워크
👉 프록시 코드는 대부분 도구로 자동화가 가능하다. 스프링 AOP, JBoss AOP 등은 내부적으로 프록시를 사용한다.
- 위는 스프링 V2.5 설정 파일 app.html 일부
- 애너테이션에 들어있는 영속성 정보는 필요하다면 XML 배치 기술자로 옮겨도 괜찮다. → 순수한 POJO만 남음
- 비교했을 땐
EJB3사용 추천
AspectJ 관점
👉 관심사를 관점으로 분리하는 가장 강력한 도구, AspectJ 언어
- AspectJ 란) 언어 차원에서 관점을 모듈화 구성으로 지원하는 자바 언어 확장
- 장점) 관점을 분리하는 강력하고 풍부한 도구 집합 제공
- 단점) 새 언어 문법과 사용법을 익혀야 함
- → 애너테이션 폼 추천
테스트 주도 시스템 아키텍처 구축
👉 코드 수준에서 아키텍쳐 관심사를 분리할 수 있다면, 진정한 테스트 주도 아키텍처 구축이 가능해진다.
- 그때 그때 새로운 기술을 채택해 키워나가는 것이 가능 단순한 아키텍처 → 복잡한 아키텍처
- BDUF(Big Design Up Font) 추구할 필요 ✕ 해로움!
- 단, 일반적인 범위, 목표, 일정, 결과를 내놓을 시스템의 일반적인 구조를 생각하는 것은 필수! 방향성을 찾지 못하는 것은 ✕
의사 결정을 최적화하라
👉 책임은 가장 적합한 사람에게, 최대한 정보를 모아 최선의 결정으로!
- 고객 피드백을 더 모으고, 프로젝트를 더 고민하고, 구현 방안을 더 탐험하라!!
명백한 가치가 있을 때 표준을 현명하게 사용하라
👉 표준이라는 이유만으로 이에 집착하는 것은 바람직하지 ✕
- 표준의 장점) 아이디어/컴포넌트 재사용 용이, 경험 충분, 캡슐화 용이, 컴포넌트 엮기에 용이
- 표준의 단점) 표준 제작 시간 딜레이, 제정 목적을 잃은 표준의 존재
시스템은 도메인 특화 언어가 필요하다
👉 최근들어 조명받기 시작한 DSL(Domain-Specific Language)을 사용하라! 장점은?
- 도메인 전문가가 작성한 구조적인 산문처럼 읽힌다.
- 도메인을 잘못 구현할 가능성이 줄어든다.
- 추상화 수준을 코드 관용구,디자인 패턴 이상으로 끌어 올린다.
- → 적절한 추상화 수준에서 코드 의도 표현 가능
결론
👉 시스템 역시 깨끗해야 한다.
- 생산성과 TDD의 장점과 연결되는 기민성을 떨어지지 않게 하라!
- 모든 추상화 단계에서 의도는 명확하게!
- 관점과 유사한 메커니즘으로 구현 관심사를 분리하라!
- 실제로 돌아가는 가장 단순한 수단을 사용하라!
인상 깊었던...
복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다.
나는 업계에서 여러 형태로 아주 과장되게 포장된 표준에 집착하는 바람에 고객 가치가 뒷전으로 밀려난 사례를 많이 봤다.
깨끗하지 못한 아키텍처는 도메인 논리를 흐리며 기민성을 떨어뜨린다.
노력하는 초보 개발자