잡소리1

DRY

Dont Repeat Yourself

 

OCP

Solid 전체가 OCP를 위한 하부원칙이라고도 볼 수 있다.

소프트웨어의 구성요소는 확장은 가능하지만 수정은 불가능해야한다.

기능을 추가하거나 현재 개체의 변경은 가능해야한다.

단 어떤 개체를 수정할 때, 다른 모듈이 영향받지 않도록 하라. (인터페이스를 수정하려고 하지마라)

 

아키텍처를 이야기할 때에는, 관심사의 분리(Separation of Concerns) 라는 용어를 자주 듣게 된다.

결국 아키텍처를 사용하는 이유는 서로 다르고 관련이 없는 책임(Responsibility)를 분리하는 것이다.

 

💭 컴퓨터는 이벤트를 처리하는 도구이다.

사용자의 이벤트를 안전하게 처리하기 위해서 트랜잭션 단위로 구분 짓게 된다.

즉 우리가 만드는 어플리케이션은 컴퓨터로 여러 트랜잭션(이벤트)를 처리하는 스크립트의 모음이다.

 

💭 아키텍처의 역사

오늘날 우리는 다중 계층 아키텍처 (Multi-Layer Architecture)를 당연하게 사용한다.

구조나 이름은 다 다르지만 결국 큰 그림으로 보면 [표현 - 비즈니스 - 데이터] 3계층으로 나누는게 제일 흔하다.

이 구조를 사용하는 Web Service를 예시로 들면
1. 사용자가 Client (웹 브라우저)의 UI로 이벤트를 발생시키면, Client는 웹 서버로 요청을 전송함.
2. 웹 서버는 브라우저의 요청을 받고, 올바른 요청인지 검증한 후 [비즈니스 로직]을 호출함
3. [비즈니스 로직]은 데이터를 조작하고, 필요에 따라 [데이터 접근 계층]에서 데이터를 요청하거나 저장함.
4. 처리가 완료되면 [프레젠테이션 계층]에 결과 값을 전달하고, 다시 웹 브라우저에게 반환함.
5. 웹 브라우저는 서버의 처리결과에 따라 사용자에게 요청한 화면을 보여주거나, 오류 메시지를 보여줌.

 

1. 당연히 최초의 컴퓨터는 아키텍처라는 개념이 없었다.

그냥 중앙집중 처리방식.

일괄 처리 시스템(Batch)을 구축해서 사용자의 요청작업 (그 당시 천공카드)를 모아놔서 일정시간마다 한번에 계산하는 방식이었다. 이는 사용자 입장에서 요청이 밀려있다면 내 결과를 확인하기까지 5~6시간이 걸리는게 당연했었다.

 

2. 당연히 이 방식은 비효율적이었다. 새로운 모델이 필요했다.

이후 시대가 발전하며 개인용 컴퓨터(PC), 서버용 워크스테이션이 등장하자 시스템 개발자들은 '서버에서만 모든 연산을 처리하고 결과값을 제공'하는게 아니라, 사용자 장비에서도 연산이 가능하도록 시스템을 구축했었다. 이게 바로 그 유명한 Client-Server 모델의 시초.

1980~90년에 유행했던 모델이다.

3. Client-Server는 매우 큰 단점이 있었다.

사용자 인터페이스(UI)와 비즈니스 로직에 대한 구분이 거의 없었다. 때론 사용자 PC(Client 코드)안에 로직이 포함된 상태로 존재하기도 했었다. 이는 개발을 진행하면서 코드가 정말 난잡하게 만들어졌었다.

JSP를 떠올리면 될 것 같다. 실제 어느 회사의 JSP 파일의 코드가 수천줄이라 제작자말고는 아무도 못건드렸다는 레거시 전설이..

2000년대 웹서비스는 개발 시 '화면 단위'로 작업을 나누는게 일반적이 었다. 이는 옛날의 Client - Server 단일 구조의 개발 방식이었다. 이 방법은 한 개발자가 너무 많은 관심사를 가지게 되고, 분업이나 유지보수도 매우 어려웠었다.

 

 

4. 이렇게 고통을 받다보니, 역할별로 영역을 분리하는게 중요하다는걸 깨달았다.

