1.1.1　常见研发场景

为了让大家理解架构设计的作用，我们来看几个常见的研发场景。第一个场景是开发一个简单软件，比如开发一个论坛或博客，通常一个人就可以搞定。一个能力很强的资深软件开发人员，可以独立完成从需求到设计再到开发的全流程。在整个开发过程中，因为只有他一个人，不需要任何设计文档，只要他自己把思路想清楚，软件就开发出来了，开发速度也非常快。但软件上线以后，一旦开发人员离职，他的继任者就很痛苦了，因为继任者完全看不懂前任写了些什么。

你可能会认为，看不懂别人写的代码说明自己的水平不够。但摆在我们面前的最现实的问题是，代码都看不懂，何谈维护、修复Bug和添加新功能？几年后实在没法继续维护了，只能推倒重新开发。由此可见，如果软件无法维护，系统做得再好也没有用。

第二个场景要更复杂一些，软件项目需要五六个人开发。在过去，五六个人的项目很常见，类似这样的项目是怎么做的呢？如图1-2所示，项目启动之初，项目经理把所有人召集起来开会，开始分配任务：小魏做库存，小王做财会，芳芳做统计。每个人都分配一个模块，从需求到设计再到开发，都由一个人负责。任务分配好之后，不需要太多的沟通协调，每个人都各自独立去做自己的事情，因此开发效率也非常高。

图1-2　开会场景

然而，各个功能模块并不是相互独立的。所以，在开发之初，当需求都确定下来以后，所有团队成员需要首先做数据库设计，因为数据库是各模块唯一的接口。一旦数据库确定下来，大家在其上进行开发，很快就能完成任务并上线系统。

这是过去很常见的软件项目开发模式，虽然快，但问题也非常明显，那就是代码重复。各模块都是各自独立开发的，其中或多或少会有许多相同或相似的功能。但在开发过程中，我不知有你，你也不知有我，所以每个人都实现了一遍相同或相似的功能，并且各自的设计思路还不一样。一旦这些功能发生变更，日后的维护就极为困难。

随着软件系统变得越来越复杂，开发人员越来越多，软件开发过程中所面临的问题也越来越多。以往的开发模式之所以快，其根本原因是尽量避免了模块间的相互调用，但现在这些越来越难以避免了。安全性、可靠性、高并发等共性问题也越来越多，每个模块都要去应对，每个模块应对的思路还不同，这样的系统还能算作一个有机的整体吗？与此同时，系统结构变得越来越复杂，网络环境、应用部署、软件框架、分层架构，方方面面的问题都需要考虑。更关键的是，系统共性的难题也越来越多，每个模块都需要去应对系统性能、安全性、可靠性、高并发、大数据等一系列设计难题。这时，我们需要一个从全局角度思考问题、把整个系统整合成一个有机整体的人，这个人就是“架构师”。