카테고리 없음

누가, 어디서, 언제: 팀의 책임 영역을 분리하는 구성 요소 시스템

카카오블로거 2021. 10. 26. 21:35

우리 팀에는 200명 이상의 백엔드 개발자가 있으며 애플리케이션에서 수백 개의 모듈과 개별 서비스를 작업하고 있습니다. 하지만 처음에는 그렇게 크지 않았다. 2006년에 이것은 소규모 팀이 작업 중인 프로젝트 중 하나였습니다. 각 개발자는 모든 것이 어떻게 작동하는지 잘 이해하고 있었습니다. 그는 코드를 쉽게 탐색하고, 거기에 있는 서비스가 무엇인지, 서로 어떻게 상호 작용하는지 알고 있었습니다. 그러나 프로젝트가 성장함에 따라 "지식 키퍼"를 찾는 데 점점 더 많은 시간이 걸렸습니다. 이러한 기능 또는 그 기능을 담당하고 질문이나 제안에 대해 연락할 수 있는 사람입니다.

이 기사에서는 컴포넌트 접근 방식을 사용하여 책임 영역 분리 문제를 해결하고 정보 업데이트 프로세스를 빠르고 편리하게 만든 방법에 대해 설명합니다. 

배경

상황을 상상해보십시오. 한 팀의 개발자가 버그를 수정하고 디버깅 과정에서 다른 팀이 담당하는 코드에 도달했습니다. 이 기능을 정확히 누가 담당하고 누구에게 질문을 해야 하는지 이해하는 방법은 무엇입니까?

즉, 시스템의 이 부분 또는 그 부분을 담당하는 사람을 쉽게 찾을 수 있는 방법이 필요합니다. 이를 위해 DocBlock 파일에서 두 개의 특수 태그를 사용하기 시작했습니다.

  • @team - 시스템의 이 부분을 담당하는 팀.
  • @maintainer는 이 기능을 개발하는 사람입니다(여러 명의 직원이 있을 수 있음).

/** * @team Team name <team@example.com> * @maintainer John Smith <john.smith@example.com> * @maintainer .... */

이 접근 방식은 구현 및 사용이 매우 쉽습니다. 예를 들어 PhpStorm에서 템플릿을 설정할 수 있으며 새 파일을 만들 때 필요한 태그가 자동으로 추가됩니다. 또한 모든 파일에 필요한 형식의 필요한 태그가 있는지 확인하는 별도의 Git 후크를 만들었습니다.

그러나 곧 이 접근 방식은 유연성을 잃기 시작했습니다. 새로운 사람들이 회사에 왔고 누군가가 한 팀에서 다른 팀으로 이동했으며 매번 책임자에 대한 정보를 업데이트해야 했습니다. 또한 Zabbix에서 모니터링을 구성할 때 이 정보가 중복되었습니다. 코드를 수정하는 것이 다소 사소한 작업이라면 특정 확인 결과에 대한 알림 수신자 목록을 빠르게 업데이트할 수 없습니다. 모니터링 부서에 작업을 할당하고 지정된 프로세스 내에서 완료될 때까지 기다려야 합니다.

책임자 목록을 한 곳에서 업데이트할 수 있기를 원했습니다. 그리고 다른 모든 시스템이 자동으로 변경 사항을 선택하는 것이 바람직합니다. 

이것이 컴포넌트 접근 방식에 도달한 방법 입니다.

구성 요소 란 무엇입니까

정의부터 시작하겠습니다. 구성 요소 는 시스템의 특정 부분을 나타내는 추상화입니다. 우리의 경우 구성 요소는 코드 구조화 도구라기 보다는 책임 영역을 분할하기 위한 관리(조직적) 도구라는 점에 유의하는 것이 중요합니다. 

구성 요소가 반드시 코드와 직접 관련된 기능일 필요는 없습니다. 애플리케이션의 새 버전 출시와 같은 조직 프로세스도 구성 요소가 될 수 있습니다.

구성 요소 접근 방식으로 전환할 때 다음과 같은 여러 규칙과 제한 사항이 있습니다.

  • 구성 요소의 구조는 선형이어야 합니다.
  • 각 팀에는 고유한 구성 요소 집합이 있어야 합니다(동일한 구성 요소는 여러 팀을 참조할 수 없음).
  • 각 구성 요소에 대해 책임자 목록을 지정해야 하며 한 구성 요소에 대한 최적의 책임자 수는 2~4명입니다.
  • 팀의 관리자 또는 팀장만 구성 요소를 추가 및 제거할 수 있습니다.
  • 각 구성 요소에는 고유한 식별자(별칭)가 있어야 합니다.

