简介
本文主要来自对阿里巴巴高级技术专家张建飞 公众号文章《从码农到工匠》的梳理和总结。
作为技术人员，我们不能忘记我们技术人的首要技术使命是治理软件复杂度。
如何定义复杂性
在《人月神话》里，作者把复杂性分为两种：
- 本质复杂性（Essential Complexity），指的是你要解决的问题本身的复杂性，是无法避免的。
- 附属复杂性（Accidental Complexity），是指我们在解决本质问题时，所采用的解决方案而引入的复杂性。在我们现在的系统中，90% 的工作量都是用来解决附属复杂性的。
比如做一个电商系统，成本是多少？可能几千块，也可能很多亿。如果你理解这个的答案，那意味着比较理解当前软件编程的复杂性问题。因为软件系统的复杂性会随着规模急剧上升。
降低软件复杂性的一般原则和方法 斯坦福教授、Tcl语言发明者John Ousterhout 的著作《A Philosophy of Software Design》
子模块的复杂度Cp乘以该模块对应的开发时间权重值tp，累加后得到系统的整体复杂度C。也就是说，即使某个模块非常复杂，如果很少使用或修改，也不会对系统的整体复杂度造成大的影响。子模块的复杂度Cp是一个经验值，它关注几个现象：
- 修改扩散，修改时有连锁反应。
- 认知负担，开发人员需要多长时间来理解功能模块。
- 不可知（Unknown Unknowns），开发人员在接到任务时，不知道从哪里入手。
互联网行业的软件系统，很难一开始就做出完美的设计，通过一个个功能模块衍生迭代，系统才会逐步成型。对于现存的系统，也很难通过一个大动作，一劳永逸地解决所有问题。系统设计是需要持续投入的工作，通过细节的积累，最终得到一个完善的系统。因此，好的设计是日拱一卒的结果，在日常工作中要重视设计和细节的改进。
组织层面
- 不管你们有多敬业，加多少班，在面对烂系统时，你任然会寸步难行，因为你大部分的精力不是在开发需求，还是在应对混乱。造成这种局面，我们的技术管理者，我们的TL要负有主要责任。说的重一点，是工作上的失职，这种失职主要体现在两个方面，一个是技术不作为，另一个是业务不思考。
- 技术人员的疲于奔命，内因上是由于上面分析的团队技术味道的缺失，外因上主要是PD的乱作为。
架构设计
分模块
Unix操作系统文件I/O是典型的深模块，以Open函数为例，接口接受文件名为参数，返回文件描述符。但是这个接口的背后，是几百行的实现代码，用来处理文件存储、权限控制、并发控制、存储介质等等，这些对用户是不可见的。
与深模块相对的是浅模块（Shallow Module），功能简单，接口复杂。通常情况下，浅模块无助于解决复杂性。因为他们提供的收益（功能）被学习和使用成本抵消了。以Java I/O为例，从I/O中读取对象时，需要同时创建三个对象FileInputStream、BufferedInputStream、ObjectInputStream，其中前两个创建后不会被直接使用，这就给开发人员造成了额外的负担。默认情况下，开发人员无需感知到BufferedInputStream，缓冲功能有助于改善文件I/O性能，是个很有用的特性，可以合并到文件I/O对象里。假如我们想放弃缓冲功能，文件I/O也可以设计成提供对应的定制选项。
业务逻辑和技术细节的分离
应用架构之道：分离业务逻辑和技术细节架构始于建筑，是因为人类发展（原始人自给自足住在树上，也就不需要架构），分工协作的需要，将目标系统按某个原则进行切分，切分的原则，是要便于不同的角色进行并行工作。
作为架构师，我们最重要的价值应该是“化繁为简”。架构师的工作就是要努力训练自己的思维，用它去理解复杂的系统，通过合理的分解和抽象，使那些系统不再那么难懂。
六边形架构、洋葱圈架构、以及COLA架构的核心职责就是要做核心业务逻辑和技术细节的分离和解耦。
业务逻辑抽象
按照Wikipedia上的解释，抽象是指为了某种目的，对一个概念或一种现象包含的信息进行过滤，移除不相关的信息，只保留与某种最终目的相关的信息。例如，一个 皮质的足球 ，我们可以过滤它的质料等信息，得到更一般性的概念，也就是 球 。从另外一个角度看，抽象就是简化事物，抓住事物本质的过程。
OOP可以看作一种在程序中包含各种独立而又互相调用的对象的思想，这与传统的思想刚好相反：传统的程序设计主张将程序看作一系列函数的集合，或者直接就是一系列对电脑下达的指令。
当发现有些东西就是不能归到一个类别中时，我们应该怎么办呢？此时，我们可以通过拔高一个抽象层次的方式，让它们在更高抽象层次上产生逻辑关系。比如，你可以合乎逻辑地将苹果和梨归类概括为水果，也可以将桌子和椅子归类概括为家具。但是怎样才能将苹果和椅子放在同一组中呢？仅仅提高一个抽象层次是不够的，因为上一个抽象层次是水果和家具的范畴。因此，你必须提高到更高的抽象层次，比如将其概括为“商品”。
在程序设计中，也是一样，如果在一个类或者一个函数中涉及过多的内容和概念，我们大脑也会显得不知所措，会觉得很复杂，不能理解。将一个大方法，按照逻辑关系，整理成一组更高层次的小而内聚的子程序的集合，那么整个代码逻辑就会呈现出完全不一样的风貌，显得干净、容易理解的多。
分层是一种常见的根据系统中的角色（职责拆分）和组织代码单元的常规实践。
写复杂业务逻辑的方法论
过程分解和对象建模相结合
”能力下沉“
一般来说实践DDD有两个过程：
- 套概念阶段：了解了一些DDD的概念，然后在代码中“使用”Aggregation Root，Bounded Context，Repository等等这些概念。更进一步，也会使用一定的分层策略。然而这种做法一般对复杂度的治理并没有多大作用。
- 融会贯通阶段：术语已经不再重要，理解DDD的本质是统一语言、边界划分和面向对象分析的方法。
指导下沉有两个关键指标：
- 复用性，复用性是告诉我们When（什么时候该下沉了），即有重复代码的时候
- 内聚性，内聚性是告诉我们How（要下沉到哪里），功能有没有内聚到恰当的实体上，有没有放到合适的层次上（因为Domain层的能力也是有两个层次的，一个是Domain Service这是相对比较粗的粒度，另一个是Domain的Model这个是最细粒度的复用）。
《能力陷阱》
发展人际关系让你觉得卑鄙，虚伪？当我们把人际关系定义为本质上是为了实现自我利益时，甚至有些肮脏时，会限制我们的领导力，限制我们的发展前进，限制我们扩展视野，会阻碍我们了解新想法、发展自己其他方面才能的机会。
Be true to yourself or Shape-shifters （”坚持做自己”，还是”随机应变“）? 对于那些“坚持做自己”的人，作者说你要先知道那个You的定义是什么，是过去的“你”，先现在的“你”，还是未来的“你”呢？是那个固步自封，不敢改变的你，还是那个越来越圆融，知道如何应对变化，可以随机应变的你呢？ 所以，坚持做自己很多时候也是自己欺骗自己，不敢跳出舒适圈，不敢做出改变的谎言。Shape-shifters（随机应变者）是指那些很自然可以适应新环境的人，他们并不会产生一种觉得自己很虚假的内疚感。“随机应变者”有一个核心的自我价值观和目标，他们不担心转变自己会对自己的信仰造成影响。
时间是有限的，越是在最忙的时候，越需要空出一些时间来思考做这些事情的原因和目的，不能一直闷着头做。时间安排好，并不是一件特别困难的事。领导者，应该把注意点放在一些非常重要的事情上。然后，其它的时间都要用来自我提升，而不是那些“没有回报的事情”。就是要多花时间在自我提升（学习，写作，分享）上，多花时间对外产生连接，拓展人际网络，扩大影响力，吸引更多人才，从而为团队和组织带来更大贡献