懒人思惟

引子

其实能够起一个好名字，好比叫勤俭持家，惋惜勤俭不是个人爱好，持家并不是我所擅长，因此只能用我惟一的优势来为这篇冠名了。

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

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

总结

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