懒人思维

引子

其实可以起一个好名字，比如叫勤俭持家，可惜勤俭不是我的爱好，持家并非我所擅长，所以只能用我唯一的优点来为这篇冠名了。

8月伊始，我们启动了一个只有四个人的开发小组。这个小组主要负责部门未来的 micro service 的探索和研发。其中一个组员是一个硕士实习生。为了减少学习成本，选择了nodejs作为开发语言（大家都比较熟悉 js）。在开发的过程中，我们会对任何技术问题进行广泛和深入的讨论。有些问题引起了我的思考。譬如这篇文章即将叙述的，关于设计，流程，优化的一系列问题，我稍微归纳了一下，发现很多问题都可以用懒人思维--能不做就不做来回答。对于这些具有一定的共性，而且能稍微引起一点思考的东西，写下来是很有必要的。

能不做就不做

对于工作，敬业的我们肯定不能秉持 能不做就不做 的想法。 但是，编程却不一样。

当我们开发一个功能的时候，我们可能会接受用户的输入，输入需要校验，需要格式化，需要存储在一个应用程序并不关心的地方。其中的逻辑和流程往往复杂而无序，通常都会需要一个详尽的文档来解释其中的缘由。而说明良好的注释则会更好的帮助阅读者理解程序的含义。这通常比一个独立于程序的文档更加来的有效。

下面就从注释开始，慢慢的将这些思考展现出来。

注释

需要很长的注释吗？

一般来说，大段的文字容易让人失去耐心。而且，由于注释内容可能距离它想要说明的代码距离很远，不方便对照查看，这样的注释也就失去了作用。所以最好的办法其实是，在一大段代码的最开始，简单的说明大概的功能，或者流程。具体的说明，可以转移到具体的需要注释的代码处。

注释是代码的辅助说明

不要试图给不了解相关技术的阅读者提供类似教程的注释，除非，你要注释的代码确实是示例代码。
有些程序员喜欢加一些类似技术性说明的注释，比如

//Close the db connection
connection.close();

诚然，不了解数据库关闭机制的阅读者会从这个注释中受益，但是注释不应该成为繁琐的教程。即使阅读者真的需要这样的提示，那也应该去对应地技术文档中获取需要的知识。

数据校验

有些时候，我们需要对即将存入数据库的数据进行校验，比如，我们想要存入一行学生信息（好吧，很俗套）

{
 name:'小明',
 gender:'0',
 grade:'3'
}

其中，gender 和 grade 分别是 gender 表和 grade 表的主键，在 student 表中， 这两个都是外键。
好了，问题来了，我们是否应该在存入信息之前检验这两项的合法性。

我的建议是，不用，即使我们不检查，数据库也会保证错误的数据不会被存储。如果我们想要返回确切的错误信息给用户（比如，性别不合法，或者年纪不合法），大可以在保存失败后再去验证--不错不查。

两种方式的比较

预先检验合法性，需要查询数据库最多三次，查询性别是否合法，年级是否合法，全部合法则存入数据。当出现错误时，则是查询了两次。
不错不查，则最多检验三次，而通常只需要一次存储就完成了。

而且，实际的应用场景下，很少会发生这样的错误，因为这两项数据往往是由下拉列表形式提供给用户选择的，用户犯错的机会基本是不存在的。也就说，出错其实是小概率事件。对于小概率事件进行广泛式的防御会消耗不必要的系统资源，而且，程序的复杂度也会上升。这样的程序，可能会使这个样子

validator.verifyGender(gender);

validator.verifyGrade(grade);

... 其他的验证

student.save();

验证的逻辑和正常的流程（读取，转化，存储）混杂在一起，对于后期维护，升级是一个巨大的挑战。

而不错不查呢？

return  student.save();

只需要在正常流程之外或之后，监听是否有错误出现，然后再逐步处理。也就是说，正常流程和错误处理完全分离了。整体的流程变得清晰，易于理解。

错误处理

当错误出现的时候，我们一般都会选择返回详略得当的信息给用户。

• 非常详细
  这样的信息一般都会包括错误码，信息，甚至错误出现的位置和程序调用栈。

• 非常含糊
  一般只会区分错误的类型，譬如，客户输入错误，服务器错误，等等。

详略水平，取决于用户的类型

如果直接用户是终端用户，那么信息就不能太详细，因为这样的信息很容易被用来窥探后台逻辑，而且，对一般的终端用户来说，这样的信息毫无用处。 某些项目经理认为详细的信息有助于分析错误，但是从终端的返回信息来分析错误往往是低效和不准确的，还不如直接去查看日志文件有效。

不应该包括类似使用指导的信息

有时候，我们天真的在信息中加入类似下面这样的指导。

grade should be a number from 1 to 6

这样的信息不应该出现在错误返回中，而是应该出现在使用文档，或者前端页面提示中。使用简单的提示信息，既能很好的隐藏后台细节，也能降低后台管理错误信息的难度。

试想，如果对于错误输入的返回都是类似

grade is invalid

那么，完全可以使用错误信息生成函数/或者同一个错误类来为每一个输入错误生成错误返回。这一部分逻辑也就可以独立出来了，同样，管理和升级的成本就变得可以接受了。

总结

以上都是一些零散但是有用的总结，很多问题到了最后都变成了设计思想上的碰撞。争论还在继续。而这片文章也会持续的记录那些沉淀下来的弥足珍贵的东西。