구성 요소를 관리하기 위해 인트라넷에 특수 인터페이스가 있습니다. 구성 요소 페이지는 다음과 같습니다.

구성 요소 인트라넷 페이지의 예

구성 요소에 다음이 포함되어 있음을 알 수 있습니다.

  • 고유 식별자;
  • 이메일;
  • 이 구성 요소를 담당하는 팀의 이름입니다.
  • Jira에서 구성 요소가 속한 프로젝트의 이름입니다.
  • 구성 요소의 용도와 책임 영역을 이해하는 데 도움이 되는 간단한 설명
  • 책임자 목록: 각 구성 요소에는 편집할 수 있는 소유자가 있습니다(이는 팀의 관리자 또는 팀 리더이거나 구성 요소를 추가할 때 소유자로 명시적으로 표시된 다른 사람일 수 있음).

코드에서 구성 요소를 사용하는 방법

파일 독블록

/** * @component component_alias */

Dockblock을 확인하는 Git hook을 개선했습니다. 수정된 파일에 @component 태그가 포함되어 있고 지정된 구성 요소가 존재하는지 확인합니다. 

remote: ERROR in SomeClass.php: remote: * Unknown @component: UnknownComponent. You have to create component before using it in the code

또한 다른 개발자가 파일에 변경한 모든 변경 사항에 대한 구성 요소 알림을 보내는 후크가 있습니다. 이는 다른 팀의 개발자가 코드를 편집하고 검토를 위해 문제를 제출하지 않는 경우에 유용합니다.

코드에서 구성 요소 작업을 위한 서비스

코드에서 구성 요소로 작업하기 위해 모든 구성 요소 목록을 가져오고 전체 이름이나 식별자로 특정 구성 요소를 찾을 수 있는 별도의 클래스가 있습니다. 인트라넷의 인터페이스에서와 동일한 정보를 코드에서 사용할 수 있습니다.

$componentManager = new \Components\ComponentManager(); $component = $componentManager->getComponent('component_alias'); $recipients = []; foreach ($component->getMaintainers() as maintainer) { $recipients[] = $maintainer->getEmail(); }

또는 구성 의무 장교를 찾으십시오.

$componentManager = new \Components\ComponentManager(); $component = $componentManager->getComponent('component_alias'); foreach ($component->getMaintainers() as $maintainer) { if ($maintainer->isDuty()) { return $maintainer; } }

PhpStorm과의 통합

우리 블로그에는 개발자의 삶을 훨씬 더 쉽게 만들어주는 PhpStorm용 플러그인에 대한 기사 가 있습니다. 작성 이후 시간이 지나면서 우리는 많은 새로운 편리한 기능을 구현하고 구성 요소에 대한 지원을 추가했습니다.

이제 IDE에 구성 요소 소유자와 교환원이 자동으로 표시됩니다. 또한 구성 요소 식별자 위로 마우스를 가져가면 메신저(Slack)에 개인 메시지를 보낼 수 있는 모든 책임이 있는 목록과 함께 추가 블록이 표시됩니다.

구성품 의무

많은 사람들이 컨텍스트 전환 문제에 직면했다고 생각합니다. 제 생각에는 이것을 피하려고 노력해야 합니다. 각각 고유한 속도가 있으며 작업(상황)에 다시 몰두하는 데 걸리는 시간이 다릅니다. 누군가는 몇 분이 필요하고 누군가는 훨씬 더 필요합니다.

컨텍스트 전환의 영향을 최소화하기 위해 당직 감시를 도입하기로 결정했습니다. 이제 각 구성 요소에는 관련된 모든 질문에 대한 진입점인 수행자가 있습니다. 사람이 직무를 인수하면 이에 대한 표시가 필요한 모든 구성 요소에 나타나며 메신저의 공개 그룹에 표시됩니다.

이것은 팀이 임무를 맡은 사람을 운명의 자비에 맡기는 것을 의미하지 않습니다. 이전에 문제가 발생하지 않았다면 항상 동료를 연결할 수 있습니다. 그러나 근무자가 질문의 80%만 단독으로 답한다면 나머지 팀원들은 맥락에서 밀리는 것을 두려워하지 않고 80%의 시간 동안 침착하게 업무를 수행한다는 의미입니다.

또한 교대 근무를 통해 팀 내에서 지식을 공유할 수 있으므로 버스 요인이 증가합니다.

내부 시스템과의 통합

코드에서 직접 구성 요소를 사용하는 것 외에도 대부분의 내부 시스템에 구성 요소에 대한 지원이 추가되었습니다. 다음은 몇 가지 예입니다.

