一个年老代程序员午后谈谈架构和架构师

转自：程序架道

写这篇文章的时候，我正坐在图书馆里，冬天的阳光透过宽大的玻璃窗户，撒在摆满了书架的地上，好久没有写文字了，突然有一种欲望：想谈谈架构和架构师。

当你提到架构两字的时候你首先想到的是什么，往往被关联到的是建筑，建筑架构的设计跟软件工程的设计的确很像，大家也都这样类比，甚至在英语中，建筑师 和 架构师 都是同一个单词 “architect”。但我觉得，软件的架构设计还要比建筑的设计复杂，软件架构是一个动态的，建筑不是。

说软件架构的设计是动态的，不觉得很贴切么，没有一成不变的架构，架构一直是在演进式的变化，以便更能服务好增长的业务而带来的需求。

架构设计，那设计是为谁服务的，是为应用程序系统服务的，那应用程序系统有什么样的需求，有两种需求：功能性需求和非功能性需求。

功能性需求，就比较好理解了，添加一个商品、修改一个商品、统计商品在一定时间段的销量报表，还有可能再给这些功能加上权限，这是功能性需求。表示的是，这个应用程序系统可以干什么。

非功能性需求，就是我们常说的是否可监控、可回退、是否具备高可用、高并发、高性能的特性，表示的是，一个应用程序在运行时的质量。

当然，还有一个更重要的需求，也是归在非功能性需求里面的，就是：快速安全的交付软件。

架构随着时间的变化演进着，人们在这方面的思考也在增加，于是，后来就有人发明了一种4+1的视图来描述架构。4代表的是4种视图，有逻辑视图、实现视图、进程视图、部署视图，1代表的是1个场景。

逻辑视图，是由研发人员来创建的，元素包含类和包，通过类和包之间的关系来实现依赖；

实现视图，由我们常使用的maven、idea等构建编译系统工具来实现，表示的是模块之间的以及组件之间的依赖关系；

进程视图，是一组运行时候的组件，他们之间如果发生关系就是依赖进程通信；

最后是部署视图，指的就是运行在机器上的进程了。最后通过业务场景来将这些视图关联起来。

依靠这样的模型可以便于说明架构，那架构的目标是什么呢，目标：“用最小的人力成本来满足构建和维护该系统的需求”。

那架构的价值是什么呢，其实先前我们在描述架构的需求的时候已经提到了功能性需求和非功能性需求，架构的价值就是对应这两种需求的，功能性需求--行为价值，非功能性需求-架构价值。哪种价值最重要呢，记住：架构价值最重要。

好了，该架构师登场了。

我们主要从两个方面来谈谈架构师，架构师是什么样的人，架构师的职责。

架构师是什么样的人，是能力最强的一群程序员，而且也必须坚持一直做程序员。他们的代码量虽然不多，但必须承接编程任务，如果不亲身承受因系统设计而带来的麻烦，就体会不到因设计不佳所带来的痛苦，随而会逐渐迷失正确的设计方向。

程序员最常接触的就是产品和业务人员，产品给你提需求，你陪产品聊需求，需求越聊越清晰。

产品人员关注的是需求对应的功能有无按照规范实现，扩展性、稳定性都是研发人员更关注。

业务人员提出业务期望给到产品人员，待系统上线后，业务人员开始推广业务，业务人员更加不会关心系统稳定性、扩展性。

但是，恰恰系统的可监控、可扩展、稳定性才是系统架构的基础。

第一职责

既然架构和建筑常来类比，我们继续打个比方。大家去楼盘买房，关注的都是户型，朝向，绿化，几乎没有人关心到这个大楼的的地基和主体结构。

而我们的架构的架构价值正如大楼的地基一样重要，因此架构师的第一个职责就是要关心架构的质量属性，也就是架构价值所强调的。乃至，需要持续地，从公司长远利益出发与其它非研发部门做抗争。

工作中常常有类似下面的三种程序员

程序员A：“我们可以未来再重构代码，产品上线最重要”

程序员B：“在工程中容忍糟糕的代码存在，可以在短期内加快工程的上线速度，未来这些代码会造成一些额外的工作量，但是并没什么大不了”

程序员C：“我的工作是且仅是，按照需求文档编写代码，并且修复任何BUG”

第二职责

那么，架构师的第二个职责就是创建一个让需求功能实现更容易，修改更简单，扩展更轻松的软件架构。记住精力守恒定律：“你投入到程序中的精力越多，用户使用时遇到的麻烦和折腾的精力就会越少”。

第三职责

做一个演进式架构师，这样的架构师的职责就要分别从愿景、同理心、合作、适应性、自治性、治理、愿景分别去考虑问题。

愿景：确保在系统级有一个经过充分沟通的技术愿景，这个愿景可以帮助你满足客户和组织的需求；

同理心：理解你所做的决定对客户和同事带来的影响；

合作：和尽量多的同事进行沟通，从而更好地对愿景进行定义、修订和执行；

适应性：确保在你的客户和组织需要的时候调整技术愿景；

自治性：在标准化和团队自治之间寻找一个正确的平衡点；

治理：确保系统按照技术愿景的要求实现；

注：文中漫画来自网络