기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
모범 사례
소유권을 증진시킵니다. 각 프로젝트 팀원에게 ADR을 작성하고 소유할 수 있는 권한이 있어야 합니다. 이 관행은 아키텍처 연구 작업을 팀원들에게 배분하고 솔루션스 아키텍트나 팀 리더의 작업 부담을 덜어줍니다. 또한 의사결정 과정에서 주인의식을 키울 수 있습니다. 이를 통해 팀은 이러한 결정을 조직의 상위 수준에서 내려진 결정으로 간주하는 대신 더 빠르게 채택할 수 있습니다.
ADR 기록을 보존합니다. ADR에는 변경 기록이 있어야 하며 각 변경에는 소유자가 있어야 합니다. ADR 소유자가 ADR을 업데이트할 때 이전 ADR의 상태를 대체됨으로 변경하고, 새 ADR의 변경 기록에 변경 사항을 기록하고, 이전 ADR을 결정 로그에 보관해야 합니다.
정기 검토 회의 일정을 잡습니다. 신규(그린필드) 프로젝트를 진행 중인 경우 처음에는 ADR 프로세스가 상당히 까다로울 수 있습니다. 일일 스탠드업 전후에 정기적인 ADR 토론 및 검토 회의의 케이던스를 설정하는 것이 좋습니다. 이 접근 방식을 사용하면 정의된 ADR이 두세 번의 스프린트 속도로 안정화되고 회의 횟수를 줄이면서 탄탄한 기반을 구축할 수 있습니다.
ADR을 중앙 위치에 저장합니다. 각 프로젝트 멤버가 ADR 컬렉션에 액세스할 수 있어야 합니다. ADR을 중앙 위치에 보관하고 프로젝트 문서의 기본 페이지에서 참조하는 것이 좋습니다. ADR을 저장하는 데 많이 사용되는 두 가지 옵션이 있습니다.
-
ADR 버전 관리를 쉽게 해주는 Git 리포지토리
-
모든 팀원이 ADR에 액세스할 수 있도록 하는 wiki 페이지
규정을 준수하지 않는 코드를 해결합니다. ADR 프로세스로는 규정을 준수하지 않는 레거시 코드 문제를 해결할 수 없습니다. 기존 ADR을 지원하지 않는 레거시 코드가 있는 경우 새로운 변경 사항을 도입하면서 오래된 코드 베이스 또는 아티팩트를 점진적으로 업데이트하거나 팀에서 기술적 부채 작업을 생성하여 코드를 명시적으로 리팩터링하기로 결정할 수 있습니다.