책: 객체지향 시스템 디자인 원칙

개요

알라딘 링크: https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=366588715

페이스북의 책나눔 이벤트로 읽게 된 책이다(리뷰 이벤트 아님).

고수가 지식과 경험을 정리하여 나누는 책을 만나는 것은 언제나 즐겁다.

TL;DR

일독을 추천한다.

 

객체지향 디자인에 대한 책들을 읽어보았다 하더라도 새로나온 같은 주제의 책을 읽는 것은 무엇일까? 가장 최근의 생각을 들을 수 있고, 저자만의 지식과 경험에서 나온 관점에서 볼 수 있기 때문일 것이다.

 

이 책은 주니어 분들에게는 디자인에 대한 중요한 원칙을 접하게 해줄 것이고, 책과 실무에서 많은 경험을 한 분들에게는 위에서 언급한 대로 동시대의 뛰어난 개발자의 생각을 배우는 기회이자, 다시 한번 자신의 개념을 돌아보고 정리하는 도구가 될 것이다.

읽으면서 가장 매력적이었던 건 실제로 현업에서 애매했던 지점들을 콕 찍어주며 방향을 제시하는 순간들이었다. 훌륭한 책들에서 말해주던 것들 만으로는 판단과 결정을 하기 난감했던 순간들을 저자는 “이럴 때 있었지?” 하며 가이드 해준다.

 

보통의 책들은 30분에 25-30페이지를 읽는데 이 얇은 책은 뒤로 갈 수록 30분에 10페이지가 넘어가기 쉽지 않았다. 어렵기 때문이 아니라 책의 이야기를 현업에서의 기억들과 연결하여 숙성하려는 욕심 때문이었다. 학이불사즉망, 사이불학즉태.

 

이 책을 읽으며 자신의 사례가 떠오르면 레벨업, 현업에 책의 내용을 적용하면 성공, 마침내 익숙해지면 대성공이 될 것이다.

밑줄

“복잡성을 줄이거나 그대로 유지하기 위한 작업을 수행하지 않으면 소프트웨어 시스템을 시간이 지남에 따라 복잡성이 증가한다.” p25

• 매니 래만의 논문, 대규모 프로그램의 생명주기에서 법칙 진화 보존에 대해 이해하기(1984년)

디자인을 단순을 하려는 지속적인 노력은 양치질에 비유할 수 있다. 이런 노력은 특별히 재미있는 일은 아니지만, 향후 불편함과 큰 비용이 발생하는 문제를 피하기 위해 필요하다. p33

엔트로피가 떠올랐다. 아무 것도 하지 않아도 소프트웨어 시스템은 복잡해진다.

코드의 주석을 추가하는 첫 번째 이유는 코드 그 이상을 설명하기 위함이다. (중략) 주석을 선호하는 두 번째 이유는 코드를 더 작은 단위로 분리하면 오히려 가독성이 떨어질 수 있기 때문이다. p53

저자 마우리시오 아니체(Mauricio Aniche)의 주석에 대한 이 생각은 존 오스터하우트의 소프트웨어 설계 철학(John Ousterhout, A Philosophy of Software Design)에 영향을 받은 것으로 보인다. 존 오스터하우트와 이 책에 대한 언급이 종종 나온다. 클린 코드와 부딪히는 주장이다.

클래스나 메서드 책임이 무엇인가 결정하기 어려운 경우가 많다. 특히 개발 초기에는 더 그렇다. 이때 더 간단한 규칙은 코드 단위를 작게 만드는 것에 집중하는 것이다. p59

SOLID의 SRP를 지키면 좋은데 개발 초기에는 판단이 어렵다. 저자는 잘 모르겠으면 그냥 작게 만들라 말한다. 나중에 아니다 싶으면 합쳐서 응집력(cohesion)을 높이면 된다.

클라이언트는 절대 일관성 검사를 책임지지 말아야 하며 기본적으로 클래스가 일관성을 관리해야 한다. 만약 클래스에 들어가기에 검사가 너무 복잡하다면 전체 작업(일관성 검사 포함)을 서비스 클래스로 이동시키고 클라이언트가 원하는 동작을 위해 그 서비스 클래스를 사용해야 한다. p69

이 책에 대한 내 평가가 확 올라가는 부분이었다. DDD에서 일관성이 유지되어야 하는 단위를 애그리게이트라 하고, 그 애그리게이트에 접근하는 방법은 애그리게이트 루트를 통한다고 막연히만 기억했는데 그 근거와 이유를 여기서 확실히 이해하게 된 것이다.

일부 개발자는 이런 작업을 프레이모크가 숨겨줌으로써 더 복잡한 의존성 그래프를 만들게 된다고 생각한다. 클래스를 직접 수동으로 인스턴스와 해야 한다면 작업의 양을 눈으로 보고 의존성 그래프를 단순화하도록 코드를 다시 디자인할 것이라는 의견이다. (중략) 실제로 나는 더 간단한 애플리케이션에는 의존성 주입 프레임워크를 사용하지 않는다.p114

