如何写一手容易维护的代码
免责声明
程序员对抽象、设计可能会有不同的习惯。同样一个功能有人用发布订阅，有人用消息队列，他们都有自己的一套设计理念。最终是谁能说服谁的问题，哪一种方式都不是绝对正确的，就像本文一样。
内容有点偏意识流，不过总结的都是些很简单的东西。文中提到的诸多“本质”，应该会再写一篇来举例说明吧。
人类智商受限
人类的智商难以理解庞大而复杂的软件系统，所以我们尝试用抽象来设计软件，设法以人类的智商也可以理解庞大的软件系统。
抽象是什么
管理自己的磁盘时，都会建立类似 Work、Software、Temp、Repo …之类的文件夹。怎么分类文件夹最合理在这里不重要，重要的是分类文件夹前，肯定会进行的简单的设计。这个设计的思考过程我认为就是正在抽象。
举个不是很恰当的例子。我们不会为某一个 IDE 单独建立文件夹，来存放用它开发的代码文件。例如 Intellij Projects、Visual Studio Projects 。而是会尝试建立 Projects、Repo、Workspace 存放代码文件。这期间我们就是在抽象，把文件和具体的软件分离开，思考了这些文件的本质是”代码文件“，而非”某款软件的文件“。
抽象本质就是简化信息，是为了降低复杂度、是控制软件系统混乱程度的外在做功。
从三层架构开始思考
三层架构是一个很简单的，但抽象程度很高的模式。它可以解释大多数程序的组成：”有对外交互、有核心逻辑、有数据读写“。这就是它的高度抽象，把信息简化到了极致，所有程序都可以遵循三层架构模式写出来。三层本质是规范了代码边界，划分出三层边界：
- 用户交互层：接收“用户”的输入，向“用户”输出处理结果。
- 核心逻辑层：只负责程序的核心“算法”，如何处理数据。
- 数据交互层：妥协层，内存实现不了持久化，抽象出一个数据读写层代替内存。
代码设计的前期阶段，如何思考出一个模块的组成部分？三层架构给了我们一个优秀的示范。不需要思考功能的太多细节，全力以赴的简化功能的细节，简单直接的阐述功能的本质。
不过三层架构太抽象了，就像将「用户注册」抽象成「新增数据」，相当于没有细节。如果只从三层中学到了“把代码按照交互、核心、读写划分”的话，那实现细节还是会剪不断理还乱。只会套用三层架构范式，而不去思考功能本质的软件最终会难以维护，也许是屎山多是三层架构的原因（风评被害）。
最小人力成本
简单的东西却蕴藏大设计，架构大道反而在最简单的三层之中。只要适当的简化信息，边界划分的足够合适，架构最终会形成一个个聚合，开始有了领域驱动的味道。可难点就是边界如何划分的足够合适，信息如何简化才算符合抽象。
因为现实世界复杂的，软件系统的复杂度是不断熵增的。不变的设计总会有一天会遇到冲击。总会遇见两难抉择：重构还是硬怼？
例如我曾碰见的 getRowDef(rowIndex) ，起初这个方法是为了获取数据的类型定义，以此解析并转换数据内容。但后来 Excel 变的很复杂，我们需要根据内容来推断列定义。所以方法变成了 getRowDef(rowIndex, rowReader, totalLines, prevRowDef...)，多了很多参数，以便在方法内部推断此行的类型定义。变成了让人困惑的屎山代码：获取数据的类型定义，需要先读取数据，然后再拿定义去转换数据。理念上有了冲突，让人产生了困惑。但还是选择了硬怼，因为这样改动最省力，写好注释后也能让人理解。
看似上面例子重构一下成本也不大，但其实功能本质已经变了。也就是设计理念变了。类型定义和数据内容的关系变了。重构就要从类型定义和数据内容这种基层代码改起。结合实际工期限制，适当的抽象减轻维护难度就可以了。如果碰到设计瑕疵就要重构，反而会给自己增加压力，延后工期，浪费人力~~，失去工作~~。
《架构整洁之道》里提到：==“软件架构的终极⽬标是，⽤最⼩的⼈⼒成本来满⾜构建和维护该系统的需求”==。遇到设计瑕疵时，有重构的想法时，需要慎重思考自己新的设计，减少的维护复杂度和花费的精力相比是否值得。
代码设计
百科对抽象的解释是「找出事物的本质，剥离其它表象、杂质，最终形成一个概念」。
抽象的本质
务实的看，抽象可以帮助我们简化代码，封装复用、继承多态、接口声明。都是在抽象代码，以形成“某某功能”的概念，实现细节则是在具象（补完）这个概念。这个概念就是前文一直在提到的功能本质、设计理念等抽象的词汇。
使用第三方库时，遇到一些不清楚的方法，一般只需要在源码中找几个接口定义（注释）看看，或者阅读官网文档的 Api Reference 就能理解。这些框架都是作者的匠心之作，单从它们的版本发布就能略知一二，它们的更新维护通常都是非 breaks 的。屎山才会经常不停的重构，导致 breaks。
这些框架怎么做到的？虽然框架支持的特性多样且复杂。但框架作者依靠抽象简化了信息，思考本质。不论是修复 bug，还是新增功能，作者只需要确保框架的概念还是不变的。这里的概念相当于其抽象的出发点，或者本质。每次维护、更新只需要确定这个本质不会发生改变。
信息隐藏
理解抽象，彻底的理解什么是“简化信息”很关键。并非是单纯的精简代码，而是一种形意拳。精简代码只是其形。意在降低复杂度。
我在《代码大全》里看到信息隐藏时，意识到到这个东西可以和简化信息联系起来，更直观的解释抽象。我们降低复杂度、抽象代码、简化信息。最终达成的效果就是隐藏了代码所蕴含的信息。
结合一段代码，有点极端但简单地例子。直观的看一下信息隐藏是什么。
// domain
class User {
fun login(): Boolean {
// 核心逻辑：只有周一允许登录
return if(today() == '周一') true else false
}
}
// service
fun loginService() {
val user = getUser()
if(!user.login()) {
// 错误的
return "登录失败，失败原因：只有周一才能登录"
// 正确的
return "登录失败" // “我”不知道失败原因，因为原因被“隐藏”了
} else {
// ...
}
}
例子中，代码的边界体现在「今天是周一才能登录系统」这个核心逻辑。服务层不应该知道这个信息。只应根据业务对象的返回值来做判断，或者说我们隐藏了这个信息。
为什么”告知用户“「只有周一才能登录」的写法是错误的？因为核心逻辑层只返回了 false，没有说原因。服务层及更上层理应不知道原因，即使所有代码都是同一个程序员写的。
程序员应该克制，或者说欺骗自己。这样才能保持住代码的边界，即使告知用户「只有周一才能登录」是更好的用户体验，仅从代码设计来看，隐藏信息是首要的。
简单来说就是，“我”忘记了核心逻辑，业务对象只返回了一个 Boolean，只包含了“登录是否成功”这条信息。这样“我”的做法是「登录失败，但我不知道原因」就很合理了。
当然上边的例子有点极端。来点实际的例子，就像我们写 java，不用去理解 public void main() 背后发生了什么，只需要知道这是程序的主入口。这就是设计 java 语言的人，隐藏了信息，我们只需要往 main 方法里浇灌屎山代码就行了，降低不少复杂度。
简化信息，降低复杂度的本质，似乎就是信息隐藏。
依赖接口
再来理解依赖接口而非实现就很简单了，接口就是隐藏信息的集大成者，如果没有 go to implementation，就是在天然的在隐藏信息，达成：
- 这个接口的实现是哪个同事写的？
- 我不在意（除非要找个人背锅了）
- 这个接口的实现具体做了什么，怎么写的，用到了什么技术？
- 关我什么事。我只关注它可以达成什么效果，我要给它什么参数，它返回了什么。
- 接口调用出错了，这可咋办？
- 确认调用方式没问题。那抽空修复、替换下实现吧。
就算脱离了接口实现，软件代码也能被理解。这样说明了简化信息很成功，复杂度理所应当的被降低了。
边界与约定
想要理解领域驱动，理解限界上下文必不可少。直接看限界上下文会感觉很抽象。不过通过信息隐藏，可以很简单的理解、接纳限界上下文的理念。
约束与限界上下文
边界像是一种约束，只允许边界外知道边界内泄漏出的信息。例如登录失败的原因，只泄漏了 True 或 False，真正的登录失败原因，被我们隐藏起来了。
这种隐藏方式和我们在面向对象代码语言里的 private 私有特性密切相关。例如边界内的业务对象的 set 方法通常是私有的，不对外公开。这就是一种约束、或者隐藏。边界外只允许获取边界内公开的信息。
构成边界内/边界外的约束就可以理解为限界上下文。上下文内一个领域、一个聚合，都是一些很纯粹、完整的业务信息，因为他们被约束了，不会泄漏核心信息，不会被外界影响。上下文外则是服务层，应用层，包含诸多的技术细节等“噪音信息”。
约定先于配置
约定大于配置你可能在某些技术框架里看到过这个理念，可以理解为一种更轻量的约束。这种约定随处可见：
- 在
Spring中，我们依赖注入一个@Resource。一般是不会特意配置name的 。而是采用默认的约定，即按属性名称注入。 Asp Net Core会约定文件夹结构，如Controller、Views…HomeController.Index()会被”翻译“为/Home/Index路由等。
或者更通用的一种约定，客户端调用后端 REST 规范接口时，一般没有强制性的约束。意味着客户端无法确定接口的输入输出结构。这种情况多靠程序猿们之间的约定，如文档注释，甚至是口头传达。
这种约定看似需要我们多记住一些规则，增加了心智负担。但反过来想，如果没有这些约定，我们要做的工作是不是会更复杂，要显示配置很多东西，引入更多的技术框架，如 Swagger、Spring XML Configuration…
例子说的太多，有点偏上层应用了。回到约定的抽象意义。有时我们只想为特定的服务公开一些领域内的能力，但不可避免地泄漏了这部分能力给所有的服务，此时我们会定下约定：在注释里写上“只允许在 XXXXService 内使用此方法，所有程序员必须遵守此约定“。这条约定就成为了边界的一部分，为功能的抽象边界填砖加瓦。
总之，这些约定也可以形成边界。
后言
受限于个人表达水平以及技术尚未炉火纯青。我只能分享这点个人理解了。然后推荐看些 DDD 相关的文章，就算不用，知道 DDD 中的诸多概念后，对写一手容易维护的代码会有很大的帮助。