面对架构，我们准备好了么？

[从兴公司 - 陈百平]

上月随公司到阳江闸坡旅游，晚上与同事在海边吃夜宵，吹着阵阵的海风，甚是爽快。谈论间突然谈到了架构问题，争论中我主张少用架构，因而被同事戏称为“反架构人士”。实际上，我并不反对使用架构，只是认为没有必要使用的话，就尽量少用而已。

首先，我们看看所谓的软件架构是如何发展的。

在我们开发程序时，因为某个开发方式用多了，各个开发人员都熟悉了，于是就出现了一个所谓成熟的架构。例如上世纪90年代用得最多是 Client/Server架构，即客户端/服务器架构。C/S架构曾经很好解决了当时分布式计算的需求，使用廉价的服务器便能构建出当时只有大型机才具备的多客户并发计算的能力。因为大家都认同了这个架构的有效性，于是，不管什么项目C/S架构都蜂拥而上。因为无论是客户还是集成商或软件提供商都认同这个模式，因此不管最终实施如何，反正大家都能接受。

虽然大家都能接受，但是客户还是有抱怨：为什么用户数一多系统就严重变慢，甚至崩溃；集成维护商也头疼：客户一有新需求，就要到处更新程序，到处抓bug，忙个半死。有不安分的开发者就想偷懒，不想这么劳累，于是就尝试着一种新的开发模式 Browser/Server，即浏览器/服务器架构。慢慢地用的人多了，大家都知道了其好处，一想到C/S的恶梦，大家又一窝蜂地扑向了B/S架构。

B/S架构中又有两大阵营：DOT.NET与J2EE。我们且不说DOT.NET，单表J2EE。自从有了J2EE，各种架构有如雨后春笋纷纷涌现，如Sprint、Hibernate、Strut、JSF、EJB、Web Service等等，五花八门。

可以认为，从C/S架构到B/S架构是一个变革，极大地改变了开发与运维模式。但从J2EE繁衍出来的相关架构或J2EE的某些变种架构并不是一个变革，更多的是某个方面的改进。特别是为了解决某个现有问题而提出的，而不是一个全局的解决方案，如J2EE一样。如Hibernate架构只做了数据层的封装，Web Service解决了系统间的数据共享访问的问题。

因此架构并不是包医百病的，更多时候，还需要我们自个去权衡使用了这些架构是否真的可以为项目带来效益？如果真能带来效益，接下来的问题是：面对如此众多的架构，我们是否已经做好了准备？

以前有同事建议引进新架构到项目时，我总爱问这几个问题：
1． 你觉得这个架构好么？
2． 由这个架构引起的问题，你有能力解决么？
3． 你可以在短时间内向项目组成员培训这个架构么？

如果能承诺这三个问题，我就允许采用新的架构。只要其中有一个不能给出肯定的回答，我就认为我们还没有准备好，因此我会拒绝新的技术。我不希望有一个不可控的元素藏在我的项目中，像一颗别人安放的地雷，不知到哪天我们会倒霉地踩上。到时我就没法向上层主管或用户交代。

第一个问题：这个架构好么？很多时候，我们是受别人的评论影响后，才对某个架构有个看法，自己对这个架构却没有深入的了解。可能有人会说，这个架构应该是好的吧，要不然为什么IBM等众多的企业都在推广它？这倒是真的，各大跨国公司都不易余力的进行新技术的推广，比如曾经的CORBA、EJB和J2EE等。但仔细想想，你会发现它们都挺有心计的。IBM不断地向客户宣传J2EE的好处，并建议客户在项目采用J2EE架构，从而可以使用IBM的 WebSphere套件。以前IBM本来是已硬件为主的，但通过卖WebSphere，IBM的软件收入大幅上升。另一方面，为了弥补J2EE原有性能上的缺陷，客户不得不购买性能更高、价格更昂贵的IBM服务器来满足计算能力的需求。在利益的驱动下，它们自然力挺新技术了。而技术对于像我们一样的软件开发商来说是中立的，我们不能因为别人说好就认为这个架构好。另一方面，好的架构往往会很好解决某个问题，但又引进其它问题，对于这些，我们是否都有很好的评估呢？因此，我们自己首先需要对即将采用的架构有着清晰的认识后，才能予以使用。

第二个问题：由这个架构引起的问题，我们有能力解决么？新架构往往伴随着新的技术。而新技术的引入，又往往容易引起新的问题。并且，在目前这种分布式计算环境中，问题更容易产生，产生问题的原因也更为复杂多变。对此，我们做好了足够的准备了么？第一个建议使用新架构的人，往往是项目团队里对该架构最为熟识的人，如果连本人都不能承诺可以解决潜在的问题的话，我们更不能指望其他人能予以解决了。当真的遇到问题时，我们是否能调动足够的资源去解决？这种额外的资源投入是否是可控的？这些风险都是在引入新架构前必须予以回答的。

最后一个问题：项目组的每一个参与者都能掌握新的架构么？如果架构过于新颖，或过于复杂，项目组的培训成本是很高的，项目计划中是否已安排了新架构的培训？培训成本是否会超出预算？在J2EE炒作得很红火的时候，著名的社交网络friendster.com花了半年时间把整个系统从J2EE移植到了PHP上。原因是大家都无法忍受原有的J2EE系统性能低下的问题。但真的是J2EE的问题么？我猜很大可能是当时负责该项目的技术主管是个J2EE的狂热爱好者。他建议使用J2EE架构，而他又对J2EE一知半解；到了他向各模块小组组长解释他设计的系统架构时，小组组长当然只能是半知错解了；随后组长向本组开发人员讲述时，开发人员更是错知乱解。到最后系统自然面目全非。

无可否认 J2EE（JSP+SERVLET部分）是成功的，因为大企业都做了大量的宣传，每个JAVA开发者都知道其概念，了解其技术。使用它来开发，不仅开发人员可以随时到位，节省了培训时间，并且成员之间也能方便的地进行沟通。CORBA、EJB为什么会失败，因为它过于复杂，并不是每个开发者都可以学会。它们本身自有的复杂性及其培训的困难性最终导致它们不能普及。

因此，当我们还没有为架构准备好时，请慎用架构。如果要在项目中引入新架构，请先问一问：
面对架构，我准备好了么？
面对架构，我的开发小组准备好了么？
面对架构，整个项目团队准备好了么？
面对架构，我们都准备好了么？

注：以上文章版权归立信集团《沟通》所有，不得转载、引用。