일부 개발자는 의존성 주입(DI) 프레임워크에 대한 거부감을 가질 수 있다는 말이다. 뜨끔하며 재미있었던 것이 바로 내가 그러했기 때문이다. 지금은 저자의 말에 공감한다. 단순한 애플리케이션이라면 의존성 주입 프레임워크는 과할 수 있지만 어느 정도 규모 이상이라면 사용하는 것이 좋다.

“추상적이라는 건 모호하다는 것과 본질적으로 다르다. 추상화의 목적은 모호해지는 것이 아니라 절대적으로 정확한 새로운 의미 수준을 만드는 것이다.” p118

컴퓨터과학계의 거인이었던 에츠허르 데이크스트라(Edsger Dijkstra)의 깨달음을 주는 말이다. C++의 창시자인 비야네 스트롭스트룹(Bjarne Stroustrup) 만큼이나 스펠링과 발음이 어려운 분이다.

좋은 추상화는 ‘무엇’과 ‘어떻게’를 분리한다. 다시 말해 좋은 추상화는 무엇을 해야 하는지에 초점을 맞추지만, 그것이 어떻게 수행되는지를 알지는 못한다. p121

좋은 추상화는 안정적일 가능성이 높다. 따라서 추상화에 결합되는 것은 큰 문제가 되지 않는다. p123

인터페이스가 그렇다. 인터페이스는 무엇을 할 수 있는지만 말한다.

안정적이라는 건 잘 변하지 않는다는 것이고, 변치 않는다는 건 의지하고 결합할 수 있다는 것이다. 변치않는 마음의 상대를 만나면 결혼하고 싶어지는 거다.

파일 접근 로직과 비즈니스 로직이 함께 섞여 있는 경우는 흔하다. p142

개발자가 부주의하게 이 라이브러리 메서드를 비즈니스 로직 안에서 직접 호출할 수 있다. p142

정리하면 외부 시스템이 코드에 미치는 영향을 최소화하는 것을 목표로 해야 한다. p142

이러한 경험, 갈등의 순간들을 많이 경험했기에 무릎을 쳤다. 파일 접근 로직을 비즈니스 로직에 섞으면 당장 구현하기 편하다. 라이브러리를 직접 호출하면 편하다. 하지만 이들이 내가 소유하고 통제할 수 없는 녀석이라면 지양해야 한다.

디자인은 구현 변경의 영향을 최소화하기 위해 코드의 나머지 부분에서 인프라의 내부 세부 사항을 숨겨야 한다. 하지만 개발자에게 너무 많은 것을 숨기면 안된다. 개발자가 내부 동작을 이해해야 최적화되고 효율적인 코드를 작성할 수 있기 때문이다.p144

책에서는 개발자가 특정 기능을 호출할 때에 네트워크 너머로 원격 호출되는 걸 모르는 예시를 들었다. 개발자는 원격 호출에서 발생할 수 있는 상황들을 대비할 수 없을 것이다. 좋은 예시였다.

기대되는 비즈니스 결과에 초첨을 맞춘 도메인 중심 인터페이스를 생성하고, 구현 세부 사항을 추상화하면 특정 인프라 기능 사용과 관련된 많은 어려움을 완화할 수 있다. p149

클라우드 제공업체로 아마존 AWS를 선택했다면 AWS의 강력한 기능을 무시하지 않는다. 아마존 SQS(AWS 큐 서비스)를 적극 활용하며 SQS를 선호해 아키텍처적 결정을 내린다. 그렇지만 AWS 관련 코드를 어댑터로 캡슐화함으로써 코드 기반 전반에 AWS와 관련된 구체적 코드가 퍼지는 것을 방지한다. p155

MySQL에는 없는데 PostgreSQL에는 있는 기능을 사용하고 싶다면? 이러한 특정 데이터베이스(=인프라)의 기능에 초점을 맞추면 문제가 되기에, 이 기능을 사용하려 해결하려는 도메인의 문제에 중심을 둔 인터페이스를 생성해야 한다.

프레임워크 예외 클래스가 코드 기반 전체에 퍼지지 않도록 해야 한다. p158

예를 들어 PostgreSQL의 특정한 에러코드를 위쪽으로 계속 리턴하면 안되는 것이다. 그 에러코드를 내가 만든(=내가 소유한) 에러로 바꾸어 올려보내야 한다. 하지만, 개발자에게는 그 특정한 에러코드 정보가 필요하므로 이를 로그로 출력해두어야 한다.

이 부분이 좋았던 것은 실제 현업에서 바로 이렇게 판단하고 구현했던 경험이 있었기 때문이다.

엔터티 재사용도 이런 결합의 일반적인 원인이다. 예를 들어 다른 모듈이 Invoice 클래스를 구현했다면 이를 다시 구현하는 것보다는 재사용 하고 싶을 것이다. p174

또 한 번의 뜨끔. 실제로 이런적이 많았다.

존 오스터하우트의 책, <소프트웨어 디자인의 철학>에 따르면 어떤 것을 디자인할 때 세 번째 시도에서 가장 좋은 디자인 결정을 내린다고 한다. p184

같은 맥락의 이야기들이 많이 떠오른다. 하나를 오래 잡고 개선하는 것보다 여러번 다시 만들어보는게 좋다는 이야기. 하루에 작업을 마치지 못하면 모두 지우고 다음날 처음부터 다시 만든다는 이야기.