지속 가능한 소프트웨어 아키텍처

시간이 지남에 따라 유지 관리는 구조적 프로그래밍에서 방어적 프로그래밍으로 변경되는 경우가 많습니다. 장기적으로 이러한 하락세에 대응하기 위해서는 가능한 한 기술 부채가 적은 고품질의 유연한 아키텍처가 필요합니다.

거의 모든 소프트웨어 시스템은 좋은 의도로 개발되지만 어려운 조건에서 개발됩니다. 개발자는 프로그래밍 해킹을 강요하는 기한과 씨름해야 합니다. 서로 다른 품질의 코드 공유로 이어지는 개발 팀에는 서로 다른 자격이 있습니다. 또한 팀은 지저분하고 얽혀 큰 진흙 덩어리가 된 오래된 코드를 처리해야 합니다.

시간이 지남에 따라 유지 관리는 구조화된 프로그래밍에서 방어적 프로그래밍으로 점점 더 많이 변화하고 있습니다. 개발자는 아키텍처 관점에서 볼 때 좋지 않다는 것을 알고 있는 코드를 작성하기 시작합니다. 코드는 더 복잡해지고 팀은 기술적 부채를 축적합니다. 유지 보수 비용이 증가하고 개선으로 인해 더 많은 부작용이 발생합니다. 그 결과 개발 비용을 증가시키는 열악한 아키텍처가 발생합니다.

장기적으로 이러한 악순환에 대응하기 위해서는 기술적 부채가 가능한 한 적은 고품질의 유연한 아키텍처가 필요합니다. 기술 부채가 낮으면 유지 관리 개발자가 시스템을 쉽게 찾을 수 있습니다. 빠르고 쉽게 버그를 수정할 수 있으며 비용 효율적인 확장을 만드는 데 문제가 없습니다. 기술 부채가 감소한 이 약속된 아키텍처의 땅에 어떻게 들어갈 수 있습니까?

기술적 부채

기술 부채라는 용어는 Ward Cunningham이 1992년에 처음 사용했습니다[1]. 기술적 부채는 의식적 또는 무의식적으로 잘못되거나 최적이 아닌 기술적 결정이 내려질 때 발생합니다. 이러한 잘못되거나 최적이 아닌 결정은 나중에 추가 비용으로 이어져 유지 관리 및 확장 비용이 더 많이 듭니다. 잘못되었거나 최적이 아닌 결정을 내린 시점에 기술적 부채를 떠안게 되었으며, 결국 과도한 부채에 빠지지 않으려면 어느 시점에서 이자와 함께 이를 갚아야 합니다.

문헌에는 기술적 부채의 다양한 유형과 변형이 나열되어 있습니다. 이 기사는 소프트웨어 개발자의 작업 속도를 늦추는 기술적 부채에 초점을 맞춥니다.

• 구현 부채: 소스 코드에는 코드를 구현하는 데 사용할 수 있는 긴 메서드, 빈 catch 블록 등과 같은 소위 코드 냄새가 포함되어 있습니다. 오늘날 구현 부채는 소스 코드의 여러 도구를 사용하여 대부분 자동화된 것으로 볼 수 있습니다. 모든 개발 팀은 추가 예산 없이 일상 업무에서 이러한 부채를 연속적으로 제거해야 합니다.
• 디자인 및 아키텍처 부채: 클래스, 패키지, 하위 시스템, 계층 및 모듈의 디자인과 이들 간의 종속성은 일관성이 없고 복잡하며 계획된 아키텍처와 맞지 않습니다. 이 부채는 단순한 계산 및 측정으로 결정할 수 없으며 포괄적인 분석이 필요하며 이는 섹션 3에 제시되어 있습니다.

누락된 문서, 낮은 테스트 범위, 열악한 사용성 또는 불충분한 하드웨어와 같은 소프트웨어 프로젝트의 부채로 간주될 수 있는 다른 문제 영역은 여기에서 제외됩니다.

