我对设计的思考

前几天被人问如何作架构设计，当时准备不足，回答的不理想，因此想在这里把本身对架构设计的思考梳理一下。

做为一个程序员，我对编程有基本的信念：代码首先是给人阅读，而后顺便让机器运行。基于这个信念造成了我对设计的思考。若是你不认同这点，那么后面就没有必要看了。

首先，命名很是重要。某名宿说过，命名是计算机世界中最重要的两件事之一（另外一件事是缓存）。作设计首先要取名，名字可以表明系统的职责和功能，体现你对问题本质的理解。模块的设计、类的设计、接口设计、函数设计也同样。系统中每一个逻辑单元都应该有清晰的名字，若是你发现命名很难或者须要不少单词组合，那就说明你的设计出了问题：职责太多或者不够清晰。

第二，设计的本质是管理复杂度。业务自己的复杂度没法下降，可是能够把复杂的业务分解为不少较简单的子问题，而后再对子问题进行设计。对系统的分解须要遵循两个原则：一、分解后的子系统应该在逻辑上属于同一个层级；二、子系统在逻辑上应该彼此独立，互不影响。

你们基本都会作分解，可是分解的结果差异很大，主要是因为视角的区别。在我最开始作架构的几年，主要从技术视角考虑怎么作分解（追求代码的复用），设计很精巧，可是后期可维护性差。如今我会更多从业务视角出发（业务自己包含哪些部分，各部分是什么关系），不刻意追求复用，后期的可维护性很不错。我理解两种方式的区别在于，根据业务作的分解体现的是业务结构，只要业务不产生结构性变化，架构就会保持稳定；而出于复用目的作的分解体现的是功能之间的类似关系，不少业务上没有关系的功能被划分到了一块儿，致使当这些功能出现变化时很容易影响架构的稳定。固然，技术上你有100种方法经过加强扩展性来保证架构的稳定，代价就是复杂度增长，最终会愈来愈难以维护（我曾经架构过一个产品，各类奇技淫巧，逼疯了不少新人）。因此最好的办法是一开始就从业务入手，后面都是天然而然的事情了。

第三，程序=算法+数据结构。在架构层面上，数据结构和算法的设计也很重要。在数据结构方面，咱们须要思考系统包含哪些数据，这些数据之间是什么关系，数据在内存中是什么结构（线性表、Hash表、树仍是图），数据如何持久化（文件、数据库）。在算法方面，若是可以把业务问题抽象成经典的算法，这样就能够找到数学上已经证实有效的解法，并且还会增长代码的可读性。以前有个表达式解析器，须要判断变量之间的循环引用，我使用了经典的拓扑排序算法实现，很是简洁并且程序员都能懂。

第四，系统的可伸缩性、健壮性、可测试性、可维护性等非功能性需求也很重要，甚至在某些时候决定了项目的成败。好消息是，这些需求很是通用，因此有不少广受欢迎的开源项目供你选择，基本不须要你本身开发。可是你要很是克制你的技术狂热，只在真正有必要的时候才引入。记住一个原则，若是引入组件的复杂度超过你要解决问题的复杂度，那就别引入了。

最后一点，必定要关注产品价值和用户体验。产品若是因为价值或体验失败了，没有人会关注你的技术架构作的多么牛逼。