语义版本化问题
语义化版本 2.0.0
《语义化版本 2.0.0》，三段版本号语义：
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
- 主版本号：当你做了不兼容的 API 修改，
- 次版本号：当你做了向下兼容的功能性新增，
- 修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2018-05-09
convention over configuration over programming
convention over configuration over programming in configuration, cmd args > env > configuration file option 是命令可选的参数，可以影响程序的how to do，算是一种特殊的argument，通常与flag同义（flag在很多时候是boolean形态的option）。普通的 argument 则是告诉程序 what to do。如果command是一个动词，option就是一个副词或者形容词，argument则是它的宾语，通常是名词或者代词。 该模型也可以这样理解：APPNAME VERB NOUN —ADJECTIVE或者APPNAME COMMAND ARG —FLAG
2018-10-08
业务分析方法
背景从 prd 出发，分析业务需求，寻找可以创造价值的方案。 业务分析的价值 全面分析用户的各项需求 告诉我们“做什么” 业务分析的目的 理解产品需求，识别业务范围 分析业务模块的重要程度、优先级 发现产品设计的不足 为后后续测试分析做准备 业务分析方法-整体过程用不同的动作达到不同的产出。 理解 需求背景（必须） 举例：阿里巴巴账户体系要初步阐述：1. 产生什么价值。 2. 需要解决什么问题。3. 甚至要阐明要达到什么目标（比如，基于支付宝账户体系统一账户id）。 现状分析（必须） 产品定位 现有业务架构 产品业务范围 规划业务架构（1. 要有分期的意识，识别产品形态。 2. 要有清洗数据的方案，预测安全风险） 识别（抽象分析建模） 业务角色（实际上就是系统交互的输入方，有多少个角色，就需要关注多少个东西） 自然人 其他系统 业务串联（为了找业务用例。业务串联就是把一堆文字描述串在一起） 业务用例（建模-业务用例图 用例是对场景的概括） 分析业务用例（建模-活动图 活动图是对用例的拆解） 提炼（进一步建模） 关键流程 由活动图的 action...
2018-10-08
系分方法论交流笔记
分析、设计和架构的区别系分 = 业务分析 + 系统设计 系分其实就是 Analysis + Design 业务分析才是最重要的大头要理解： 架构约束 项目约束 要有： 权衡 选择的过程 理解业务，要理解业务背后的东西，产出的是模型。一步一步走，推演出来解决方案，要有方法论。 系统设计是很明确的工作了应用设计 + 数据设计 + 技术设计 = 系统方案 要考虑的额外问题： 非功能设计：运行关注点、运维关注点、开发关注点、测试关注点。 项目约束 常见方法论用例驱动设计SOAD 面向服务的分析和设计OOAD 面向对象分析和设计DDD 领域驱动设计 DDD特别适合复杂系统。有一个以不变应万变的对象，才可以在未来承载复杂的业务演进过程。这几种方法论可以混合使用。 需求分析与业务建模把 prd 从薄读到厚，把文档中缺失的部分补全。 系分做 PRD...
2018-10-26
checklist
写代码 checklist注意位置注意顺序注意初始化注意返回值注意注释注意防御性编程注意数据库性能 上线 checklist代码变更 check 代码配置变更 check 配置系统变更注意上线顺序依赖中间件变更注意配置中间件配置中心配了吗交互所有细节都实现了吗？配监控和埋点数据库变更了吗？安全检查
2019-02-13
所谓解耦
软件设计，必有单元/片段，不管他们叫做系统、层次、模块、类型和方法，都是为了在一个抽象颗粒度上分割复杂度，让我们降低思考的难度，并且进行团队协作。 我们在进行系统交互的时候，要尽量设计单元交叉点通过薄的中间层交互。也就是放弃直接性，拥抱间接性。 间接性的实现，就是契约、接口或者门面/桥接模式。这些实践的使用，可以轻易让我们切换层次之间的实现，而使变动不扩散出去。
2019-12-13
CI/CD 方法论
CI/CD 的重要性Martin Fowler说过，“持续集成并不能消除Bug，而是让它们非常容易发现和改正。” 持续集成和持续交付作为敏捷开发的一种最佳实践，通过包括构建、部署、测试、发布流程的自动化，实现质量内建，让质量问题可以快速发现和消除，从而提升软件交付的质量和效率。 基本策略分支模型是CICD落地的源头，研发过程各角色间的协作方式以及研发过程内代码版本的流转方式都取决于分支模型。 首先划分环境。 划分环境后设计分支，注重开发和发布两个场景。 根据分支设计流水线，验证应该发生在全流水线里。 一般的分支模型 参考文献：《在阿里，我们如何管理代码分支？》《What is Trunk-Based Development?》《提升团队的微服务落地能力》