PHP 오류 수집 및 분석 시스템

역사적으로 PHP 오류를 수집하고 분석하기 위해 인기 있는 Sentry 및 Splunk와 기능면에서 유사하지만 내부 프로세스에 맞게 조정된 자체 작성 시스템을 사용합니다. 여기에는 먼저 구성 요소에 대한 지원이 추가되었습니다. 

오류 수집 단계 중 하나는 추가 정보로 이벤트를 포화시키는 것입니다. 시스템이 오류 스택 추적에서 파일 목록을 기반으로 영향을 받는 구성 요소 목록을 수집하는 파이프라인에 새로운 단계를 추가했습니다. 

이 정보는 다음과 같이 사용할 수 있습니다.

  • 특정 구성 요소에 대한 오류를 검색합니다.
  • 구성 요소별로 분류된 보고서 및 그래프를 생성합니다.

또한 구성 요소에 대한 정보를 사용할 수 있으므로 오류가 발생한 시스템 부분에 대한 책임이 있는 사람을 쉽게 찾을 수 있습니다. 이렇게 하려면 오류에 대한 자세한 정보가 있는 페이지로 이동하여 스택 추적을 확인합니다. 

데이터베이스 레지스트리

Badoo 및 Bumble 앱의 백엔드는 수백 개의 서로 다른 모듈, 시스템 및 서비스로 구성되어 있습니다. 대부분은 데이터 저장을 위해 MySQL을 사용합니다.  

이제 상황을 상상해 봅시다. 개발자가 그를 위해 새로운 기능을 다루기 시작하고 그 과정에서 일부 테이블의 스키마를 살펴봐야 했습니다. 이를 위해서는 다음이 필요합니다.

  1. 호스트가 거주하는 코드에서 찾으십시오.
  2. 편리한 도구(콘솔 유틸리티, phpMyAdmin, Sequel Pro, IDE 등)를 통해 호스트에 연결합니다.
  3. 필요한 베이스와 테이블을 찾으십시오.
  4. 테이블에 대한 정보를 조사합니다.

생산 중인 테이블의 크기를 알아야 하는 경우? 

먼저 데이터베이스에 대한 액세스를 요청하고 데이터베이스가 제공될 때까지 기다려야 합니다. 그런 다음 필요한 정보를 얻을 수 있습니다. 사실, 이 계획은 간단하고 작동합니다. 액세스 권한을 얻는 과정은 우리와 함께 자동화되어 있습니다. 그러나 간단한 질문에 대한 답을 얻는 데는 꽤 오랜 시간이 걸립니다.

또 다른 예: 오랫동안 사용되지 않고 단순히 서버의 공간을 차지하는 테이블 목록을 찾아야 합니다. 여기에서 필요한 모든 서버를 우회하고 통계를 수집하는 스크립트를 이미 작성해야 합니다.

개발자의 삶을 더 쉽게 만들기 위해 DBRegistry라는 시스템을 만들었습니다. INFORMATION_SCHEMA를 통해 사용 가능한 모든 데이터베이스에 대한 정보를 저장합니다.

구성 요소를 구현할 때 특정 데이터베이스 또는 테이블이 속한 구성 요소를 지정하는 기능을 추가했습니다.

구성 요소에 대한 정보는 문제가 일부 서버에서 시작되고(예: CPU의 부하가 증가한 경우) 데이터베이스 관리자가 문제 요청을 발견하고 개발자에게 문제를 보고하려는 경우에 유용합니다. 그는 단순히 DBRegistry에서 필요한 테이블을 찾고 바인딩된 구성 요소를 보고 교환원에게 문제에 대해 씁니다.

결론

구성 요소 접근 방식으로 전환한 지 3년 이상이 지났으며 이 기간 동안 모든 내부 시스템에서 구성 요소 지원이 구현되었습니다. 우리는 프로세스를 더 빠르고 이해하기 쉽게 만들 수 있었습니다. 이제 아무도 "누가 이 코드를 담당합니까?"라는 질문을 하지 않습니다. 인트라넷을 열고 필요한 구성 요소를 찾는 것으로 충분합니다. 여기에는 필요한 모든 정보가 포함되어 있습니다.

책임자 목록 업데이트는 인터페이스에서 몇 번의 클릭 으로 가능하지만 구성 요소를 구현하기 전에는 모든 시스템에서 이 정보를 업데이트하는 데 며칠 또는 몇 주가 걸릴 수 있습니다.

그게 다야. 관심을 가져 주셔서 감사합니다!