🌱 ADR - Architecture Decision Records
February 7, 2023•385 words
Registro de Decisões Arquiteturais (ADRs)
- Why: registrar decisões arquiteturais significativas
- What: registros da decisão em texto e contextualizados
- When: quando qualquer proposta significativa surge (proposta, aceita, ou rejeitada)
- How: criar uma pasta no repositório e um arquivo para cada decisão
Exemplos de ADRs
/adr/0000-architecture-decision-records.md (meu modelo para sugerir o uso de ADRs, quando aplicável, em um novo repositório)
# Architecture Decision Records ## Status `proposed` ## Context We want to contextualize our architecture decisions and document them in a way that is easy to understand and easy to find. Relates to #issue-number ## Decision Use the [lightweight](https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-by-michael-nygard/index.md) Architecture Decision Records (ADR) format. > An Architectural Decision (AD) is a justified software design choice that addresses a functional or non-functional requirement that is architecturally significant. An Architecturally Significant Requirement (ASR) is a requirement that has a measurable effect on a software system’s architecture and quality. An Architectural Decision Record (ADR) captures a single AD and its rationale; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM), but ADR usage can be extended to design and other decisions (“any decision record”). Extracted from <https://adr.github.io/>. This first ADR is both the record of our decision to use it and a template for future ADRs. ## Consequences We now have a centralized place for architecture decisions that directly influence this repository, but maintaining requires cultural shift and discipline.
Inspiração para templates de merge requests
# MR: One-line summary of requested change ## Context Brief comment on what is needed to know before reviewing the merge request and the why it was created. [Resolves, Fixes] #issue-number ## Implementation Brief description of the implementation approach, considered alternatives and any other important information not explicitly declared by the code itself. Focus on why it was done this way, not how or what (whitch is evidenced by the diff itself). ## Impact Sumarize important breaking changes or other non-clear impacts, such as: - Changes required by clients - Side effects - Anything that everybody needs to be aware
🌱 Seedlings são ideias que recém tive e precisam de cultivo, não foram revisadas ou refinadas. O que é isso?