의사결정을 최적화 하라

velog 블로그에서 tistory로 이전한 데이터 입니다.

들어가기 전,

Clean Code 11장 시스템을 읽으면서 중요하다고 생각하는 점을 적어봅니다.

의사결정을 최적화 하라

1. EJB2에서 EJB3로 넘어오면서 많은 게 바뀌었다고 생각한다.

   요즘 Spring을 개발할 때, EJB3 형태로 XML 설정과 Annotation을 이용해 손쉽게 개발하느라 이전의 형태를 보고 많이 놀랬다. 이전코드에서 TDD를 실천해온 개발자들이 정말 대단하다.
   EJB2때, 목적에 따라 코드를 수정해야 되는데 테스트 케이스를 작성한다면 모든 코드를 건드리게 된다. 위험성이 높다.

2. 소프트웨어를 개발할 때, BDUF(Big Design Up Front)를 추구 하지말자.

   오히려 아키텍처의 틀을 정해버리는 행동으로 향후 지속적인 발전이 어려울 수 있다.

3. 명백한 가치가 있을 때 표준을 현명하게 사용하라

업계에서 여러 형태로 아주 과장되게 포장된 표준에 집착하는 바람에 고객 가치가 뒷전으로 밀려난 사례가 있다.

 _"표준을 사용하면 아이디어와 컴포넌트를 재사용하기 쉽고, 적절한 경험을 가진 사람을 구하기 쉬우며, 좋은 아이디어를 캡슐화하기 쉽고, 컴포넌트를 엮기 쉽다. 하지만 때로는 표준을 만드는 시간이 너무 오래 걸려 업계가 기다리지 못한다. 어떤 표준은 원래 표준을 제정한 목적을 잊어버리기도 한다."_

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

DSL(Domain Specific Language)은 간단한 스크립트 언어나 표준언어로 구현한 API다.

좋은 DSL은 도메인 개념과 그 개념을 구현한 코드 사이에 존재하는 '의사소통의 간극'을 줄여준다.

JetBrain DSL
Banksalad Product Language를 소개합니다 를 읽고 도메인 특화 언어에 대한 좋은 예시인 것 같다.
디자이너와 개발자가 같은 생각, 원칙으로 손쉽게 개발할 수 있다는 점이 멋있다.

도메인 논리를 구현하면 도메일을 잘못 구현할 가능성도 줄어들 뿐만아니라 같은 개념(Thinking)을 가지고 문제를 해결할 수 있다.

결론

시스템은 깨끗해야 한다. 도메인 논리가 흐려지면 제품 품질이 떨어진다. 버그도 숨어들기 쉽고, 스토리를 구현하기 어렵다.

모든 추상화 단계에서 의도는 명확하게 표현하자. POJO(순수한 객체)를 만들어서 적절히 분리하자.