각 역할을 확실하게 분리하기 위해서 Cilent-Server 사이에 여러 계층(미들 웨어)를 끼워넣었다. 즉 [비즈니스를 담당하는 App Server] [DB를 담당하는 코드]를 사용하기 시작했었다.

[표현 계층 - 비즈니스 계층 - 데이터 접근계층] Tier 단위의 개발

이렇게 계층을 확실하게 나누니 유지보수가 쉬워지는 것도 있지만, 아래와 같은 특징도 있었다.

• 클라이언트와 비즈니스 로직이 확실하게 분리가 되다보니 각자가 맡은 부분만 분담, 집중해서 개발할 수 있었다.
   ➡ 관심사가 분리되었다. UI 개발자는 비즈니스 로직에 대한 고민을 하지 않아도 된다.
• 반복적으로 사용되는 같은 구조를 보일러 플레이트로 만들어 서비스를 빠르게 양산할 수 있었다.

 

5. 그런데 영역을 나누니 시야가 좁아지게 된다.

확실하게 분업을 하다보니 개발 효율은 매우 좋아졌고, 유지보수도 쉬워졌다.

하지만 이로인해 생긴 단점이 하나있는데, [기획자 - 개발자 - 그 외 팀원들]이 같은 시야를 공유하기 어려워진 것이다.

연통 배관처럼, 각 서비스마다 분리된 트랜잭션으로 처리

모든 서비스가 위 그림과 같다면, 팀원들이 같은 시야를 가질 필요가 없다.

그냥 공장에서 부품을 찍어내듯이 본인이 할 일만 잘한다면, 서비스는 잘 돌아갈 것이다.

 

하지만 현실적인 앱은 그렇게 동작하지 않는다. 여러 객체들이 협업하고, 여러 DB에 요청을 한다.

[ 우리가 무엇을 만드는가] 에 대한 이해가 없는 개발은, 서비스를 만들어나가는데 큰 걸림돌이 되었다.

이게 건물을 짓는 건지 통로를 만드는 건지 모르고 그냥 무작정 땅에다 삽질하는 것과 같았다.

 

옛날의 Client-Server 구닥다리 방식은 개발 효율은 나빴지만, 적어도 모든 팀원이 공통된 서비스에 대한 이해가 있었다. 하지만 지금은 그렇지 않다. 분업은 쉽게 가능하지만 내가 무엇을 만드는지에 대한 이해가 어려워졌다.

 

 

💭 스마트 DAO, 데이터베이스에 의존하는 개발

기존의 DAO는 단순히 데이터베이스에게 위임하는 간단한 역할만 맡았었다.

그래서 실제 비즈니스 로직들은 아래 SQL문안에 녹아 들게 된다.

SELECT username, secword
    FROM user
    WHERE UID=1 AND birday > "20000101" AND gender='F' AND rate > 40 AND status='T';

UPDATE users
   SET rate = rate + 10
   WHERE UID=112 AND gender='F' AND rate > 40 AND status='T';

 

우리는 소프트웨어의 복잡도를 낮추기위해서, 객체지향이나 아래와 같은 여러 기술들을 배워왔었다.

• Abstraction (추상화)
• Encapsulation (캡슐화) & Information Hiding ( 정보 은닉)
• Modularization (모듈화)
• Seprataion of Concerns (관심사의 분리)
• Coupling and Cohesion (응집도와 결합도)
• Divide And Conquer (분할정복)

그러나 위와 같이 SQL에 모든 로직을 담아버리면, 방금 언급한 모든 개념들은 무용지물이 되어버린다.

SQL의 역할을 줄여야한다. 로직을 유지보수 가능한 객체지향적인 코드에서 처리해야한다.

• Active Record 또는 ORM
• Query Builder (JooQ, QueryDSL)
• Table Data Gateway

상태를 영속화 해야한다.

데이터베이스에 값을 저장하는게 단순한 SQL문이 였다면, 메모리에서 상태를 보관(영속화)해야 한다.

DB에 저장한다는 의미가 달라진다. 많은 상태 조작이 메모리에서 수행된다.

프로그래밍 언어의 복잡도를 관리하는 기능을 활용할 수 있다.

 

이는 이후 도메인 모델을 설명하면서 추가로 설명하겠다.

 

💭 뒤범벅 아키텍처

어플리케이션에 여러 로직이 너무 섞여있다.

