아키텍처

GitLab에서는 전용 “소프트웨어 아키텍트”가 없습니다. 누구나 자신의 결정을 내리고 적절하게 문서화하도록 장려받습니다. 이러한 결정을 어떻게 또는 어디에 문서화해야 하는지 알아보려면 계속 읽어보세요.

결정 문서화

새로운 기능을 개발할 때, 구축할 내용의 범위와 규모를 고려하세요. 답에 따라 여러 도구나 프로세스가 귀하의 노력을 지원할 수 있습니다. 기능을 구축하는 프로세스를 가능한 한 효율적으로 유지하려고 합니다. 일반적으로 추가 지원과 구조가 필요하지 않은 경우에만 가능한 간단한 프로세스를 사용하세요.

Merge Request

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

아키텍처 이슈

작업 단위가 충분히 크면 전체 그룹의 방향에 영향을 미칠 수 있다면 기술적인 방향을 논의하기 위해 아키텍처 이슈를 만드는 것이 좋은 생각일 수 있습니다. 이 프로세스는 비공식적이며 공식적인 요구 사항이 없습니다. 작업을 제안하고 협업자를 초대하여 제안서를 개선하는 GitLab 프로젝트 내에 이슈를 만드세요.

이 구조를 사용하면 그룹이 제안된 변경 사항을 심사하고 피드백을 모아 반복할 수 있습니다. 또한 관련 이슈를 기능 이슈 또는 MR 자체의 코멘트 스레드로 사용하는 대신 진실의 원천으로 사용할 수 있습니다. 논의를 용이하게 하는 비주얼 지원(스키마와 같은)을 추가하는 것도 고려하세요. 예를 들어, CI/CD 카탈로그의 아키텍처 이슈를 참조할 수 있습니다.

설계 문서

앞으로의 작업이 단일 그룹 이상, 스테이지 이상 또는 아마도 전체 부서에 영향을 줄 수 있다면(프론트엔드 팀 전체 등), 이럴 경우 설계 문서가 필요할 가능성이 높습니다.

이는 핸드북에 잘 문서화되어 있지만 간략히 언급해보면, 이는 대규모 변경을 제안하고 필요한 피드백과 지지를 모으는 가장 좋은 방법입니다. 이러한 문서는 버전이 관리되며, 시간이 지남에 따라 발전하며 조직 전체에 복잡한 이해를 공유하는 훌륭한 방법입니다. 또한 대규모 변경에 대한 많은 경험이 있는 사람을 참여시키는 좋은 방법이기도 합니다. 이 프로세스는 모든 공학 부서에서 공유되며 CTO가 소유하고 있습니다.

모든 설계 문서를 보려면 GitLab 아키텍처 페이지를 확인하세요.

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

과거에는 전체 부서로부터 의견을 구하고 대규모 변경을 제안하기 위해 프론트엔드 RFC 프로젝트를 운영했습니다. 이 프로젝트는 일련의 이유로 더 이상 사용되지 않습니다.

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

대부분의 경우, 우리가 RFC를 만들었을 때 대신 설계 문서를 사용할 수 있습니다. 이는 대화를 기술적 설계 중심으로 만들며, RFC는 설계를 더 진행하는 방법 중 하나일 뿐입니다.

프론트엔드 문서에 등록

문서에 아키텍처 섹션을 추가하여 프론트엔드 엔지니어들에게 기존 아키텍처를 사용하거나 이를 기반으로 하는 방법을 알려줄 수 있습니다. 만약 다른 팀에 영향을 미치지 않는다면 프로덕션하는 그룹의 아키텍처를 여기에 문서화하는 것을 피하세요.

어느 것을 선택해야 할까요?

일반적으로 변경 사항의 범위가 넓을수록 설계 문서의 장점이 더 크다고 볼 수 있습니다. 또한 변경 사항이 실수로 뒤로 돌릴 수 있는 진정한 양면 문제인지도 고려하세요. 뒤로 돌릴 수 있는 변경 사항은 미리 생각할 필요가 적기 때문입니다.

단일 마일스톤 내에 달성할 수 있는 작업은 아마도 Merge Request만으로 처리하는 것이 더 쉽습니다. 여러 마일스톤에 걸쳐 완료되지만 귀하가 유일한 DRI인 경우도 아마도 MR로 진행하는 것이 더 쉽습니다.

여러 DRI가 관련된 경우, 앞으로 할 작업이 모두에게 명확한지 스스로에게 묻습니다. 만약 귀하가 하는 작업이 복잡하고 서로에게 영향을 미치는 경우, 아키텍처 이슈 작업을 시작하기 전에 팀으로부터 기술적 피드백을 수렴할지 고려하세요. 명확한 제안을 작성하고 초기에 모든 이해 관계자를 참여시키고 해당 이슈에 대한 결정을 책임져야 합니다.

매우 작은 변경 사항은 매우 넓은 영향을 미칠 수 있습니다. 예를 들어, 모든 공학에 영향을 미칠 ESLint 규칙의 변경은 모두에게 영향을 끼칠 수 있지만 설계 문서가 필요 없을 수 있습니다. 이때 관심을 메트릭하기 위해 제안서를 Slack을 통해 보내고, 간단히 MR를 만드세요. 마지막으로, 적절한 채널에 널리 공유하여 피드백을 수집하는 것이 좋습니다.

저희 문서에서 특정 코드 패턴을 권장하기 위해서는 귀하의 제안을 적용하는 MR을 작성하고 이를 부서 전체에 널리 공유한 후, 강한 반대 의견이 없다면 변화를 Merge하세요. 이는 행동에 대한 편향으로 인해 모두가 포함된 필요한 모든 피드백을 수집하는데 RFC에 비해 더 효율적입니다.

기술적 스택에 중대한 변경을 제안하려면(Vue에서 React로, JavaScript에서 TypeScript로 등), 관심을 메트릭하기 위해 먼저 Slack을 통해 연락하세요. 항상 현재 기술 스택에서 문제를 해결할 수 있는지 여부를 스스로에게 묻습니다. 왜냐하면 우리는 이미 있는 도구로 문제를 해결하려고 항상 노력해야 하기 때문입니다. 백엔드 및 QA와 같은 다른 부서들도 기술적인 변경을 제안하는 명확한 프로세스가 없습니다. 그것은 회사로부터 큰 투자가 필요하고 아마도 공학의 고위책임자들을 참여시키지 않고는 결정할 수 없기 때문입니다.

대신, 현재 도구로 문제를 해결할 수 있는지 논하기 위해 문제를 설명하는 설계 문서를 시작하고 이 부서로부터 기여를 제알하며 심사숙고하게 연구하세요. 문제가 우리 현재 도구로 해결할 수 있다면, 우리 팀에 대한 큰 승리가 될 것입니다. 왜냐하면 스택을 완전히 변경할 필요 없이 문제를 해결했기 때문입니다. 만약 해결할 수 없다면, 설계 문서는 기술적인 변경을 둘러싸는 큰 대화의 시작점이 될 수 있습니다.

위젯 아키텍처

Plan 스테이지는 오른쪽 사이드바를 위젯으로 구성하는 중입니다. 이들은 재사용 가능하고 페이지의 외부 Vue 애플리케이션에서 사용할 수 있는 인터페이스를 노출하는 특정 아키텍처를 갖고 있습니다. 위젯 아키텍처에 대해 더 알아보세요.