좋은 소프트웨어 아키텍처의 기준

능률

숙련된 프로그래머는 좋은 아키텍처와 나쁜 아키텍처를 쉽게 구분할 수 있지만 몇 마디로 설명하라는 요청을 받으면 그렇게 할 수 없을 것입니다. 좋은 아키텍처에 대한 단일 기준이나 단일 정의는 없습니다.

그러나 잘 생각해보면 좋은 아키텍처가 만족해야 할 여러 기준을 쓸 수 있다. 좋은 아키텍처는 무엇보다도 프로그램 개발 및 유지 관리 프로세스를 더 간단하고 효율적으로 만드는 논리적 아키텍처입니다.

프로그램의 아키텍처가 양호하면 작동 방식과 코드 작성 위치를 쉽게 이해할 수 있습니다. 잘 설계된 프로그램은 변경, 테스트, 디버그 및 개발이 더 쉽습니다. 똑똑한 사람들은 좋은 아키텍처에 대한 다음과 같은 기준을 공식화했습니다.

• 능률;
• 유연성;
• 확장성;
• 확장성
• 테스트 가능성;
• 코드 유지 보수성.

시스템 효율성. 물론 프로그램은 할당된 작업을 해결하고 다양한 조건에서 기능을 잘 수행해야 합니다. 모든 프로그램이 해야 할 일을 수행하는 것처럼 보이지만(작성된 경우) 종종 그렇지 않습니다.

자신이 주장하는 바를 수행하지 않는 프로그램을 지속적으로 보게 될 것입니다.

• Libre Office는 Microsoft Office를 완전히 대체합니다.
• Edge 브라우저는 모든 웹 표준을 지원합니다(실제로는 아님).
• 은행은 사용자의 개인 데이터 보안을 중요하게 생각합니다(실제로는 그렇지 않음).

그리고 아직 성능, 안정성, 시기 적절한 버그 수정 또는 알려진 취약점에 대한 정보 게시에 대해서는 다루지 않았습니다.

완벽한 사람은 없지만 프로그램은 기본 작업을 해결해야 합니다. 따라서 효율성 없이는 어디에도 없습니다.

유연성

제 생각에는 효율성보다 더 중요한 것은 유연성입니다. 모든 애플리케이션은 시간이 지남에 따라 변경되어야 합니다. 요구 사항이 변경되면 새로운 요구 사항이 추가됩니다. 기존 기능을 변경하는 것이 더 빠르고 편리할수록, 이로 인해 발생하는 문제와 오류가 적을수록 시스템 아키텍처가 더 유연해집니다 .

종종 초보 프로그래머/설계자는 현재 작업에 이상적인 아키텍처가 필요하다고 생각합니다. 아니요. 1년 후에 발표될 작업에 대한 이상적인 아키텍처가 필요합니다. 이미 미래의 작업을 알지 못하는 당신은 그것이 무엇인지 알아야 합니다.

항상 예상치 못한 일이 있기 때문에 예측하려고 시도하는 것은 의미가 없습니다. 그러나 그러한 작업이 나타날 것이라는 점을 고려해야 합니다. 따라서 개발 과정에서 어떻게 변경해야 하는지 측면에서 얻은 결과를 평가하십시오.

"현재 아키텍처 결정이 잘못된 것으로 판명되면 어떻게 됩니까?", "얼마나 많은 코드가 변경됩니까?" 시스템의 한 조각을 변경해도 다른 조각에 영향을 주지 않아야 합니다.

가능할 때마다 아키텍처 결정은 확정되어서는 안 되며 아키텍처 오류의 결과는 합리적으로 제한되어야 합니다. "훌륭한 아키텍처를 사용하면 주요 결정을 지연시킬 수 있으며"(Bob Martin) 실수의 "비용"을 최소화할 수 있습니다.

이러한 접근 방식 중 하나는 애플리케이션을 마이크로서비스로 분할하는 것입니다. 이미 존재하는 논리를 별도의 부분으로 나누기가 쉽습니다. 그러나 가장 큰 문제는 하나의 작은 기능을 구현하기 위해 한 번에 12개의 서비스를 변경하는 것입니다.

확장성

확장성은 프로젝트에 새로운 사람을 추가하여 개발 시간을 단축할 수 있는 능력입니다. 아키텍처는 많은 사람들이 동시에 프로그램에서 작업할 수 있도록 개발 프로세스를 병렬화할 수 있어야 합니다.

이 규칙은 자체적으로 수행되는 것처럼 보이지만 실제로는 모든 것이 정반대입니다. 프로젝트에 새로운 사람이 추가되면 개발 시간이 늘어나는 이유를 설명한 매우 인기 있는 책인 The Mythical Man-Month 도 있습니다 .

확장성

확장성은 핵심 구조를 손상시키지 않고 시스템에 새로운 기능과 엔터티를 추가할 수 있는 기능입니다. 초기 단계에서는 기본적이고 가장 필요한 기능만 시스템에 넣는 것이 좋습니다.

이것은 소위 YAGNI 원칙입니다. "당신은 그것을 필요로 하지 않을 것입니다." 동시에 아키텍처는 필요에 따라 추가 기능을 쉽게 늘릴 수 있어야 합니다. 따라서 가장 가능성이 높은 변경 사항을 도입하는 데 최소한의 노력이 필요했습니다.

시스템의 아키텍처가 유연하고 확장 가능해야 한다는 요구 사항(즉, 변경 및 진화 가능)은 매우 중요하여 "개방형/폐쇄형 원칙"이라는 별도의 원칙으로 공식화되기도 합니다 . Open-Closed 원칙은 5가지 SOLID 원칙 중 두 번째입니다. 소프트웨어 엔터티(클래스, 모듈, 함수)는 확장에는 열려 있어야 하지만 수정에는 닫혀 있어야 합니다 .

