软件架构师的误区

在现实中，我们会发现很多从业人员对软件架构的认知有着明显的局限和偏差，具体体现在以下几点。

误区一：不知道架构与设计的区别

虽然许多从业人员的头衔为“架构师”，但是他们并不能回答下面一些问题:
☆系统架构与设计有区别吗？区别在哪里？
☆什么样的人能满足系统架构师的要求？
☆什么样的人能满足设计人员的要求？

一般地，架构师都是技术出身，他们可能长期从事过编码、设计领域的工作。很自然，他们可能认为设计、编码工作就是软件架构的一切。但是真正的构架师必须有长期的工作经验，并在系统化的提升之后才可能成为合格的构架师。他们需要考虑商业概念、商业运作、系统结构、结构优化等这些更为宏观的方面，然后选择那些最经典的实践参考模型，才能构建出合格的的软架构。

误区二：不知道系统架构该如何做

让我们回到日常的软件系统活动中来。其实通过一些实践，我们已经逐步建立起一些对软件架构及设计活动的认知。直觉和经验告诉我们，一个软件系统或软件架构在构建之处就给架构师留下充分的创作空间。但是，一个单纯为了一系列功能的实现而构建的架构，还不能称作严格意义上的软件架构。一个真正意义上的软件架构，是需要考虑如下的一些系统要求：

☆好的系统，一定是一个架构灵活的系统。
☆我们需要一个方便维护的系统来满足可维护性的要求。
☆架构设计人员能够确定当运行系统的下一个时刻的状态。
☆最大峰值时，系统还能保持运行，系统性能不会明显降低。
☆我们的系统能够与其他系统进行集成。但是许多架构师并不知道在系统架构构建时期，他们应该完整考虑

哪些因素，应该采用怎样的手段，应该完成什么任务，才能构建出一个久经考验的系统架构。

误区三：只盲目追随业界通用框架

事实上，我们在工作中，也许还会听到这样一些声音：
☆我们要解决一个分布式的问题，CORBA很好而且还很标准化，用这个架构就行了。
☆我们要做一个电子政务的应用，J2EE框架不就很流行嘛，就选这个架构吧。
☆我们要做一个车载系统平台，OSGI就是一个好的嵌入式平台，就用它吧。

上述只不过是我们经常能见到的一种对框架或中间件的依赖现象。如果我们每开发一个应用或产品，都要自己手工设计一个框架，的确是一件令人痛苦的事。当然，我们承认现在有很多产品化的、很成熟的框架或中间件，的确极大方便了我们的应用及产品开发。这似乎给人们一种错觉，以为应用和产品开发是一件很容易的事。但是，我们也要清醒的认识到这些框架或中间件背后实际上隐藏着很多技术、设计、应用场景，也就是说为设计开发人员隐藏了很多系统设计开发的复杂性。于是当产品开发或项目结束时，你就可能听到这样的抱怨：

☆我们应用CORBA架构系统在运行时速度很慢，而且很复杂，出了问题却不知道症结在那里。
☆我们的2JEE架构让我们使用了大量的EJB和JAVA和JAVABEAN，简单就是构件的海洋太难维护了。
☆我们的车载电子系统根本就不工作，打开汽车车门，插入车钥匙，点火，需要等上几十秒，电子系统都没反应。
 

所以系统架构并不是简单地应用一个流行的、通用地、看似很唬人的某某通用框架，从而使自己的系统过分地依赖流行的框架或中间件，同时把所有的系统级质量要求统统扔给这些框架或中间件，以寄希望于这些通用框架代替你去思考和处理你应该解决的问题。实际上，我们应该寄希望于自己来构建系统架构，使其能够做到：

☆即便是最大峰值运行时，系统也要有很好的性能。
☆当系统面对大量并发事件时，能够很好的进行调度和并行处理。
☆当系统资源使用频繁且负荷增加时，系统能够很好协调资源的运用。
☆当我们设计的重要实时系统（例如航空管制系统）出现错误时，能快速实现系统的自我恢复。

这些都是软件架构及设计人员自己应该动手解决的问题。引用FrederickP在1986年《No Silver Bullets》一文中说过的一句经典明言"Silver bullets do not exist"，即"世上没有万能的解药"。Frank Buschmann也曾经说过"Any framework or middleware can only help you in doing your job,but it cannot do your job for you"，即“框架或中间件是用来帮助你的，而不是代替你去思考和工作的”。所以我们必须根据现实的系统要求（功能和非功能要求），自己去构建适合现状的软件架构！