“我到底在想什么？！？” 凌晨1:30分，我正盯着不到一个月前我写的一段代码
当时它看起来像是件艺术品，全部是可理解的，优雅、简单、让人叹为观止
这一切都不再了，明天是我的最后期限，数小时前我发现了一个bug
当时看起来的简单和逻辑再也说不通了
可以肯定的是，如果我写代码，我应该足以聪明到理解代码？ 经过了多次这种经历以后，我开始认真思考，为什么我的代码在我编写的时候很清楚、而当我数周或数月后回头看的时候，它们却那么费解
问题1，过度复杂的逻辑模型 为了理解当你间隔一段时间返回到你的代码、却发现代码难以理解的第一步，就是理解我们如何从心智上建立问题模型
你写的几乎所有代码都是尽量解决现实世界的问题
在你写代码之前，你需要理解你正试图解决的问题
这常常是编程里最难的一步
为了解决现实世界的问题，我们首先需要形成该问题的心智模型【注1】，以此作为编程意图
接下来你需要形成实现编程意图的方案模型，我们姑且称为语义模型（semantic model）
从来不要混淆你的编程意图和此意图的方案
我们倾向于主要考虑方案方面的东东，而常常忽略意图的模型
你接下来的步骤是形成可能最简单的语义模型
这是容易搞错的第二步
如果你不花时间去真正理解你正试图解决的问题，你将在写代码时被绊倒在模型上
另一方面，如果你真正考虑了你正尽量做的事情，你经常得到一个非常简单的模型，这足以让你掌握最初的意图
如果你想容易地维护简单的代码，就尽可能多些地消除意外的复杂性
我们正试图解决的问题是足够复杂的
如果你不必那么做，就不要把意外的复杂性增加进来
问题2，笨拙的把思想转化成代码 一旦你尽全力形成了最好的语义模型，那么就到了把它转化为代码的时候了
我们称之为句法模型（syntactic model）
你正试图把你的语义模型的意义转化为计算机能够理解的句法
如果你有非常不错的语义模型、而在转化为代码时搞砸了，那么在你需要在以后某个阶段回头修改代码时，你将比较痛苦
当你脑子里还有语义模型时，把你代码映射到语义模型是容易的
回忆起变量“x”实际上代表一条记录被创建的日期、而“y”代码记录被删除的日期，这是不难的
当你3个月后再回来看代码，你的脑子里将没有这个语义模型了，因此无法理解同样的变量名字
把语义模型转化为句法的任务就是尽量多地留下线索，让你在今后返回时，能够重建当初的语义模型
好了，你该怎么做呢？ 类结构和命名 如果你在使用面向对象语义，请尽量让你的类结构和命名靠近语义模型
领域驱动设计（Domain Driven Design）【注2】是在这种练习上投入了相当重要性的一种运动
即使你没有相信完全的DDD方法，你也应当非常小心地考虑类结构和命名
每个类都是你留给自己和其他人的线索，它帮助你在将来返回的时候重建你的心智模型
变量、参数和方法命名 尽量避免普通的变量和方法命名
不要把方法命名为“Process”，因为“PaySalesCommision”更有意义
不要把变量命名为“x”，因为它应当是“currentContract”
不要把参数命名为“input”，因为“outstandingInvoices“更好
单一功能原则（Single responsibility principle，简称SRP） SRP【注3】是面对对象设计原则的核心之一，关联着好的类和变量命名
它认为，任何类或方法都应该完成一个单一的功能，只能是一个单一的功能
如果你想为类和方法给出有意义的名字，那么它们需要有一个唯一的较好定义的目的
如果一个单一类从数据库读和写、计算营业税、通知交易客户并生成账单，那么你就可能无法给出合适的名字
我常常停留在重构类上，因为我总是努力取一个足够短的名字，以描述它做的每个功能
为了更多地讨论SRP和其它面向对象原则，可以参考我的博文《面向对象设计》
适当的注释 如果因为某种原因，你不能让代码变得清晰，你同情将来的自己，需要不得不做些事情，那就留下注释来说明你为什么不得不那样做
注释倾向于快速地变得陈旧，因此我宁愿尽可能让代码自描述，注释用来说明为什么你不得不那样做，而不是它如何做
问题3，没有足够的组块 心理学上的组块被定义是，把信息组块定位为单一的实体
那么这该如何应用到编程上呢？作为一名开发者，在你积累经验时，你开始发现你解决方案里反复出现的模式
极具影响的设计模式：《可重用的面向对象软件》是第一本整理和解释一些模式的书
尽管如此，组块不仅仅用在设计模式和面向对象
在函数式编程（FP）里，存在大量的著名标准函数具备这同样的目的
算法是组块的另一种形式（后续会更多）
当你合理地使用组块（设计模式、算法和标准函数）时，它让你停下来思考，你编写的代码是如何运行的、而不是考虑它做了什么
这缩短了你的语义模型（你的代码）和句法模型（你脑子里的模型）的距离
这个距离越短，你就越容易重建你的心智模型
如果你有兴趣了解更多FP里的函数，请移步到我的文章面向web开发者的函数式编程
问题4，费解的用法 目前，我们主要讨论了如何结构化你的类、方法和变量命名
心智模型的另一个重要部分是理解这些方法应该怎样被使用
再次强调，当你最初形成心智模型时，这是相当清晰的
当你后来返回时，就非常难以重建你的类和方法的、所有有意图的用法了
通常这是因为不同的用法散布在你的程序其它地方
有时候甚至出现在很多不同的项目中
我就是在这种情况下发现测试用例是非常有用的
除了相应地知道一个修改是否破坏了代码的明显好处，测试为你的代码提供了一整套的用例
你不必搜遍100个文件，只需看测试就能得到引用的全景
注意为了达到这个目的，你需要有一整套完整的测试用例
如果你的测试仅仅覆盖了一部分、而你认为测试是完整的，那么你后来将陷入困境
问题5，不同的模型之间没有清晰的途径 你的代码从技术角度看，常常是优秀的、非常优雅，但是从程序意图到语义模型、再到代码存在非常不自然的跳跃
考虑你选择的一堆模型的透明性是重要的
从程序意图到语义模型、再到代码的过程需要尽可能平滑
你应当能够看透对应到问题的每个模型的所有方面
多数情况下，最好选择特定类结构或算法不是为了它在隔离方面的优雅，而是可以连接各种模型，为你重建的目的而留下 一条自然的途径
当你从抽象的编程意图走到具体的代码时，你做的选择应该受到 你能够表现更为抽象模型 的清晰度驱使
问题6，发明算法 作为程序员，我们经常认为，我们在为了解决问题而发明着算法
事实很难是这样的
几乎所有情况下，已经有现成的算法可以被组合在一起解决你的问题了
像最短路径搜索法、字符串相似度算法、粒子群算法等
大部分编程是以正确的组合、选择现存算法来解决你的问题
如果你正在发明新算法，那么，要么你不知道合适的算法、要么你正忙于你的博士论文
总结 最后总结：作为一名程序员，你的目标是建立能够解决你问题的、尽可能简单的语义模型
把语义模型尽可能靠近地转化为句法模型（代码），尽可能多地提供线索，便于你之后无论哪个人看你的代码，都能重建像你最初脑子里的、相同的语义模型
设想一下，当你走过你代码的被照亮的森林时，你在身后留了面包屑
相信我，当你需要找到回去的路时，森林将充满了黑暗、朦胧和不详的预感
