郑剑峰的个人博客

Markdown

相信现在应该没有人没听过markdown，如果你没听过，你该反思下，如果你没用过，建议你从现在开始尝试。markdown是一种基于文本的描述语言，什么意思呢，通俗的讲就是你只要靠键盘就能完成文章的排版，并且可读性很高，Markdown因为其超级简单的语法（十分钟就能入门），能够摆脱万恶的鼠标，友好的编辑界限，灵活的扩展性等特点迅速在开发人员间流行起来，成为文档编写首选工具，github的README文档默认使用markdown。

markdown主要是用来写文档，在word的时代，写文档对于开发人员就是折磨，“文档十分钟，排版一小时”是很常见的，不仅如此排出来往往还是一坨狗屎，有了markdown之后，情况就变了，你只需用md描述你的格式，具体排版就交给工具。

在写文档上，md描述的是文档的格式，但作为一门这么优秀的描述语言，可不仅仅能描述格式这么简单。

Markdown绘制流程图

我们怎么描述一个流程？用自然语言描述就是“A提交到B，B审批后流转到C，C审批后流程结束”，用流程编排工具就是在界面上拖拽各种节点将每个节点按照流程流转规则连接，用程序描述就是后台需要将流程信息结构化存储，并且借助流程引擎驱动流程。既然markdown是描述语言，能不能用markdown来描述流程，肯定是可以的，我们拍脑袋想一个语法：

背景

最近在重构一个框架的代码，在重构的过程中就在想一个问题，如何做单元测试，当然，这个问题不是如何使用JUnit的问题，而且如何使做单元测试更充分，如果你有时间写几千个测试用例，这个也许不是问题，但当你的系统足够庞大，而你的人力和时间有限的情况下，如何最大限度的完成单元测试。

天上是不会掉馅饼的，有的话也只会砸到天才，砸不到普通人，我们都是普通人，不是天才，据说天才们已经想到方案了睡觉的时候，程序能不能自动查 bug，让你在睡觉的时候自动帮你查bug。如果没有完美的方案，有没有退而求其次的方案。这个就是今天要讨论的主题。

单元测试主要解决两个问题

• 系统错误
• 业务错误