아키텍처

GitLab에서는 전용 “소프트웨어 아키텍트”가 없습니다. 모든 사람이 자신의 결정을 내리도록 권장하며, 적절하게 문서화하도록 estop합니다. 이러한 결정을 어떻게하거나 어디에 문서화해야하는지 알고 싶다면 계속해서 읽어보세요.

결정 문서화

새로운 기능을 구축할 때, 구축할 것에 대한 범위와 규모를 고려하십시오. 답에 따라 세 가지 도구나 프로세스가 작업을 지원할 수 있습니다. 우리는 기능 구축 프로세스를 가능한 한 효율적으로 유지하기를 원합니다. 일반적인 규칙으로는 추가적인 지원 및 구조가 필요하지 않은 한 가능한 한 간단한 프로세스를 사용하십시오.

병합 요청

변경 사항이 그룹 내에 제한되거나 단일 기여자가 있는 경우, 아키텍처 결정의 가능한 작은 문서화는 커밋 또는 확장으로 병합 요청(MR)입니다. MR이나 커밋은 병합된 후에도 참조할 수 있으므로 특정 결정을 나중에 참조할 필요가 있을 경우를 대비해 좋은 설명, 코멘트 및 커밋 메시지가 중요합니다. 그룹 내에서 검토되도록 의도된 MR에도 모든 관련된 의사 결정이 명시적으로 포함되어야 합니다.

아키텍처 이슈

작업 단위가 충분히 크다고 생각되어 전체 그룹의 방향에 영향을 줄 수 있는 경우 기술적 방향을 논의하기 위해 아키텍처 이슈를 만드는 것이 좋은 아이디어일 수 있습니다. 이 프로세스는 비공식적이며 공식적인 요구 사항이 없습니다. 작업 계획을 제안하고 협업자를 초청하여 제안을 함께 정제할 수 있는 GitLab 프로젝트 내에서 이슈를 생성하십시오.

이 구조를 사용하면 그룹이 제안된 변경 사항을 심사하고 피드백을 모아 수정할 수 있습니다. 또한 특징 이슈나 MR 자체의 코멘트 스레드보다 이슈를 진실의 원천으로 사용할 수 있습니다. 토론을 원활하게 하기 위해 스키마와 같은 시각적 지원을 추가하는 것도 고려하십시오. 예를 들어, CI/CD 카탈로그의 아키텍처 이슈를 참조할 수 있습니다.

디자인 문서

차후 작업이 단일 그룹 이상, 스테이지 또는 아마도 전체 부서(예: 전체 프론트엔드 팀)에 영향을 줄 수 있다면 디자인 문서가 필요할 확률이 높습니다.

이것은 핸드북에서 잘 문서화되어 있지만 간단히 언급해 보자면, 이것은 대규모 변경을 제안하고 필요한 피드백과 지원을 얻는 최선의 방법입니다. 이러한 문서는 버전이 관리되며 시간이 지남에 따라 계속 발전하며 조직 전체에 복잡한 이해를 공유하는 훌륭한 방법입니다. 또한 이러한 문서에는 큰 변화에 대해 많은 경험을 가진 사람을 많이 참여시킴으로써 관계자와 관련시킴으로써 관련시킬 수 있습니다. 이 프로세스는 모든 공학 부서에서 공유되며 CTO가 소유하고 있습니다.

모든 디자인 문서를 보려면 GitLab 페이지의 아키텍처를 확인할 수 있습니다.

프론트엔드 RFCs (사용 중단됨)

과거에는 전체 부서의 의견을 얻기 위해 대규모 변경을 제안하기 위한 프론트엔드 RFC 프로젝트가 있었습니다. 이 프로젝트는 여러 이유로 더 이상 사용되지 않습니다:

이 프로젝트에서 생성된 이슈들의 참여율이 매우 낮았습니다 (20% 미만).
논란이 되는 문제는 분명한 해결 방법이 없어 멈추게 되었습니다.
완료된 이슈들은 대부분 처음부터 RFC가 필요없었습니다 (작은 문제들).
변경 사항이 종종 명확한 시간 및 리소스 할당 없이 “순진하게” 제안되었습니다.

우리가 RFC를 만들지 않은 대부분의 경우, 대신 디자인 문서를 사용하여 디자인 문서 자체에 그것의 RFC가 첨부되도록 할 수 있습니다. 이것은 대화를 기술적 설계를 중심으로 만들고 RFC는 설계 완료를 더 전진시키는 방법일 뿐입니다.

