守株阁

本文是如何写《复杂业务系统》和《我眼中的阿里经济体的中台架构演进》的续篇。 本文探讨到底不确定性和复杂性源于何处，并引出互联网业务系统的一种“可适应性架构”，适用于平台型业务系统。 定义问题 软件难写，是软件工程师的共同感觉。 特别地，对于中国的互联网公司的“业务团队”的工程师而言，“业务系统”在业务的复杂度堆积到一定程度以后，软件本身的“熵增效应”会特别严重：一个业务系统的内部会充满了难以理解的分层、堆积如山的 if-else 分支，以至于很多工程师都不愿意进入密密麻麻复杂逻辑深处，去做高风险的维护工作。但是，只要公司正常发展，业务总会越做越大/复杂，所以要维持系统的可维护性，成为了一门很重要的学问。 现实中的系统的高复杂度问题，可以简单表述为“不确定性矛盾”：需求具有高度不确定性，一直都在高速变化；而工程师高度倾向于确定实现（因为高度抽象、反复抽象的成本很高），所以具体的实现难以变更，这两种相反的特性难以调和。 其实我们现在遇到的困境，历史上发生过很多次，比如我们现代的很多软件工程理论，就是从历次的软件危机中诞生的。归根结底，软件之所以叫软件（Software），是因为相...

FROM：《关于中台的思考和尝试》 围绕中台的争议非常多，但是往往争议的原因是连中台这个概念都完全没有达成共识，可以说是毫无意义的争吵。在 12 月 20 日由极客邦科技举办的 QCon 全球软件开发大会 2020（上海站）上，车好多 CTO 郭东白博士发表了主题演讲《从中台技术谈架构师的独立思考能力》。由于演讲时间有限， 关于中台的思考没办法讲得非常透彻，本文是对演讲的补充，期望能与大家形成思想碰撞。识别文末二维码，可免费下载郭东白博士的主题演讲PPT。 中台的定义 我们的讨论先从定义中台这个概念开始。 定义中台我认为可以有两个角度， 一个是从中台本身的价值和出发点来： 中台是在多个部门之间共享的开发资源所提供的业务能力、数据能力和计算能力的集合；另一个定义从中台的相对定位来：前台是面向终端用户的一组业务能力，业务中台是对前台应用的抽象，提供多个前台业务之间共享的业务逻辑、数据和计算能力。 我想特别强调这个定义是相对中性的， 我们能够通过这个定义区分什么东西是中台，什么不是中台。有的中台定义严格来说不是定义， 比如说“中台是提升效率和加速业务增长的一种工具”、“中台是我们的战略...

引言 本文只是一家之言。 本文是一系列文章的缩略版本（完整版只写了个开头），尽量只讲具体的东西，如果有东西太干了，没有具体的“体感”，是作者的责任。 不喜欢看纯理论分析的可以跳到单一系统层次和模块设计（大多数人可能更加关注这一节，其实前面的部分更重要）。 几个很干的原则 解决复杂问题要用高级思维，不要用低级思维。 蚂蚁/ebay 等若干家企业架构师四大原则 - 听过的可以往下跳： 分治（其他所有原则都是从分治里衍生的） 分层 抽象 演化 solid 5 原则很重要很重要 -很多人读过，很多人可能没有读过，温故知新很重要。 注重过程质量，拿到结果质量。 业务系统为什么难写？ 纯粹的业务驱动：技术的输入和决策完全来源于业务同事，甚至只受业务摆布的团队，架构容易混乱 业务又不懂架构、业务又不懂功能点罗列的合理性，业务只会往技术团队身上扔需求。 怎么把需求和实现分门别类是技术自己的事情。 但技术人员如果一直都很忙，没有自己的空闲时间或者对设计洁癖的坚持，慢慢地就会养成“把需求翻译成代码，然后往老的系统里面扔”（混乱根源 1）的坏习惯- 问题：翻译只是普通的低级思维，不能解决很复杂...

一定要记得保留数字标题前缀，这样可以在目录里恰当地理解结构深度。 图例 红色代表变更/新增功能 蓝色/黑色代表原有功能 1、需求分析 1.1 原始需求 1.2 需求背景 1.3 需求收益 1.4 术语解释 名称 解释 例子 例子 1.5 流程分析 1.6 用例分析 1.6.1 业务用例分析 1.6.2 系统用例分析 2 功能性设计 2.1 交互设计 2.2 流程变动 2.3 领域模型变更 要有枚举变更、领域名词变更 2.4 数据模型变更 2.5 状态机变更 2.6 关键时序 对 sla 的需求是什么？写在时序的 Note 里。 2.7 接口变更 参考： 1. 《Google API Design Guide (谷歌API设计指南)中文版》。 2. github 的 REST API 注意 api 的风格、可扩展性、场景的隔离。 List Get Create Update Delete 接口要素 接口要素值 语义说明 path /api/v1/account_settings/reclaim_rules http method PUT ...