기술 부채의 기원

소프트웨어 개발 프로젝트 초기에 고품질 아키텍처가 설계되었다면 소프트웨어 시스템이 처음부터 유지 관리하기 쉽다고 가정할 수 있습니다. 이 초기 단계에서 소프트웨어 시스템은 지속적인 유지 관리 노력으로 낮은 기술 부채의 복도에 있습니다(그림 1).

그림 1: 기술 부채의 영향

시스템이 점점 더 확장되면 필연적으로 기술 부채가 발생합니다(그림 1의 일정 비용 회랑에서 노란색 화살표). 소프트웨어 개발은 솔루션의 첫 번째 던지기가 최종 솔루션이 되는 경우가 거의 없는 지속적인 학습 프로세스입니다. 아키텍처 개정(아키텍처 갱신, 그림 1의 녹색 화살표)은 정기적으로 수행해야 합니다. 그 결과 지속적인 확장 및 리팩토링 시퀀스가 발생합니다.

팀이 이러한 확장 및 리팩토링 주기를 영구적으로 따를 수 있다면 시스템은 낮은 기술 부채 범위(유지 관리 범위의 그림 1에서 노란색 및 녹색 화살표)에 남아 있게 됩니다. 개발팀이 기술 부채를 지속적으로 줄이는 것이 허용되지 않으면 시간이 지남에 따라 필연적으로 아키텍처 침식이 발생합니다(그림 1의 노란색 및 빨간색 오름차순 화살표).

기술적 부채가 누적되면 소프트웨어 유지 관리 및 업그레이드 비용이 점점 더 많이 들고 결과적인 오류를 추적하기가 점점 더 어려워져 모든 변경 사항이 고통스러운 노력이 됩니다. 그림 1은 빨간색 화살표가 점점 짧아짐에 따라 이러한 느린 감소를 보여줍니다. 부채가 늘어남에 따라 시간 단위당 구현되는 기능이 점점 줄어들고 있습니다.

애초에 이 딜레마에 빠지지 않으려면 한편으로는 고품질의 유연한 아키텍처를 구성하는 요소에 대한 개발 팀의 지식과 다른 한편으로는 개발 방법에 대한 지식이 필요합니다. 이 아키텍처의 보존.

다음 항목도 참조: "배포 이후에 발생할 일에 대해서는 아무도 생각하지 않습니다."

지속 가능한 소프트웨어 아키텍처의 기반이 되는 인지 심리학

진화 과정에서 인간의 뇌는 복잡한 구조를 다루는 데 도움이 되는 몇 가지 인상적인 메커니즘을 습득했습니다. 이러한 메커니즘은 유지 관리 및 확장이 많은 오류 없이 신속하게 수행될 수 있도록 소프트웨어 시스템에서 사용되어야 합니다. 우리의 목표는 개발 팀이 바뀌어도 동일한 품질을 유지하면서 오랫동안 소프트웨어 시스템을 개발할 수 있는 것입니다. 복잡한 구조에 대해 우리 뇌가 개발한 세 가지 메커니즘은(그림 2) 청킹, 계층 구조 형성 및 스키마 구조입니다. 이러한 메커니즘은 아키텍처의 기준에 직접적인 이미지가 있습니다.

그림 2: 인지 메커니즘과 아키텍처의 매핑

이러한 메커니즘과 아키텍처에서의 구현이 개발 팀에 명확하다면 고품질 아키텍처를 위한 중요한 기반이 마련됩니다. 모듈성, 계층화 및 패턴 일관성의 구현에 대한 자세한 내용은 d.punkt-Verlag [2]에서 출판한 "Sustainable Software Architecture, Analyze and Reduce Technical Debt" 저서에서 찾을 수 있습니다.

아키텍처 품질을 위한 방법으로서의 몹 아키텍처

