Dev Guidances

目的

本仓库尝试根据过往的经验，针对开发团队的日常事务，制定出纲领性的清单、规范、标准和流程，并在实践中不断完善，构建出一整套覆盖各个工作环节的、可执行的体系。

除了作为开发的日常事务的执行参考以外，本仓库中的内容还可以作为研究团队、运维团队等其他技术向团队的编写参考。

概念

在以下的阐述中，我们尝试以 可以(MAY)、应当(SHOULD)、必须(MUST)、避免(SHOULD NOT)、不得(MUST NOT) 来区分要求的严格程度。

清单

清单是一系列事、物的罗列，通常用于检查事是否已经执行、物是否存在。

编撰清单时应当遵循：

• 每一项均应当为简洁的名词或动词，避免出现不必要的形容词或副词以及其他修饰类语素
• 可以包含非必选项，但应当有清晰的条件标注
• 各项之间可以存在层级关系，避免出现分支和依赖

规范

规范是针对某个具体场景的、可以提升质量的一组建议和做法的集合。在此，我们主要取其倡议的语义，从而避免和标准形成交叉和冲突。

编撰规范时应当遵循：

• 建议和做法应当源于实践
• 可以包含一定的宽容度；对于建议，可以从最高标准逐渐降级；对于做法，可以从最低标准逐渐升级；但应当给予衡量尺度、使用场景的分析，避免形成简单的罗列
• 规范的实施与否、覆盖范围、严格程度，应当由团队自决

标准

标准是将部分规范精炼、提升执行力度后的结果。

编撰标准时应当遵循：

• 每一条标准都应当包含精确的前置条件
• 每一条标准都必须包含评判规则，根据评判规则应当得到一个关于达标与否的、简单的二元结果
• 标准的实施必须具备强制力，应当包含不达标时的处理方式

流程

流程是将一个完整的动作分解成多个步骤之后的结果。

编撰流程时应当遵循：

• 流程应当仅存在一个“入口”步骤，仅存在少量“终止”步骤
• 每一个步骤都应当至少存在一个动作
• 每一个步骤都应当至少关联到一个清单、规范、标准 或其他 流程
• 当两个步骤之间存在分支、依赖关系时，应当包含精确的前置条件

概念的界定

流程与其它

• 流程可以由清单、规范或标准转化而来；这种转化依然应当遵循流程的编撰要求；举例来说，如果一份标准，其执行过程不涉及到其他清单、规范、标准或流程的执行，那么它应当维持标准的形式，避免升格成流程
• 相应的，流程也可以降格成清单、规范或标准；举例来说，如果一种流程，可以经过简化、去除绝大多数的分支和依赖，那么它可以被简化成一份清单

规范与标准

• 规范升级成标准需要经过不少于3个月的执行，并就执行的细节在团队内达成一致
• 不具备强制力，或无法评判的标准应当先降级成规范。