持续交付之标准现行

前言 标准先行并不是一个新鲜玩意,不过是先制定事实标准,而后使用这些标准约束之后的行为。俗话说得好:“没有规矩,不成方圆”。在这里,我想说一下我认为的标准先行以及与持续交付的结合,希望不会对你产生误导。 为什么需要标准先行 我们可以先不去问为什么,而是反过来看这个问题。假设在我们的产物交付过程中,没有任何的标准,给你自由,会发生些什么问题。在一阵头脑风暴(抽搐)之后,我做出如下假设: 乱象百出,群魔乱舞。不论是正确的还是错误的产出,解释如此。比如,整体代码的可读性和可维护性直线下降;分支来回穿插,Commit 信息奇奇怪怪;开发、测试环境存在混用,测试数据过于随意;部署由心,同一个应用在不用的主机上存放位置可能还不同等等。 过程、阶段性产物不统一,且质量高低不齐,严重影响系统集成与交付。 高效完成,但前提是有着意见一致、理念相同、水平相当的一群人。 在我的假想中,自由带来的有好也有坏。但是我仍认为大部分的时候出现的都是坏的影响,毕竟要寻找到一群志同道合的人一起共事,就已经是一件很不容易的事了,且不说每个人都是单独的个体,其思想与灵魂亦是独一无二的。所以,不管在什么样的情况下,我们都需要制定标准来约束我们的行为。统一标准下的行为造成的影响几乎是一致的,那么即使是排错、修改时也是有迹可循。(在这里不会抬杠标准与自由的取舍,存在即是合理。但是从两者在大部分时候所能产生的影响来看,我会采取强标准,若自由的方式,但这绝非将两者置为对立关系。) 都有哪些标准先行 没有绝对通用的标准,任何的标准都是不同场景下最佳实践的总结,且需要持续的进行优化,是可以传承的宝贵知识集合。之所以扯这么一段话,我只是想说目前还处于实践阶段,但是这并不影响制定相关的标准。使用过 SpringBoot 开发的大佬都知道什么是约定优于配置,我认为标准亦是如此,即标准之上是约定。在这里,我将需要先行的标准分为了如下几个方面: 开发模式与分支策略(含 Commit 规范) 编码规范(Java、JavaScript) API 设计规范 数据库设计规范 环境隔离 部署规范 发布流水线标准 标准先行与持续交付 总结 参考文献 持续交付36讲 说明 我不是在卖课 本文大部分内容来源于极客时间以及网络博文节选,如有冒犯,我先向您道歉,另还请告知我进行处理,谢谢 邮箱:thread_zhou@126.com

November 17, 2020 · 1 min · Fuyi