일주일에 100,000만 줄의 코드를 읽고 고치는 방법

처음에는 크고 오래된 프로젝트를 이해하는 것이 항상 어렵습니다. 건축은 건축가 평가 활동 중 하나입니다. 일반적으로 대규모의 오래된 프로젝트를 진행해야 하며 결과는 일주일 안에 전달되어야 합니다.

클라이언트에게 진정으로 유용한 결과를 제공하면서 일주일 안에 100만 줄 이상의 코드 프로젝트를 평가하는 방법.

대부분의 설계자와 기술 책임자는 유사한 프로젝트 평가를 받았습니다. 이것은 반공식적인 프로세스처럼 보일 수도 있고 우리 회사에서 수행되는 별도의 서비스로 보일 수도 있습니다. 어떤 식으로든 대부분의 여러분이 이 문제를 처리해 왔습니다.

러시아어를 사용하지 않는 친구를 위한 영어 원본은 여기 있습니다: 일주일 만에 아키텍처 평가.

우리 회사의 접근 방식

우리 회사에서 어떻게 작동하는지, 그리고 비슷한 상황에서 제가 어떻게 행동하는지 말씀드리겠습니다. 하지만 프로젝트와 회사의 필요에 따라 이 접근 방식을 쉽게 변경할 수 있습니다.

아키텍처 평가에는 두 가지 유형이 있습니다.

내부 – 보통 회사 내 프로젝트를 위해 그렇게 합니다. 모든 프로젝트는 다음과 같은 여러 가지 이유로 아키텍처 평가를 요청할 수 있습니다.

1. 팀은 자신의 프로젝트가 완벽하다고 생각하는데 이는 의심스럽습니다. 우리는 그러한 경우를 겪었고 종종 그러한 프로젝트에서는 모든 것이 이상적이지 않습니다.
2. 팀은 프로젝트와 솔루션을 테스트하고 싶어합니다.
3. 팀은 상황이 나쁘다는 것을 알고 있습니다. 주요 문제와 원인을 나열할 수도 있지만 프로젝트 개선을 위한 전체 문제 목록과 권장 사항을 원합니다.

외부의 내부 평가보다 더 공식적인 프로세스입니다. 클라이언트는 항상 모든 것이 나쁜 경우에만 발생합니다. 매우 나쁩니다. 일반적으로 클라이언트는 전반적인 문제가 있음을 이해하지만 원인을 정확하게 식별하고 구성 요소로 분류할 수 없습니다.

외부 클라이언트에 대한 아키텍처를 평가하는 것은 더 복잡한 경우입니다. 프로세스는 좀 더 형식적이어야 합니다. 프로젝트는 항상 크고 오래되었습니다. 그들은 많은 문제, 버그, 비뚤어진 코드를 가지고 있습니다. 완료된 작업에 대한 보고서는 최대 몇 주 이내에 준비되어야 하며, 여기에는 주요 문제와 개선을 위한 권장 사항이 포함되어야 합니다. 따라서 프로젝트의 외부 평가를 처리한다면 내부 평가는 식은 죽 먹기가 될 것입니다. 가장 어려운 경우를 생각해 봅시다.

엔터프라이즈 프로젝트 아키텍처 평가

평가할 일반적인 프로젝트는 문제가 많은 대규모의 오래된 엔터프라이즈 프로젝트입니다. 한 고객이 우리에게 와서 자신의 프로젝트를 수정해 달라고 요청했습니다. 이는 마치 빙산과 같습니다. 클라이언트는 자신의 문제의 일각만을 보고 물 아래(코드 깊은 곳)에 무엇이 있는지 전혀 모릅니다.

고객이 불만을 제기할 수 있고 인지할 수 있는 문제:

• 성능 문제
• 사용성 문제
• 장기 배포
• 단위 및 기타 테스트 부족

클라이언트가 인식하지 못할 가능성이 높지만 프로젝트에 존재할 수 있는 문제:

• 안전 문제
• 디자인 문제
• 잘못된 아키텍처
• 알고리즘 오류
• 부적절한 기술
• 기술 부채
• 잘못된 개발 프로세스

공식적인 아키텍처 검토 프로세스

이는 당사가 회사로서 준수하는 공식적인 프로세스이지만 회사 및 프로젝트에 따라 맞춤 설정할 수 있습니다.

클라이언트의 요청

클라이언트는 현재 프로젝트의 아키텍처를 평가해 달라고 요청합니다. 당사 담당자는 프로젝트에 대한 기본 정보를 수집하고 필요한 전문가를 선정합니다. 프로젝트에 따라 전문가가 다를 수 있습니다.

