복잡한 IT 시스템에 대한 새로운 솔루션을 설계해야 합니다. 어떤 조치를 취하시겠습니까?
작업 계획을 시작하기 전에 최고의 리더와 전문가의 모범 사례를 이해하기 쉬운(최소한 부분적으로는) 다이어그램으로 연결해야 합니다.
아래 예제에서 항상 하나의 선두적인 요소를 찾아야 합니다. 이것은 전체 형식에 영향을 미치는 첫 번째 블록입니다.
소프트웨어 개발에서 저는 Gitlab 또는 GitHub와 마크다운 문서 형식을 이러한 블록으로 사용하는 것을 제안합니다. 한 곳에 있고 이를 사용하는 것이 좋습니다. 왜냐하면 문서는 프로젝트의 모든 것입니다(이것에 대해 더 자세히 논의하지는 않겠습니다).
문서의 노후화 원인은 다음과 같습니다.
- 문서가 작성되지 않습니다.
- 문서가 흩어져 있고 완전하고 최신 버전을 조각에서 모으기 어렵습니다.
이 두 가지 요인은 위에 설명된 스키마에서 통제됩니다.
일부 팀에서는 자체적으로 문서 방향에 기여하는 모든 직원이 문서를 개발하는 커뮤니티가 나타날 수 있습니다.
세 가지 힘이 병렬로 진행되어야 합니다. 이는 건축가, 전문가 및 프로젝트 감독관입니다.
전문가는 건축가가 지시한 작업을 수행해야 합니다. 전문가는 자체적으로 해결책을 찾습니다. 건축가는 프로젝트 설명을 위한 형식을 설정합니다. 그리고 프로젝트 감독관은 일정을 원활하게, 예측 가능하며 가능한 한 편안하게 진행되도록 역할과 규칙을 관리합니다.
명확한 책임 영역이 개발자 측면과 고객 측면 모두에 없으면 작업이 비효율적입니다.
이 토픽은 Gemba - 현장 관찰 접근 방식의 소개입니다.
대규모 프로젝트를 시작할 때는 고수준 다이어그램(이전에는 Git+Markdown 블록이 이미 설정됨)으로 시작해야 합니다. 이는 모든 참가자가 동일한 언어로 이야기하고 오해나 설명 없이 작업을 할 수 있도록 해줍니다.
각 단계에서 다양한 방향과 전문성을 가진 직원들이 참여합니다.
고객 사이에서 널리 퍼진 접근 방식은 C4 모델(컨텍스트, 컨테이너, 구성 요소, 코드) 및 그 변형을 사용하여 소프트웨어 아키텍처를 설명하는 것입니다.
HLD 다이어그램, 배포 다이어그램, 컨테이너 다이어그램을 고려하십시오.
이러한 다이어그램은 네트워크 컨투어, 컨테이너 분배, MSE 및 보호 요소, 기술 지원 연결 방법을 보여줍니다. HLD 다이어그램은 데이터 흐름과 민감한 데이터 위치를 보여줍니다. 배포 다이어그램은 하드웨어 요구 사항, 장비 공급업체, 가상화, 컨테이너화, 오케스트레이션, 배포 환경을 보여줍니다. 컨테이너 다이어그램은 서버로서의 서비스, 서비스, IaaS, 마이크로 서비스, 인터페이스, 프로토콜 및 통합 유형, 데이터베이스, 브로커, 외부 구성 요소, 통합(버스, 큐, 게이트웨이, 동기/비동기 연결 유형, 통신 프로토콜)을 보여줍니다.
항상 다이어그램 블록을 따르십시오. 일치 항목을 찾고 작업을 구축하여 흰색 지점이 없도록 하십시오. 프로세스에 변경 사항이 필요한 경우 점진적으로 수행하십시오.