守株阁

业务研发面对的问题 稳定的业务模式 不稳定的需求 业务对交付的渴望 假设 命名规范（《clean code》） 面向对象设计（SOLID原则、贫血/充血模型、设计模式） 系统要拆分 流程控制系统与领域系统.drawio 每一个用例（解决的一个问题）都由访问逻辑和执行逻辑组成。访问逻辑负责用例执行的顺序与分支，并调用执行逻辑完成完整业务逻辑。 访问逻辑由单独的交易系统负责。执行逻辑由个子系统负责。 工程要拆分 三层架构 + 洋葱架构 代码要拆分 业务代码：描述核心业务逻辑的代码，核心是保持业务的流程及业务状态的一致性 领域对象与领域服务，不得对外部有任何依赖（工具类除外） 最核心的几个抽象： 校验：参数有效性校验、参数的业务属性校验。在进入正常业务逻辑代码前，完成所有的校验工作。 异常：业务异常：所有不符合业务逻辑而产生的异常。 系统异常：因为程序本身or依赖产生的异常。 所有的异常第一位runningtime异常。 数据: 业务数据：保存领域对象状态的数据。 非业务数据：过程数据。业务的核心流程中，只对业务数据的持久化负责。 参数：任何时候，任何方法的参数都需要...

调试的时候的断点 Suspend Policies Specifies whether to pause the program execution when the breakpoint is hit. Non-suspending breakpoints are useful when you need to log some expression without pausing the program (for example, when you need to know how many times a method was called) or if you need to create a master breakpoint that will enable dependent breakpoints when hit. The following policies are available for the breakpoints that suspend program execution: All: all threads are suspended when...

前言 本文是《架构随笔》系列的第五篇，也是它的收官之作。 架构的定义 架构是一个界定不清的东西，我们很难讲清楚哪些东西是架构，哪些东西不是架构。但软件行业里其实人人都在搞架构，软件设计就是架构本身。 架构这个词出现得很早，有些人认为是 NASA（也可能是NATO） 发明的。最早的架构定义就是描述软件的结构而已，但现在已经没有多少人谈论他们定义的“软件架构”了。工程师很难以克制描述复杂结构的原始冲动，但描述复杂结构的普世标准并不存在。大家常见的各种定义，翻来覆去地重新讲着“软件架构是软件结构的顶层设计或者抽象设计”之类的话。即使是这种软件架构的定义，也并不为所有人都接受。汗牛充栋的架构书籍里有各种各样的观点，有的进一步把软件架构视作一堆组件和交互的设计，有的则把软件架构视作架构师主观意图的体现。把自己当作架构师的人们，着迷于把软件里的“不变与抽象的部分”和“易变与具体的部分”分离出来，把前者当作架构。架构师们是如此地热衷于做这样一件事，以至于有些人认为架构设计好了就解决了基本问题，设计不好通常是因为架构不好。于是很多人开始刻舟求剑：从某某颗粒度开始的设计应该叫概要设计，从某某颗粒度...

每个人都应该知道的操作时间 出处：《每个程序员都应该知道的延迟数字》

Java Java 8 Lambda Java 8 Lambdas - A Peek Under the Hood What does $$ in javac generated name mean? lambda 表达式并不总是持有外部 enclosing object 的引用，如果它不访问任何外部变量，即不持有这样的引用。只要设计一个对比实验，就会发现引用过外部变量的lambda实例才会产生一个 arg 的隐式参数引用。而内部类内部总是含有一个this$0。 lambda表达式是词法作用域的-意思是不产生新的作用域，不产生任何shadowing问题。它可以无缝访问外部作用域的东西，就好像从一个 if block 里访问一个方法里的其他变量一样。但，同样地，不能声明新变量。

如何摆脱懒惰？ 懒，其实只是一个表象，它不过就是「缺乏行动力」的另一种说法而已。 多巴胺的四条回路 回路1-运动回路 回路2-运动回路 回路3：中脑-皮层通路，主要跟决策和行为控制有关 回路4：奖赏回路 中脑-皮层通路 中脑-皮层通路，调控的是我们「做出决策」「选择行动」的动力。当这条回路中多巴胺的浓度超过某个阈值时，我们就会更倾向于「去行动」。反之就容易犹豫不决。 而奖赏回路，调控的是我们的「动机」强度。当它被外部反馈所刺激、激发多巴胺分泌时，我们就会产生「我想做某事」的动机；反之就会感到没有动力、对一切都失去兴趣。 所以，行动力强的人，最主要的原因，是他们大脑中自主产生多巴胺的能力较强，与此同时对多巴胺的阈值足够高，因此他们很容易从外部的反馈中得到激励，反过来，他们也不容易对激励感到「疲劳」或「过载」 —— 甚至，如果一段时间不从外部反馈得到激励，他们会感到无聊、烦躁、打不起精神…… 有没有发现，这其实跟「上瘾」有类似的情况？其实你可以理解为：这就是一种良性的、对「行动」的上瘾。只有不断获取外部的反馈，他们才能感受到自我的价值和意义感，一旦停下来，就很容易感...