写在前面的话 强迫症是一种观念冲突，不能摆脱这种冲突，则人生的心境进退不得。 神经衰弱是文化发展带来的弊端。Civilization 等同于 Syphilisation。身心过劳，导致神经衰弱，也会治愈神经衰弱。 精神疗法的不切实际，来自于忘却回归自然的原理，滥用脱离实际、纸上谈兵的条条框框。一般街头流行的售药广告，把可怜巴巴的病人毒害得苦不堪言。 当今医学界过分注意物质因素，忽略精神因素。疾病在各方面表露出来的症状，是它自身各方因素综合作用的必然结果，并非神经衰弱加进去的。疲劳导致的痛苦不算神经衰弱。 神经质实际上是由过分看重疾苦，担心患病这种基本精神状态引起的。 用钝感保护自己，注意力不要过度集中，不要强制自己变得乐观。 哪些是长期趋势里一直存在的，我们如何将它分离出来，加以合理对待。 迷惘是无焦点而无法做选择，破除迷惘的方式是试错。 身入深山不见山是常态，不要纠缠于当时的感受，要明白真正的为人处世之道。 不以物喜不以己悲意味着鞍下无马，要把喜放掉，才能放掉悲。而且要先无喜才能后无悲，这个先后顺序让人难以破除人性的诱惑。 太执着于当下只会引发不清醒和迷信，自业自得，自作自受才...

什么是单元测试，什么是集成测试 单元测试是只测试一个特定单元的测试，如果你的测试需要启动多个层而不是只启动这个被测试单元，那它就是一个集成测试。 一种比较前沿的观点认为：访问代码、管理者代码、存储代码和业务代码里，只有第四种需要测试，其他的逻辑的正确性只要由顺序执行保证就行了。这这第四种测试，是不需要 mock 的，尽量使用 main 就能启动。这就要求把业务逻辑和输入输出解耦。和输入解耦比较简单，和输出解耦需要一定的巧思-把业务逻辑写成纯函数也许能达到这一目的。 而集成测试意味着我们要启动尽可能大的完整的程序，进行： - 功能测试 - 验收测试 - 端到端测试 mock object 历史上的 mock object 是为了 peel out 整个 framework，让测试变轻而设计出来的。但如果 mock 的配置比较繁琐，则 mock 仍然很重。 当一个对象的依赖的行为很难定制而需要定制的时候，mock 对象就登场了。在历史上，软件工程的语言里，关于什么是 mock、stub、fake 和 stub 有漫长的争论，它们的共同点是都是真接口的假实现。 mockito 已经完成...

Apache Maven Surefire Apache Maven Surefire 本身是一个测试框架。 Maven Surefire Plugin 和 Maven Failsafe Plugin 都是这个项目的模块。 Surefire 插件 Surefire 是在 maven 的构建生命周期里面，test phase 执行单元测试的插件。 Surefire 的意思是“完全，一定成功的”。任何单元测试失败，都会导致构建失败。 Surefire 跑测试失败，会在现场留下名如hs_err*的文件。 用法 这个插件只有一个 goal，就是 test。 因此，使用它都不需要配置什么 configuration 和 phase。 1234567<plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <ve...

分类 本日 明天 本周 本月 本半年 本年 个人+组织 换行换行 个人：需要消费的东西 个人：对别人的承诺/责任 个人：需要干掉的东西 个人：生活上的下一步 个人：需要掌握的技能 组织：基本任务 个人：基本功锻炼

何谓领导梯队 定义 领导梯队：英文(leadership pipeline)应该更合适，不同层级更像是一个管道，会流转会转弯。这个转弯非常重要，每个人不是通过走直线，而是需要通过转折完成转变。在每一层级都需要不同的工作技能、时间分配方式、价值导向。如果你不能很好地意识到这个转变，就不利于完成这个转变。在公司里面如果某个层级出现问题，这级管道堵塞了，那么剩下的都会出问题。因为人才培养除了自己努力，直接上级是起很重要作用的，不然会阻碍下级的提升，所以有一级管道堵住了后面就会没有水。 比较科学的组织结构，是Enterprise-BG-BU。 管理自己——管理他人——管理管理者——管理职能(FM)——管理事业部(BM)——管理事业群(BGM)——管理企业(EM) 德鲁克说过：没有能力或者不愿意因新职位的需求而做出改变。管理者继续沿用先前的成功方法二不能进化，几乎是注定要失败的。 德鲁克还说：管理本质上不是science（科学），而是practice（实践）。没有实践并不能真的学会。所以实践是关键。但理论框架体系的支撑也很重要，它决定了最终成就的高度。《领导梯队》提高了认知起点，不用在...

What is the best comment in source code you have ever encountered? [closed]