메서드마다 [로그, 인증인가, 모니터링]등 반복적인 횡적인 관심사 로직은 객체지향적으로 분리하기 어렵다.

• 파이프 & 필터 패턴 (순서대로 나열하고, 파이프로 처리. 서블릿 필터)
• AOP

 

💭 긴 공개 메서드 (메서드 단위의 기능 분업)

메서드 단위의 리펙토링이 되어있지 않다. 메서드도 기능이 분화되어있어야 한다.

클래스에 공개메서드만 존재하고 각 메서드의 크기가 너무 길면 유지보수성이 떨어진다.

• 기능단위의 메서드 분리, 중복을 제거
• 단일 책임 원칙 위반
• 재사용 코드의 발견, 추상화의 기회

복잡한 기능은 메서드들의 협업으로 구현해야한다. 기능을 추상화하자.

아래의 StringCalculator 클래스를 예를 들어보자.

public class StringCalculator {

    public int calculate(String text) {
        if (text == null || text.length() == 0) {
            return 0;
        } else if (text.contains(",")) {
            String[] values = text.split(",");
            int sum = 0;
            for (String val : values) {
                sum += Integer.parseInt(val);
            }

            return sum;
        }

        return Integer.parseInt(text);
    }

}

동작에는 아무런 문제가 없다. 하지만 한 메서드에서 너무 많은 일을 하고 있고, 코드만으로 동작을 이해하기도 어렵다.

긴 메서드의 역할을 분리하고, 동작을 메서드의 조합으로 구현해야한다.

public class StringCalculator {

    public int calculate(String text) {
        if (isBlank(text)) {
            return 0;
        }

        String[] values = splitToken(text);
        return sum(toInt(values));
    }
}

이제 calculate가 무슨 동작을 하는지 알겠는가? isBlank -> split -> toInt -> sum

굳이 세부 메서드를 까보지않더라도, 동작을 충분히 유추할 수 있다. 마치 코드로 의사소통 하는 것 같다.

 

내부 구현을 전혀 모르더라도, 비즈니스 로직만으로 어떠한 동작을 하는지 한눈에 알 수 있다. 또한 각각의 메서드를 재사용하거나 확장하기도 용이하다. 예를 들어 만약 입력 문자열의 종류를 확장하고 싶다면 splitToken()만 수정하면 된다. 

public class StringCalculator {

    public int calculate(String text) {
        if (isBlank(text)) {
            return 0;
        }

        String[] values = splitToken(text);
        return sum(toInt(values));
    }

    private int sum(int[] values) {
        return Arrays.stream(values)
            .sum();
    }

    private int[] toInt(String[] values) {
        return Arrays.stream(values)
            .mapToInt(Integer::parseInt)
            .toArray();
    }

    private String[] splitToken(String text) {
        return text.split(",");
    }

    private boolean isBlank(String text) {
        return text == null || text.isEmpty();
    }

}

 

예제는 너무 심하게 나눈 것이 아닌가 걱정되기도 한다. 하지만 평소에 이러한 습관을 가지고 있어야 복잡한 비즈니스 로직을 만났을 때, 메서드를 나누는 습관이 들게 된다.

• Public 메서드는 추상화된 이야기(의도, 작업흐름)을 나타내라.
• Private 메서드는 이야기의 의미를 정의하라.
• 작게 만들고 한가지만 하라(SRP)
• 함수내 동일한 추상화 수준을 유지하라.
• 명령과 조회를 분리하고 서술적인 이름을 사용하라.
• 고차 함수를 이용해서 함수 수준으로 추상화하라 (람다식)

 

public String renderPage(PageData data, boolean isSuite) {
    ResultPage result = prepareResultPage(isSuite);

    if (isTestPage(data)) {
        result.includeSetup(data);
        result.includeTeardown(data);
    }

    return result.getHtml();
}

 

💭 클래스 추가 공포증

OCP를 잘 지켰다면 전혀 무섭지않다.

TDD에 대해서도 알아보자.

 

💭 무거운 서비스 정리

AOP를 이용해서 관심사를 분리하자

조합 메서드를 활용하고 DSL(도메인 정의 언어)를 개발하자

도메인 모델을 도입하자

큰 서비스를 작은 클래스로 분해하고 위임하자

높은 응집도를 가지고, 낮은 결합도를 갖도록 설계하자.