이러한 높은 수준의 아키텍처를 유지하기 위해 개발 팀은 지속적으로 아키텍처 개선 작업을 수행해야 합니다. 아키텍처에서 이 작업을 지원하는 좋은 방법은 mob 설계입니다. 모브 아키텍팅을 이용하면 계획한 아키텍처가 소스코드에 어느 정도 구현되었는지(그림 3), 소프트웨어 교육 수준이 어느 정도인지 소스코드에서 직접 확인할 수 있다. 대상 아키텍처는 설계자와 개발자의 마음에 있거나 종이에 존재하는 아키텍처에 대한 계획입니다. Lattix, Sotograph/SotoArc, Sonargraph, Structure101 등의 대상/실제 비교를 위해 몇 가지 유용한 도구를 사용할 수 있습니다.

그림 3: 대상 아키텍처와 실제 아키텍처 비교

그림 4는 몹 설계 프로세스를 보여줍니다. Mob 설계는 워크샵에서 시스템의 모든 설계자 및 개발자와 함께 파일럿에 의해 수행됩니다. 워크숍 시작 시 시스템의 소스 코드를 분석 도구(1)로 파싱하고 실제 아키텍처를 캡처합니다.

이를 통해 기술 부채가 가시화되고 파일럿은 개발 팀과 함께 리팩토링(3)을 통해 실제 아키텍처를 대상 아키텍처에 적용할 수 있는 방법에 대한 간단한 솔루션을 찾기 시작합니다. 또는 파일럿 및 개발 팀은 토론 중에 소스 코드에서 선택한 솔루션이 원래 계획보다 낫다는 것을 발견할 수 있습니다. 그러나 때로는 대상 아키텍처나 편차가 있는 실제 아키텍처가 최상의 솔루션이 아니며 파일럿 및 개발 팀이 아키텍처에 대한 새로운 대상 이미지를 공동으로 설계해야 합니다.

그림 4: 개발 팀과 함께 하는 Mob 설계

시스템이 대규모 확장에 직면한 경우가 이에 해당합니다. 계획된 아키텍처는 향후 확장을 위해 설계되지 않았으므로 아키텍처의 근본적인 추가 개발이 필요합니다. 이를 수행하는 방법과 같은 질문에 대한 답변이 제공됩니다. 기존 아키텍처가 확장에 충분히 유연합니까? 구조 조정을 허용하기 위해 일부 위치에서 결합을 줄여야 합니까? 새 모듈을 새 기능과 일관되게 통합하기 위해 모듈 및 계층의 컷이 올바르게 선택되었습니까? 공동 개발하지 않은 소프트웨어 시스템을 채택한 경우 먼저 시스템을 파악하기 위해 심층적인 아키텍처 분석이 필요합니다. 소스 코드 기반이 개발 팀에 알려지지 않은 경우 원래 계획된 구조는 이 방법으로만 표시될 수 있습니다.

이러한 아키텍처 분석 과정에서 파일럿과 개발 팀은 기술 부채 및 가능한 리팩토링을 수집합니다(4). 함께 리팩토링의 우선 순위가 지정되고 구현이 계획됩니다.

요약

이 기사에서는 개발 팀이 아키텍처를 양호한 상태로 유지하기 위해 알아야 하고 수행할 수 있는 사항에 대해 매우 간략하게 설명했습니다. 한편으로 개발 팀은 모듈식, 계층적, 패턴 일치 아키텍처가 무엇인지 알아야 합니다. 이러한 기본 개념은 계획(대상 아키텍처)과 최종적으로 소스 코드에 반영됩니다. 개발 및 유지 관리 과정에서 개발 팀은 대상 아키텍처와 실제 아키텍처 간의 차이점을 확인하고 필요한 경우 리팩토링을 수행하기 위해 mob 설계를 사용할 수 있어야 합니다. 이 두 가지 측면을 마음에 새기고 팀에 필요한 리소스가 제공된다면 모든 소프트웨어 시스템은 지속 가능하게 유지될 것입니다.

출처 : https://devm.io/software-architecture/sustainable-software-architecture-technical-debt-160372