纸上设计的利弊

纸上设计看起来容易做起来难，它就像良好的代码质量一样并不会对最终输出的程序有什么显性的帮助。

良好的代码质量只有在程序后期才能显现出来，前期会觉得为了质量会让编程更麻烦，我们所要做的就是让编写高质量的代码变成我们的习惯，写出又快又清晰的代码。比如将很多方法和实现，能用抽象接口描述出来的，就用接口描述出来。

同理，纸上设计，以及各种单元测试、重构、设计模式、设计原则也是一样的，纸上设计的本质就是UML图，但是UML图需要花费更多的时间去掌握，用例图、类图、时序图等，即使掌握了UML图，其实全部实践的机会也并不多，而纸上设计是UML的简化，它和我们目前的框架搭配得很好，我们只需要养成纸上设计的习惯就可以了。

为什么做纸上设计

做项目能力的上限，就是能够应付多大的项目。如果能做一个项目在代码量10W行而没有崩溃，并且运转良好，那么再做个1W行左右的项目就会更容易，甚至能做出更精简的1W行项目。这就是做项目的能力。

做项目越大，里面的信息量也就越多，直接看代码就不可行，所以需要一个能描述项目结构的工具，这个工具就是UML，UML是很强大的项目描述工具，能够描述任何代码语言的逻辑，不过这也意味着，UML的抽象程度也更高。

而用这套框架配合的简化的纸上设计图，能够比较好的沟通交流，比较好的描述当前项目、能够进行设计、容易维护，既能满足大部分的团队，又能满足个人开发的需要。

一般情况下，使用这套架构需要一张总览图，各种具体实现的图。总览图统一团队成员对于项目整体架构的认知，具体实现图帮助开发者梳理开发逻辑。