程序架构重要的5个原因

这是来自InsideRIA的一篇文章，由RIAMeeting翻译，原文地址是：

http://www.insideria.com/2009/06/ria-architecture-why-it-matter.html

这篇文章主要是想纠正一下部分人对好的应用程序架构不是很重视的一种现象。

有时候，项目经理或者客户会对你在应用程序架构上花的时间产生质疑，而你也很难在这个问题上给出一个很好的解释。

下次有人认为你在应用程序架构上浪费时间和精力的时候，你可以引用这篇文章中的观点来回应。

像Flex这样的RIA技术的一个优点，就是能够进行快速开发。

这个观点在许多教程和屏幕录像中又得到印证，似乎大多数复杂的任务都在很短的时间内得到了解决。

不幸的是，这实际上会给人留下一个错误的概念认为RIA的开发很容易，而客户则也是期待所有的应用程序都应该能够通过这种便捷的方式开发出来。

而实际情况则是随着需求越来越复杂构建应用程序不再是简单的摆放几个组件和设置几个数据源就能完成的，对应用程序合理计划以及组织的需求也就产生了。

另外一种反对的声音来自于一些新手，他们认为运用架构，框架，以及最佳实践是过于繁杂的步骤。一种常见的思维类似：“为什么我就不能简单的在这个按钮上加个监听器来实现我全部的逻辑？”

实际上，我倒是认为，如果是编程新手或者对某个平台很陌生的话，倒是不如使用简单的代码逻辑。因为在你对这个应用程序架构所致力于解决的问题有充分的认识和体验之前，这些复杂的架构是比较难理解。（译者注：我比较赞成作者的观点：你必须真的在开发过程中遇到问题，并且尝试自己去解决这样的结构问题，才能够很好的理解一个应用程序架构，否则，如果一上来就试图去读那个架构，去看那个架构的一些文档，照猫画虎的去用，反而是对你编程时间和效率的一种浪费。）

然而，如果你是那些打算提升自身技能或者固执的认为应用程序架构没有好处的人，我这里有几个关于为什么一个好的架构在RIA开发中很重要的观点。

Consistency（一致性）

我觉得大家应该不会对DRY(Don’t repeat yourself不要写重复代码)这个原则有不同见解。

即使对于解决“给按钮添加逻辑”的任务，把重复的逻辑代码分离出来放到一个方法中就可以做到DRY这个原则。

然而，随着你的应用程序越来越大，开始使用多个视图的时候，我们的方法要么要变成公有方法让其他视图也能使用(这样是不好的，因为那个最开始做的视图必须一直保持共有)，或者从当前视图中脱离出来，放到一个单独的类中（这实际上是个更好的方案）。

把上述的复杂性再加剧些，在你意识到之前，你的代码就开始变得非常的混乱而且，乱得像意大利面的代码会很快占据你的大脑。

如果你的应用程序框架中有了一些预先设想好的模式，每个方法都有一个他自己的位置，一旦别人熟悉了你的这个模式，任何人都可以马上知道实现某种逻辑的代码在哪。

这种前后一致性也会让你在编程的时候做决定更简单更快捷。后期，也可以减少重构的工作。

用不了多久，你就会发现“拿过需求来直接就开始做界面组件”的这种做法比这种模式差远了。这时候，你的脑子里的想法则是：“所有的功能都放在一个地方，而每个功能都有它自己的位置”。

Team working团队合作

从来没人愿意接手其他开发者的代码。

很差劲的架构代码会损失很多小时，甚至很多天的工作时间，仅仅去看明白哪些代码都是干什么的又都在什么地方。

两个开发者几乎不可能完全一致的选择同样的方式去实现一些功能，而当具体的功能实现需要共享的时候，大家又要花很多时间来讨论那部分代码在什么，以及为什么这样写。

一个更好的做法则是把时间花在确保所有的团队成员都熟悉一个架构，并且确保大家都使用相似的方式方法去编写代码。

这可以让团队的协助更加有效，帮助团队成员快速高效合作。

Maintainability 可维护性

好的架构一般都是构建在好的编程模式和好的实践之上的。由于这个，应用程序的脆弱点以及可维护性都得到了提升。可维护性是由定位某个功能代码在代码库中的时间，实现一个功能所需要花费的时间，以及对已有代码做修改后产生的影响决定的。

一个好的架构可以让开发人员快速定位需要修改的代码，我们在“一致性”中已经讨论过这个了。它也会提供一个结构性的方案让开发人员去执行这样的修改，因此实际的编写代码的时间也会缩短。

这个修改的影响应该对已有系统产生很小甚至没有任何影响，因为一个好的架构是开放性的而且可以容纳需改的。

如果一个项目是构建于一个常用的架构，重新回顾一个很老的项目会更加简单和容易。但是，如果一个项目构建的时候，没有一个明确的架构而又记不太清楚的代码的时候，就会困难很多。

Flexibility 灵活性

在设计一个架构的时候，一个很重要的考虑因素就是灵活性。架构应该能够提供一个简单的方式来修改，添加新的实现而不需要完全重写。

如同上面提到的，一个好的架构应该对变化是开放的，并且应该让开发人员可以轻松应对变化而不是总要回到初始的需求重新在冗长，过于繁琐的变更控制流程。

当不可避免的情形终于发生，客户想回到最初的实现的时候，架构让你从容面对而不是恨不得把你的电脑顺着窗子扔出去。

Code Re-use 代码重用

面向对象的一个很吸引人的特点就是重用。在实际情况中，虽然代码重用不应该像上面提到的那些方面一样重要，但它仍然是一个好的架构提供的一个额外的好处。

逻辑化地把功能组织到相关的组中，并且尽量减少对系统的依赖就可以把可以重用的代码使用在其他的项目中，同样也提供了同其他开源或者商业类库整合的可能。

总结

上面谈到的许多点实际上对经验丰富的开发人员来讲应该并不陌生，我只是整理一下这组观点，使得它更容易被你的客户和项目经理接受；也使得他们能够认可在应用程序架构上花费的时间是有益于商业利益的。

通常情况下，你可能看不到立竿见影的效果，因为不重视应用程序架构的情况下短期的一些目标会更快的达成，而让你忽略了实际上你是在用你长期项目的整体质量，高效的软件质量，以及延误整体的项目工期来做代价的。

我也尽量保持使用广义架构来指代好的开发实践上而不是具体到框架，一个好的架构并不需要包含一个通用框架。实际上，理解并且使用一个现有的框架是节省时间和减少重复投资的好方法。