守株阁

会计科目 会计科目.xmind 财务报表 三大财务报表.xmind

刻戒于碑，铸法于鼎 软件特性、质量属性。 将两个元素以某种方式连接在一起，就形成了结构。 module component-connector 就是我们经常讲的系统交叉点 allocation 就涉及到我们的部署设计 每一本书都会讲到利益相关者，也就是 stakeholder。 主动撰写设计决策，承担设计职责。 软件之所以叫软件，是因为它灵活而易于变动。架构是软件里硬的部分，为变动提供了章法，也制造了约束-否则我们不用经常“对架构产生冲击”，而需要打破架构。 设计原则： 以人为本（能落地能产生价值的架构才是真的好架构） 推迟决策 善于借鉴 化虚为实 推迟决策不是推迟大的设计决策，要推迟的是细枝末节的决策。不要陷入舍本逐末的优化中，导致项目无法受控。 忽视前人的设计，是最低效的设计方法之一。所以寻找架构风格是很重要的。 设计思维模式： 理解：换位思考 探索：尝试各种结构组合，找到最能提升目标质量属性的那种组合。-大多数情况下，是我们手头最简单最现成的解决方案。 展示：用图、表、模型、原型来展示，探讨。原型应该尽量具有交互性，可以直接和客户评审。 评估：评估到底我们要做什么东西...

解决问题的过程，是探索的过程。 19 世纪 30 年代，英国工程师巴贝奇发明了差分机，用来计算数学用表。巴贝奇还构思了分析机，意图使用一般性方法，用来解决通用计算问题。巴贝奇自己还是英国科学学会会员，以及一位经济学家。巴贝奇使用齿轮和条杆来制造分析机，受到时代所限，始终无法落地，没有得到英国政府资助，没有继续下去。后来有长达一百年的时间里，人们转而使用模拟的方式解决问题。 图灵对计算机的贡献是制造了通用机。 冯诺依曼的贡献是制造了“一般性方法”，即编程。 实时计算的发展历程是：美军飞行员的训练需求诞生了旋风计算机，而后又产生了 SAGE 系统。这两个项目为美国的商用计算机行业，培养了大量程序员。而且使 IBM 认识到商用计算机的商业潜力，斥巨资开发了 SABRE 系统。 IBM 是靠生产办公机器起家的。 computer 最早是指计算员。计算机的发展序列为：哈佛马克一号，ENIAC 和 EDVAC、EDSAC（威尔克斯）、UNIVAC。个人计算机首先是阿塔利的“牵牛星 8800”，然后是苹果，苹果 2，丽萨（太贵而卖不出去），麦金塔（平价版 lisa）。 第一个革命性的通用操作系...

自序 领导者总是嘴上以人为本，但对待员工却弃之如敝履。 人的一生用在工作的时间是最多的。工作的经历-甚至为最好的一些雇主工作-令人动力尽失、丢掉本性，这样是不对的。 杰克韦尔奇和人力资源主管比尔康纳迪共同建立了广受赞誉的员工管理体系，严格按照绩效表现对员工进行排名，每 12 个月至 18 个月重新调配拔尖人才的工作岗位，同时还在纽约的克罗顿维尔建立了全球培训中心。 20-70-10 的绩效排名体系。最开头的人才会得到赞扬，最末位的人才要遭到解雇。 韦尔奇最著名的是他的六西格玛（six-sigma）。 谷歌的企业文化不提倡穿西装工作。 前言 为什么谷歌的原则也对你适用 “10 亿小时之前，现代智人出现。 10 亿分钟之前，基督教诞生。 10 亿秒之前，IBM 个人电脑发布。 10 亿次谷歌搜索之前…是今天早上” “用心才能让企业成功，心怀这种愿景，不让客户离开时不开心，我们也依此做决定，善待员工，不计成本。” 命令导向型、低自由度的管理方式非常普遍，因为这种管理方式下容易产生效益，需要耗费的精力较少，而且绝大多数经理都畏惧其他的管理方式。管理一个按指令办事的团队很容易。但是要想他们...

本文是如何写《复杂业务系统》和《我眼中的阿里经济体的中台架构演进》的续篇。 本文探讨到底不确定性和复杂性源于何处，并引出互联网业务系统的一种“可适应性架构”，适用于平台型业务系统。 定义问题 软件难写，是软件工程师的共同感觉。 特别地，对于中国的互联网公司的“业务团队”的工程师而言，“业务系统”在业务的复杂度堆积到一定程度以后，软件本身的“熵增效应”会特别严重：一个业务系统的内部会充满了难以理解的分层、堆积如山的 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 接口变更 参考： 《Google API Design Guide (谷歌API设计指南)中文版》。 github 的 REST API 注意 api 的风格、可扩展性、场景的隔离。 List Get Create Update Delete 接口要素 接口要素值 语义说明 path /api/v1/account_settings/reclaim_rules http method PUT q...

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

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