솔루션 설계자 – 평가 및 조정을 담당하는 주요 사람(종종 유일한 사람).
스택 전문 전문가 – 프로젝트 및 기술에 따라 .Net, Java, Python 및 기타 기술 전문가
클라우드 전문가 – Azure, GCP 또는 AWS 클라우드 설계자가 될 수 있습니다.
인프라 – DevOps, 시스템 관리자 등
기타 전문가 – 빅데이터, 머신러닝, 성능 엔지니어, 보안 전문가, QA 리드 등이 있습니다.

프로젝트에 대한 정보 수집

프로젝트에 관해 가능한 한 많은 정보를 수집해야 합니다. 상황에 따라 다양한 기술을 사용할 수 있습니다.

• 설문지 및 기타 우편을 통한 의사소통 방법. 가장 비효율적인 방법입니다.
• 온라인 회의.
• Google 문서, Confluence, 저장소 등과 같은 정보 교환을 위한 특수 도구
• 현장에서의 "실시간" 회의. 가장 효과적이고 비용이 많이 드는 방법입니다.

클라이언트로부터 무엇을 얻어야 할까요?

기본 정보. 이 프로젝트는 무엇에 관한 것인가요? 그 목적과 가치. 앞으로의 주요 목표와 계획입니다. 사업 목표 및 전략. 주요 문제와 원하는 결과.

프로젝트 정보. 기술 스택, 프레임워크, 프로그래밍 언어. 온프레미스 또는 클라우드 배포. 프로젝트가 클라우드에 있는 경우 어떤 서비스가 사용됩니까? 어떤 아키텍처 및 디자인 패턴이 사용되었는지.

비기능적 요구사항. 시스템의 성능, 가용성 및 사용 편의성과 관련된 모든 요구 사항입니다. 안전 요구사항 등

기본 사용 사례 및 데이터 흐름.

소스 코드에 대한 액세스. 가장 중요한 부분! 프로젝트를 빌드하는 방법에 대한 저장소와 문서에 확실히 액세스할 수 있어야 합니다.

인프라에 대한 접근. 라이브 시스템과 함께 작업할 수 있는 무대나 프로덕션 인프라에 접근할 수 있으면 좋을 것 같습니다. 클라이언트가 인프라와 성능을 모니터링할 수 있는 도구를 갖고 있다면 이는 큰 성공입니다. 다음 섹션에서 이러한 도구에 대해 설명하겠습니다.

Документация. 클라이언트에 문서가 있는 경우 이는 좋은 시작입니다. 오래되었을 수도 있지만 여전히 좋은 시작입니다. 문서를 절대 믿지 마십시오. 클라이언트, 실제 인프라 및 소스 코드에서 테스트하십시오.

아키텍처 평가 프로세스

어떻게 그렇게 짧은 시간에 그렇게 많은 양의 정보를 처리할 수 있을까요? 우선, 작업을 병렬화하세요.

DevOps는 인프라를 살펴봐야 합니다. 코드에 대한 기술 리드. 성능 측정항목을 볼 수 있는 성능 엔지니어. 데이터베이스 전문가는 데이터 구조를 더 깊이 파고들어야 합니다.

하지만 이는 리소스가 많을 때 이상적인 경우입니다. 일반적으로 XNUMX~XNUMX명이 프로젝트를 평가합니다. 프로젝트의 모든 영역에 대한 적절한 지식과 경험이 있는 경우 견적을 직접 수행할 수도 있습니다. 이 경우에는 모든 프로세스를 최대한 자동화해야 합니다.

안타깝게도 설명서를 수동으로 읽어야 합니다. 적절한 경험이 있으면 문서의 품질을 빠르게 이해할 수 있습니다. 무엇이 사실이고 무엇이 현실과 분명히 일치하지 않는지. 때로는 실제 생활에서는 결코 작동하지 않는 아키텍처를 문서에서 볼 수 있습니다. 이는 프로젝트에서 실제로 어떻게 이루어졌는지 생각해 볼 수 있는 계기가 됩니다.

프로젝트 평가를 자동화하는 유용한 도구

코드 평가는 간단한 연습입니다. 디자인, 성능 및 보안 문제를 보여주는 정적 코드 분석기를 사용할 수 있습니다. 다음은 그 중 몇 가지입니다.

구조 101 건축가에게 훌륭한 도구입니다. 이는 큰 그림, 모듈 간의 종속성 및 리팩토링을 위한 잠재적 영역을 보여줍니다. 모든 좋은 도구와 마찬가지로 비용도 많이 들지만 30일 평가판을 활용할 수 있습니다.

소나큐브 - 좋은 오래된 도구입니다. 정적 코드 분석을 위한 도구입니다. 20개 이상의 프로그래밍 언어에 대한 잘못된 코드, 버그 및 보안 문제를 식별할 수 있습니다.

모든 클라우드 제공업체에는 인프라 모니터링 도구가 있습니다. 이를 통해 비용 및 성능 측면에서 인프라의 효율성을 적절하게 평가할 수 있습니다. AWS의 경우 이는 신뢰할 수있는 조언자. Azure에서는 쉽습니다. 애저 어드바이저.