프론트엔드 문서에 등록

문서에 아키텍처 섹션을 추가하는 것은 프론트엔드 엔지니어에게 기존 아키텍처를 어떻게 사용하거나 이를 기반으로 구축하는지 알리는 방법입니다. 만약 다른 팀에 영향을 미치지 않는다면 당신의 그룹의 아키텍처를 여기에 문서화하는 것을 피하십시오.

어느 것을 선택해야 하는가?

일반적인 규칙으로는 당신과 당신의 팀이 이득을 얻을 가능성이 더 높을수록 변경의 범위가 넓은 경우 디자인 문서를 만드는 것이 더 가능성이 큽니다. 또한 변경 사항이 확실한 이중문이 결정이 맞는지도 고려하십시오: 쉽게 되돌릴 수 있는 변경 사항은 더 많은 사전 사고를 필요로하지 않습니다.

단일 마일스톤에서 달성할 수있는 업무는 아마도 MRs로 충분할 것입니다. 여러 마일스톤이 걸릴 수 있지만 DRI가 단일하다면 일반적으로 MR를 통해 수행하는 것이 더 쉽습니다.

여러 DRI가 관련된 경우 당신 모두에게 작업이 명확한지 스스로 물어보십시오. 당신이 하는 업무가 복잡하고 서로 영향을 미친다면 아키텍처 이슈에 대한 기술적 피드백을 먼저 수렴하는 것이 좋습니다. 명확한 제안을 작성하고 초기에 모든 이해관계자를 참여시키고 이슈에 대해 내린 결정에 대해 책임을 져야 합니다.

아주 작은 변경 사항에서는 매우 넓은 영향을 미칠 수 있습니다. 예를 들어, 모든 공학에 영향을 미칠 ESLint 규칙의 변경은 디자인 문서를 요구하지 않을 수 있지만 모든 의견을 수렴하기 위해 제안을 슬랙으로 보내고 단순히 MR을 만들고 마지막으로 관련 채널에 널리 공유하여 피드백을 수집하는 것이 좋습니다.

문서의 특정한 코드 패턴을 추천하기 위해, 제안된 변경을 적용하는 MR을 작성하고 이를 부서 전체에 널리 공유하고 강한 반대가 없다면 변경 사항을 병합하는 것이 좋습니다. RFC보다는 행동에 대한 편향 때문에 모든 사람이 포함되기에 필요한 모든 피드백을 수집하는 데 더 효율적입니다.

기술 스택에 대한 중대한 변경을 제안하려면 (Vue에서 React로, JavaScript에서 TypeScript으로 등)먼저 슬랙으로 연락하여 흥미를 측정하는 것으로 시작하십시오. 본인에게 완전히 현재 기술 스택에서 문제를 해결할 수 있는지 항상 스스로 물어보십시오. 이것은 우리가 이미 가진 도구로 문제를 해결하려고 노력해야하기 때문입니다. 이와 같이 기술적인 변경을 제안하는 다른 부서(예: Backend 및 QA)도 명확한 프로세스를 갖고 있지 않습니다. 그 이유는 해당 변경사항이 회사로부터 큰 투자를 요구하며 공학의 고위 직원들을 참여시키지 않고는 결정할 수 없기 때문입니다.

대신, 문제를 설명하는 디자인 문서를 작성하고 현재 도구로 문제를 해결하려고 노력하십시오. 부서로부터 기여를 초대하고 품질 있게 연구하십시오. 왜냐하면 결과적으로 두 가지 결과만 있을 수 있기 때문입니다. 문제를 현재 도구로 해결할 수 있다면, 이것은 우리 팀들에게 큰 이점입니다. 왜냐하면 우리는 스택을 완전히 변경하지 않아도 문제를 해결했기 때문이고, 만약 현재 도구로 해결할 수 없다면, 디자인 문서는 기술적 변경에 대한 대화의 시작점이 될 수 있습니다.

위젯 아키텍처

Plan stage는 오른쪽 사이드바를 위젯으로 구성하기 위한 리팩터링 작업을 진행 중에 있습니다. 이들은 재사용 가능하도록 특정한 아키텍처를 갖고 있으며 페이지의 외부 Vue 애플리케이션에서 사용할 수 있는 인터페이스를 노출합니다. 위젯 아키텍처에 대해 자세히 알아보세요.