背景
前几篇文章中，我们介绍了两个与 “隐藏信息” 有关的编程技巧，
（1） “让主流程清晰”：尽可能少的在主流程中堆放不相关的内容。
（2） “提取工具”：组装更大的信息块，避免频繁的应对细节。
这两个技巧所做的都是，尽可能的少的披露内容，
减少阅读者一次感受到的信息量，目的是帮助阅读者抓住重点、看清脉络。
在展现信息时，要讲究策略，不要一股脑的席卷而来。
可是，这并不意味着，代码中该保存尽量少的信息。
相反我们得把业务知识想方设法，以各种形式 “固化” 下来。
代码中无法保存的，还应考虑其他形式。
下文我们来探讨几个常见的场景，看看我们 “遗失” 了哪些内容。
代码的局限性
我们知道，代码是执行过程的一种编码形式，
它最终交给机器运行，机器只要能按照步骤得到最终结果就行了，
代码中并不需要储存除了执行过程之外的其他信息。
然而，一个完整的业务逻辑，肯定不仅仅只包含过程信息，
还包括背景、设计意图、决策、解释说明，等等一系列内容。
这些内容是代码中不必记载的，也是最容易丢失的。
如果我们手头上只有代码，却没有任何与代码相关的说明，
修改这样的代码，风险是极高的，很容易出现各种意想不到的后果。
所以，一个 “为食用者着想” 的开发者，总是会惦记着代码的局限性，
想方设法将更多的业务知识保存下来，前人栽树后人乘凉。
文能补拙
有一句流传很广的说法 —— “好的代码本身就是文档”。
引发了很多误解。
本来这是人们对 “好代码” 的高度赞扬。
是想说 “好代码” 太容易理解了，简直不需要再另写文档了。
结果导致了很多初学者，为了彰显自己代码写的好，而故意不写文档。
要知道，有没有文档，跟代码写的好不好是两码事，
事实上，不写文档只会让代码更糟。
因此，勤能补拙是良训，
如果代码写不清楚，那就多补充一些文档，这才是专业的做法。
拆分
随着业务规模的增长，软件所需适用到的场景会越来也多，
代码量会越来越大，系统也会越来越复杂。
为了对复杂系统进行管控，“拆分” 子系统是一个很常用的办法。
但 “拆分” 却并不能降低系统的整体复杂度。
好比把一个团队划分为十个小组之后，
管理这十个小组，比直接管理所有成员，负担是变小了，
但团队作为一个整体来看，却是更复杂了。
所以，并不是拆分的越细越好，
因为每个具有独立边界的子系统，都得考虑自己如何与其他系统进行交互。
这会在无形中增加额外的沟通负担，整个系统所包含的全部信息量会为之暴涨。
用法说明
每一个提供对外服务的子系统，都有义务写明如何使用当前系统所提供的功能。
没有明确用法的软件服务，用户就会选择自认为便利的方式来使用，
这会增加服务提供方所必须覆盖的业务场景之数量。
一旦有人这样用了，以后就不得不继续支持。
其次，用户可能会以一种导致软件崩溃的方式来使用它，有意或无意的，
这虽然有利于我们发现漏洞，
但防御性编程会大大增加我们的业务复杂度，还得专门处理一些虚构出来的问题。
所以，对于一个软件服务而言，写明用户到底该如何使用它，是非常重要的。
这部分内容是通过代码无法领会到的。
结语
在编码过程中会发现有些内容，只用代码没办法交代清楚，
这时候就不应该吝啬笔墨了。
多写一些注释，多写一些文档，并不意味着我们写不好代码。
反而恰恰意味着，我们对代码的局限性有更深的自知之明。
最后，独立系统的 “使用文档”，经常被人忽视，
如果别人不知道如何使用的话，可能甚至都不知道系统提供了此项功能。
所以，好代码虽然会讲究信息披露的必要性，但仍然会传达出足够的信息，
给人一种 “想了解的都在那里” 的感觉。