즉, 시스템의 기존 부분을 다시 작성하지 않고도 시스템의 동작을 변경하고 확장할 수 있어야 합니다 .

즉, 기존 코드를 변경할 필요 없이 새 코드(확장)를 작성하여 동작을 변경하고 새 기능을 추가하는 방식으로 응용 프로그램을 설계해야 합니다.

이 경우 새로운 요구 사항의 출현은 기존 논리의 수정을 수반하지 않지만 주로 확장하여 구현할 수 있습니다. 이 원칙은 "플러그인 아키텍처"(Plugin Architecture)의 기본입니다. 이를 달성할 수 있는 기술은 나중에 설명합니다.

서블릿과 필터를 기억하십니까? 실제로 서블릿을 사용하여 모든 동일한 논리를 구현할 수 있다면 필터가 필요하고 별도의 인터페이스가 필요한 이유는 무엇입니까?

다양한 서비스 기능을 별도의 계층으로 이동할 수 있게 한 것은 필터(서비스 서블릿) 개념의 발명이었습니다. 그리고 앞으로 필터의 동작을 변경할 때 서블릿을 변경할 필요가 없었습니다.

필터가 발명되기 전에는 요청을 리디렉션하는 역할을 하는 모든 서비스 논리가 서블릿 자체에 있었습니다. 그리고 종종 로직의 작은 변화 하나가 모든 서블릿을 검토하고 모든 서블릿에 다양한 변경을 가할 필요성으로 이어집니다.

테스트 가능성

Java 백엔드 개발자인 경우 서버 애플리케이션은 종종 일련의 메서드를 REST API로 노출합니다. 그리고 모든 방법이 의도한 대로 작동하는지 확인하려면 테스트를 거쳐야 합니다.

일반적으로 API 테스트 범위는 좋은 스타일입니다. 이를 통해 API가 의도한 바를 실제로 수행하는지 확인할 수 있습니다. 또한 더 중요한 것은 서버 로직을 변경하고 실수로 아무것도 손상시키지 않았는지 쉽게 확인할 수 있다는 것입니다 .

테스트 작성을 시작하자마자 개인 메서드, 강력한 결합, 정적 클래스 및 변수와 같은 대부분의 코드를 전혀 테스트할 수 없다는 것을 알게 될 것입니다.

"코드가 작동하는데 테스트가 필요한 이유는 무엇입니까?"라고 초보자가 묻습니다.

"테스트할 수 없는 작업 코드가 필요한 이유는 무엇입니까?"라고 전문가가 묻습니다.

테스트하기 쉬운 코드는 더 적은 버그를 포함하고 더 안정적입니다. 그러나 테스트는 코드 품질만 향상시키는 것이 아닙니다. 거의 모든 개발자는 결국 "좋은 테스트 용이성"의 요구 사항이 자동으로 좋은 디자인으로 이끄는 지침이 된다는 결론에 도달합니다.

이상적인 아키텍처라는 책에서 인용한 내용입니다: "클래스의 "테스트 가능성" 원칙을 좋은 클래스 디자인의 "리트머스 테스트"로 사용하십시오. 테스트 코드를 한 줄도 작성하지 않더라도 90년 안에 이 질문에 답하십시오. 사례의 %는 그의 디자인이 얼마나 좋은지 또는 "나쁜지"를 이해하는 데 도움이 될 것입니다."

TDD(Test-Driven Development)라고 하는 테스트를 기반으로 프로그램을 개발하는 전체 방법론이 있습니다. 이것은 물론 다른 극단입니다. 코드를 작성하기 전에 코드를 작성하십시오.

코드 유지보수성

일반적으로 많은 사람들이 프로그램에서 작업합니다. 일부는 떠나고 새로운 사람들이옵니다. IT 회사에서 프로그래머의 평균 근무 시간은 1년 반입니다. 따라서 5년 된 프로젝트에 온 경우 동료의 20%만이 처음부터 작업했습니다.

다른 사람이 작성한 프로그램을 유지하고 개발하는 것은 매우 어렵습니다. 프로그램이 이미 작성된 경우에도 계속 유지 관리해야 하는 경우가 많습니다. 오류를 수정하고 약간 수정합니다. 그리고 종종 이것은 작성에 참여하지 않은 사람들이 수행해야 합니다.

따라서 좋은 아키텍처는 새로운 사람들이 시스템을 비교적 쉽고 빠르게 이해할 수 있도록 해야 합니다 . 프로젝트는 다음과 같아야 합니다.

• 잘 구성되어 있습니다.
• 중복을 포함하지 마십시오.
• 형식이 잘 지정된 코드가 있어야 합니다.
• 문서를 포함하는 것이 바람직합니다.
• 프로그래머에게 표준적이고 친숙한 솔루션을 적용하는 것이 필요합니다.

작업 중인 프로젝트를 5점 척도로 쉽게 평가할 수 있습니다 . 이러한 요구 사항 각각에 대해 2점만 계산하십시오 . 그리고 5개 이상을 얻으면 운이 좋은 것입니다.

프로그래머는 최소한의 놀라움이라는 원칙 도 가지고 있습니다 . 시스템이 더 이색적일수록 다른 사람들이 이해하기 더 어렵습니다. 일반적으로 사용자 인터페이스와 관련하여 사용하지만 코드 작성에도 적용할 수 있습니다.