추가 성능 모니터링 및 로깅은 모든 수준에서 성능 문제를 찾는 데 도움이 됩니다. 비효율적인 쿼리가 있는 데이터베이스에서 시작하여 백엔드에서 프런트엔드로 끝납니다. 클라이언트가 이전에 이러한 도구를 설치하지 않은 경우에도 이를 기존 시스템에 상당히 빠르게 통합하여 성능 문제를 식별할 수 있습니다.

언제나 그렇듯이 좋은 도구는 그만한 가치가 있습니다. 몇 가지 유료 도구를 추천해 드릴 수 있습니다. 물론 오픈 소스를 사용할 수도 있지만 시간이 더 걸립니다. 그리고 이는 아키텍처 평가 프로세스가 아닌 사전에 수행되어야 합니다.

새로운 유물 – 애플리케이션 성능을 평가하기 위한 도구
데이터 도그 – 클라우드 시스템 모니터링 서비스

보안 테스트에 사용할 수 있는 도구는 많습니다. 이번에는 무료 시스템 검사 도구를 추천해 드리겠습니다.

OWASP 잽 – 보안 표준 준수를 위해 웹 애플리케이션을 검사하는 도구입니다.

모든 것을 하나로 모아 보자.

보고서 준비

클라이언트로부터 수집한 데이터로 보고서를 시작하세요. 프로젝트 목표, 제약 조건, 비기능적 요구 사항을 설명합니다. 그 후에는 소스 코드, 문서, 인프라 등 모든 입력 데이터를 언급해야 합니다.

다음 단계. 수동으로 또는 자동화된 도구를 사용하여 발견한 문제를 나열하십시오. 대규모 자동 생성 보고서를 애플리케이션 섹션의 끝에 배치하세요. 발견된 문제에 대한 짧고 간결한 증거가 있어야 합니다.
오류, 경고, 정보 척도에서 발견된 문제의 우선순위를 정합니다. 자신만의 척도를 선택할 수 있지만 이는 일반적으로 허용되는 척도입니다.

진정한 설계자로서 발견된 문제를 해결하기 위한 권장 사항을 제공하는 것은 귀하의 책임입니다. 고객이 받게 될 개선 사항과 비즈니스 가치를 설명합니다. 비즈니스 가치를 보여주는 방법 아키텍처 리팩토링 우리는 앞서 논의했습니다.

작은 반복으로 로드맵을 준비하십시오. 각 반복에는 완료 시간, 설명, 개선에 필요한 리소스의 양, 기술적 가치 및 비즈니스 가치가 포함되어야 합니다.

우리는 아키텍처 평가를 완료하고 고객에게 보고서를 제공합니다.

보고서를 우편으로 보내지 마십시오. 전혀 읽히지 않을 수도 있고, 적절한 설명이 없으면 읽거나 이해하지 못할 수도 있습니다. 즉, 라이브 커뮤니케이션은 사람들 간의 오해를 없애는 데 도움이 됩니다. 고객과의 회의 일정을 잡고 가장 중요한 문제에 초점을 맞춰 발견된 문제에 대해 이야기해야 합니다. 내담자가 인식하지도 못하는 문제에 대해 내담자의 관심을 끄는 것은 가치 있는 일입니다. 보안 문제 등이 비즈니스에 어떤 영향을 미칠 수 있는지 설명합니다. 개선 사항이 포함된 로드맵을 보여주고 고객에게 더 적합한 다양한 옵션에 대해 논의하세요. 시간, 리소스, 작업량이 될 수 있습니다.

회의 요약으로 고객에게 보고서를 보냅니다.

결론적으로

아키텍처 평가는 복잡한 프로세스입니다. 평가를 제대로 수행하려면 충분한 경험과 지식이 필요합니다.

단 일주일 만에 고객과 그의 비즈니스에 유용한 결과를 제공하는 것이 가능합니다. 혼자하더라도.

내 경험에 따르면 많은 개선 사항이 중간에 다운로드되어 시작되지 않는 경우도 있었습니다. 자신을 위해 황금률을 선택하고 최소한의 인건비로 비즈니스에 가장 유용한 부분만 개선한 사람들은 제품의 품질을 크게 향상시켰습니다. 아무것도 하지 않은 사람들은 몇 년 후에 프로젝트를 완전히 종료할 수도 있었습니다.

귀하의 목표는 고객에게 최소 가격으로 최대 개선 사항을 보여주는 것입니다.

해당 섹션의 다른 기사 아키텍처 여가 시간에 읽을 수 있습니다.

깨끗한 코드와 올바른 아키텍처 결정을 기원합니다.

우리의 페이스북 그룹 - 소프트웨어 아키텍처 및 개발.

출처 : habr.com