引言 企业最根本的竞争优势既不是来自资本实力、发展战略，也不是来自技术，而是来自团队协作，因为团队协作能力是非常强大而且弥足珍贵的。 很多领导者认为，让团队所有成员齐心协力实际上是不可能做到的。 由于团队是由具有各种缺点的人所组成的，这样团队就不可避免地带有其先天缺陷。但这绝不是说团队协作注定要失败，恰恰相反，建立一支强大的团队既切实可行又相当简单，但是却需要克服困难才能做到。 第一部分 寓言 故事背景 硅谷的概念更取决于公司的文化特征。 两年对于一家科技创业公司来说，可能就是其从诞生到灭亡的全过程。 团队出问题的迹象：管理层相互倾轧，团队毫无团结友爱可言，大家对这种情况心照不宣。每项工作似乎都要花费很长时间才能完成。 在硅谷工作是不流行穿西服。 凯瑟琳在团队建设方面有惊人的天赋。 凯瑟琳几乎什么都没做，只是旁听团队会议，进行记录。凯瑟琳有如下几段经历：在军队打滚过，后来嫁给一位篮球教练，然后入读了三年夜校，后来在一家日美合资企业任职，迅速成为首席运营官。 大多数程序员都被他们的知识弄得麻木不仁，好像认为只有编程和产品设计才能使公司腾飞。 管理者不需要成为业务的专家，也可以管理一...

亚马逊成长战略研究 FROM：《【案例】亚马逊成长战略研究》 对于亚马逊来说，考虑到其电子商务的特质（零售+互联网），业务拓展、投融资、物流基建和技术研发对其持续增长起到最强的内在推动。由于电子商务的高固定成本与规模经济本质，持续发展的唯一方式就是不断的扩张业务，以达到成本下降，摊薄固定成本，实现规模收益的目标。当企业达到一定规模时，自建业务所需的成本往往将超过收购业务的成本，这时收购成为企业在对应时间点上继续发展的重要选项。而电子商务的本质是零售供应链的进化，这种进化依托于更快、更好、更精准针对的客户体验，物流体系是否完备，是电子商务企业是否能够决定性持续满足客户需求的基础所在。同时，技术能力决定了企业运营的效率，减少内部损耗和浪费，同时为向更积极、享受高估值溢价的产业延伸乃至最终转型提供依托。 边际效应低意味着马太效应高。 做电商强依赖于物流能力。 亚马逊的业务扩张从两个维度分别延伸，即地域扩张和品类扩张，两者同时对其营收与利润的绝对值和结构造成影响。在地域扩张方面，亚马逊不单推广国际化，将成熟的模式拓展到海外市场，扩大营收规模，摊低运营成本，获取新的市场份额和客户群体...

架构演进之路，路漫漫其修远兮 架构关乎不变的顶层设计抽象。 架构关乎组件（元素）、交互（连接器）、功能（function or feature）、约束（constraint 面向当前、未来-下一场景、下一个规模、下一个地域或国家） 洋葱架构的另一种解读 系统是洋葱，看似有边界，但是每次改动总是端到端，过程让⼈人泪流满⾯面。 系统的本质 功能与质量量的结合体：功能是核心价值 + 质量实现增值或保值。 系统的复杂性 过程与过程数据 过程与过程数据.drawio 易变性 系统复杂度.drawio 系统复杂度 = 功能的数量 * 功能的过程 《人月神话》：本质复杂度(Essential Complexity)和偶然复杂度(Accident Complexity)。 解法 分离业务复杂度和系统复杂度。 回归面向对象的本质，重拾抽象思维的价值 维护效率曲线.drawio 三种编程范型.drawio 领域驱动设计 战略设计 领域驱动设计-战略设计-一般过程.drawio 需求分析 需求分析.xmind 词汇提取 知识提取.drawio 领域语⾔定义-合理的上下⽂和领域划分 顺序-...

原文链接：《Becoming a Better Writer in Tech》