【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
前几天被人问如何做架构设计，当时准备不足，回答的不理想，所以想在这里把自己对架构设计的思考梳理一下。
作为一个程序员，我对编程有基本的信念：代码首先是给人阅读，然后顺便让机器运行。基于这个信念形成了我对设计的思考。如果你不认同这点，那么后面就没有必要看了。
首先，命名非常重要。某名宿说过，命名是计算机世界中最重要的两件事之一（另一件事是缓存）。做设计首先要取名，名字能够代表系统的职责和功能，体现你对问题本质的理解。模块的设计、类的设计、接口设计、函数设计也一样。系统中每个逻辑单元都应该有清晰的名字，如果你发现命名很难或者需要很多单词组合，那就说明你的设计出了问题：职责太多或者不够清晰。
第二，设计的本质是管理复杂度。业务本身的复杂度无法降低，但是可以把复杂的业务分解为很多较简单的子问题，然后再对子问题进行设计。对系统的分解需要遵循两个原则：1、分解后的子系统应该在逻辑上属于同一个层级；2、子系统在逻辑上应该彼此独立，互不影响。
大家基本都会做分解，但是分解的结果差别很大，主要是由于视角的区别。在我最开始做架构的几年，主要从技术视角考虑怎么做分解（追求代码的复用），设计很精巧，但是后期可维护性差。现在我会更多从业务视角出发（业务本身包含哪些部分，各部分是什么关系），不刻意追求复用，后期的可维护性很不错。我理解两种方式的区别在于，根据业务做的分解体现的是业务结构，只要业务不产生结构性变化，架构就会保持稳定；而出于复用目的做的分解体现的是功能之间的相似关系，很多业务上没有关系的功能被划分到了一起，导致当这些功能出现变化时很容易影响架构的稳定。当然，技术上你有100种方法通过增强扩展性来保证架构的稳定，代价就是复杂度增加，最终会越来越难以维护（我曾经架构过一个产品，各种奇技淫巧，逼疯了很多新人）。所以最好的办法是一开始就从业务入手，后面都是自然而然的事情了。
第三，程序=算法+数据结构。在架构层面上，数据结构和算法的设计也很重要。在数据结构方面，我们需要思考系统包含哪些数据，这些数据之间是什么关系，数据在内存中是什么结构（线性表、Hash表、树还是图），数据如何持久化（文件、数据库）。在算法方面，如果能够把业务问题抽象成经典的算法，这样就可以找到数学上已经证明有效的解法，而且还会增加代码的可读性。之前有个表达式解析器，需要判断变量之间的循环引用，我使用了经典的拓扑排序算法实现，非常简洁而且程序员都能懂。
第四，系统的可伸缩性、健壮性、可测试性、可维护性等非功能性需求也很重要，甚至在某些时候决定了项目的成败。好消息是，这些需求非常通用，所以有很多广受欢迎的开源项目供你选择，基本不需要你自己开发。但是你要非常克制你的技术狂热，只在真正有必要的时候才引入。记住一个原则，如果引入组件的复杂度超过你要解决问题的复杂度，那就别引入了。
最后一点，一定要关注产品价值和用户体验。产品如果由于价值或体验失败了，没有人会关注你的技术架构做的多么牛逼。
来源：oschina
链接：https://my.oschina.net/u/2394157/blog/1613973