- 讲师：刘萍萍 / 谢楠
- 课时：160h
- 价格 4580 元
特色双名师解密新课程高频考点，送国家电网教材讲义，助力一次通关
配套通关班送国网在线题库一套
软件架构的艺术之软件架构的误区
来源：长理培训发布时间：2017-11-22 17:10:34
在现实中，我们会发现很多从业人员对软件架构的认知有着明显的局限和偏差，具体体现在以下几点。
误区一：不知道架构与设计的区别
虽然许多从业人员的头衔为"架构师"，但是他们并不能回答下面的一些问题：
系统架构与设计有区别吗？区别在哪里呢？
什么样的人能满足系统架构师的要求？
什么样的人能满足设计人员的要求？
一般地，架构师都是技术出身，他们可能长期从事过编码、设计领域的工作。很自然，他们可能认为设计、编码工作就是软件架构的一切。但是真正的架构师必须有长期设计的工作经验，并在系统化的提升之后才可能成为合格的架构师。他们需要考虑商业概念、商业运作、系统结构、结构优化等这些更为宏观的方面，然后选择那些最经典的实践参考模型，才能构建出合格的软件架构。
误区二：不知道系统架构该如何做 让我们回到日常的软件系统活动中来。其实通过一些实践，我们已经逐步建立起一些对软件架构及设计活动的认知。直觉和经验告诉我们，一个软件系统或软件架构在构建之初就给架构师留下了充分的创作空间。但是，一个单纯为了一系列功能的实现而构建的架构，还不能称作严格意义上的软件架构。一个真正意义上的软件架构，是需要考虑如下的一些系统要求：
好的系统，一定是一个架构灵活的系统。
我们需要一个方便维护的系统来满足可维护性的要求。
当系统用户数量随着业务的扩展而增加，我们的架构还能应对。
架构设计人员能够确定当前运行系统的下一个时刻的状态。
最大峰值时，系统还能保持运行，系统性能不会明显下降。
我们的系统能够与其他系统进行集成。
但是许多架构师并不知道在系统架构构建时期，他们应该完整考虑哪些因素，应该采用怎样的手段，应该完成什么任务，才能够构建出一个久经考验的系统架构。
误区三：只盲目追随业界通用框架
事实上，我们在工作中，也许还会听到这样一些声音：
我们要解决一个分布式的问题，CORBA很好而且还很标准化，用这个架构就行了。
我们要做一个电子政务的应用，J2EE框架不就很流行嘛，就选这个架构吧。
我们要做一个车载电子系统平台，OSGI就是一个好的嵌入式平台，就用它吧。
上述只不过是我们经常能见到的一种对框架或中间件的依赖现象。如果我们每开发一个应用或产品，都要自己手工设计一个框架，确实是一件令人痛苦的事。当然，我们承认现在有很多产品化的、很成熟的框架或中间件，确实极大方便了我们的应用及产品开发。这似乎给人们一种错觉，以为应用和产品开发是一件很容易的事。但是，我们也要清醒地认识到这些框架或中间件背后实际上隐藏了很多技术、设计、应用场景，也就是说为设计开发人员隐藏了很多系统设计开发的复杂性。于是当产品开发或项目结束时，你就可能听到这样的抱怨：
我们应用CORBA架构的系统在运行时速度很慢，而且很复杂，出了问题却不知道症结在哪里。
我们的J2EE架构让我们使用了大量的EJB和JavaBean，简直就是构件的海洋，太难维护了。
我们的车载电子系统根本就不工作，打开汽车车门，插入车钥匙，点火，需要等上几十秒，电子系统都没有反应。
所以，系统架构并不是简单地应用一个流行的、通用的、看似很唬人的某某通用框架，从而使自己的系统过分地依赖流行的框架或中间件，同时把所有的系统级质量要求统统扔给这些框架或中间件，以寄希望于这些通用框架代替你去思考和处理你应该解决的问题。
实际上，我们应该寄希望于自己来构建系统架构，使其能够做到：
即便是最大峰值运行时，系统也要有很好的性能。
当系统面对大量并发事件时，能够很好地进行调度和并行处理。
当系统资源使用频繁且负荷增加时，系统能够很好地协调资源的运用。
当我们设计的重要实时系统（例如航空管制系统）出现错误时，能快速实现系统的自我恢复。
这些都是软件架构及设计人员自己应该动手解决的问题。引用Frederick P在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"，即"框架或中间件是用来帮助你的，而不是代替你去思考和工作的"。所以我们必须根据现实的系统要求（功能和非功能要求），自己去构建适合现状的软件架构！
系统架构与设计有区别吗？区别在哪里呢？
什么样的人能满足系统架构师的要求？
什么样的人能满足设计人员的要求？
一般地，架构师都是技术出身，他们可能长期从事过编码、设计领域的工作。很自然，他们可能认为设计、编码工作就是软件架构的一切。但是真正的架构师必须有长期设计的工作经验，并在系统化的提升之后才可能成为合格的架构师。他们需要考虑商业概念、商业运作、系统结构、结构优化等这些更为宏观的方面，然后选择那些最经典的实践参考模型，才能构建出合格的软件架构。
误区二：不知道系统架构该如何做 让我们回到日常的软件系统活动中来。其实通过一些实践，我们已经逐步建立起一些对软件架构及设计活动的认知。直觉和经验告诉我们，一个软件系统或软件架构在构建之初就给架构师留下了充分的创作空间。但是，一个单纯为了一系列功能的实现而构建的架构，还不能称作严格意义上的软件架构。一个真正意义上的软件架构，是需要考虑如下的一些系统要求：
好的系统，一定是一个架构灵活的系统。
我们需要一个方便维护的系统来满足可维护性的要求。
当系统用户数量随着业务的扩展而增加，我们的架构还能应对。
架构设计人员能够确定当前运行系统的下一个时刻的状态。
最大峰值时，系统还能保持运行，系统性能不会明显下降。
我们的系统能够与其他系统进行集成。
但是许多架构师并不知道在系统架构构建时期，他们应该完整考虑哪些因素，应该采用怎样的手段，应该完成什么任务，才能够构建出一个久经考验的系统架构。
误区三：只盲目追随业界通用框架
事实上，我们在工作中，也许还会听到这样一些声音：
我们要解决一个分布式的问题，CORBA很好而且还很标准化，用这个架构就行了。
我们要做一个电子政务的应用，J2EE框架不就很流行嘛，就选这个架构吧。
我们要做一个车载电子系统平台，OSGI就是一个好的嵌入式平台，就用它吧。
上述只不过是我们经常能见到的一种对框架或中间件的依赖现象。如果我们每开发一个应用或产品，都要自己手工设计一个框架，确实是一件令人痛苦的事。当然，我们承认现在有很多产品化的、很成熟的框架或中间件，确实极大方便了我们的应用及产品开发。这似乎给人们一种错觉，以为应用和产品开发是一件很容易的事。但是，我们也要清醒地认识到这些框架或中间件背后实际上隐藏了很多技术、设计、应用场景，也就是说为设计开发人员隐藏了很多系统设计开发的复杂性。于是当产品开发或项目结束时，你就可能听到这样的抱怨：
我们应用CORBA架构的系统在运行时速度很慢，而且很复杂，出了问题却不知道症结在哪里。
我们的J2EE架构让我们使用了大量的EJB和JavaBean，简直就是构件的海洋，太难维护了。
我们的车载电子系统根本就不工作，打开汽车车门，插入车钥匙，点火，需要等上几十秒，电子系统都没有反应。
所以，系统架构并不是简单地应用一个流行的、通用的、看似很唬人的某某通用框架，从而使自己的系统过分地依赖流行的框架或中间件，同时把所有的系统级质量要求统统扔给这些框架或中间件，以寄希望于这些通用框架代替你去思考和处理你应该解决的问题。
实际上，我们应该寄希望于自己来构建系统架构，使其能够做到：
即便是最大峰值运行时，系统也要有很好的性能。
当系统面对大量并发事件时，能够很好地进行调度和并行处理。
当系统资源使用频繁且负荷增加时，系统能够很好地协调资源的运用。
当我们设计的重要实时系统（例如航空管制系统）出现错误时，能快速实现系统的自我恢复。
这些都是软件架构及设计人员自己应该动手解决的问题。引用Frederick P在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"，即"框架或中间件是用来帮助你的，而不是代替你去思考和工作的"。所以我们必须根据现实的系统要求（功能和非功能要求），自己去构建适合现状的软件架构！
责编：罗莉
下一篇：架构师之路(2)详解面向过程
发表评论(共0条评论)
| 课程专业名称 |
讲师 |
课时 |
查看课程 |
|---|
国家电网招聘考试录播视频课程
| 课程专业名称 |
讲师 |
课时 |
查看课程 |
|---|
湘公网安备:43011102000856号 
点击加载更多评论>>