实践软件架构

引言

如今技术如此发达，为什么还有这么多开发团队以一种过时的方式创建项目？这不仅仅是精简客户端还是厚客户端、客户端/服务器、浏览器端的问题。甚至也不是开发语言的问题，C#、VB、Java、PHP、Python、Ruby 还是 COBOL。别管什么扩展和库，所有语言都有，当然有些设计得很好，当然不要重复造轮子。你有设计模式、SOA，以及敏捷、瀑布甚至极端的极限编程等各种方法论。等等，我再去搜集一堆流行语来好好推销一下。哦，忘了那些乱七八糟的，你明白我的意思。

架构在哪里？哦，忘了那些其他的乱七八糟的，当然你可以模块化、最小化依赖、大量利用设计模式，这些都很棒，但你的可维护性、可扩展性在哪里？你如何修复一个缺陷？谁负责修复？开发模块的人还是任何人？现在你又有了版本控制问题、QA 问题、源代码合并问题，是否有回滚计划？添加新功能后，遗留数据和新数据如何处理？归根结底，维护人员是谁？嗯，你已经有了画面，甚至比那里的开发人员的梦想还要好。他们有工作保障。

这是一个疯狂的讨论；是的，每个 IT 部门都有不同的需求。然而，许多 IT 部门面临着同样的噩梦。他们在系统运营方面都有各种各样的需求和业务要求。然而，当需求变化时，他们如何扩展？这不是关于某些系统特定的应用程序，例如操作系统、文字处理器、电子表格、某些硬件嵌入式解决方案或纯粹的基于实用程序的应用。那些是超出本范围的特定需求，将在即将到来的一集中讨论。我相信，大多数应用程序都是业务数据库类型的应用程序，涉及客户支持或财务。

IT 部门如何进行？可能会发生流程和重点的改变。所有独特和多样的需求都有解决方案。也会有很多架构师和专家为不同的需求提供各种解决方案。他们没错！我只是觉得他们没有从大局考虑，这就是重点丢失的地方，“大局”。

最完美的例子和机会是一个全新的 IT 部门，一切从零开始。我们接下来去哪？有很多选择。我认为大多数人会购买一个能满足大部分需求的系统。他们可能会走运，处于一个有完全满足其需求的软件包的行业。计划就此设定。现在看看未来，随着他们的成长和扩张，甚至可能改变业务计划并朝着不同的方向发展。现在，他们说，让我们开发自己的应用程序，这样我们就可以根据需要定制以满足新需求。那么几年后，当方向再次改变时会发生什么？

一些部门正处于这种需要升级新遗留系统的境地。现在会发生什么？技术已经改变，可能使用了过时的语言。他们会不断升级遗留系统，还是进行又一次重写，在新系统上修补旧系统？现在你有了新技术、新模式和新库。现在会发生什么？他们使用的是同一个专家还是新的专家？在这种情况下，有几种思路。你可以只维护现有代码库，可能根据需要重写模块，并在此过程中不断添加“胶带”。有很多考虑因素；规划、预算甚至人才。许多现有系统正是按照其预期工作。该系统是否满足业务需求？随着业务的变化，它会有可扩展性吗？即使 IT 部门选择了购买现成的解决方案，它是否能够随着业务的增长而增长？

这场疯狂将何时结束？这是大局，并且体现在你的架构中。通过我的经验和各种机会，我看到了组织内部的方方面面，好的、坏的和丑陋的。然而，许多组织中一个普遍的思考是那些几乎无法管理的遗留系统。当然，不是所有人都糟糕，是架构糟糕。我之所以现在说这些，只是因为经验和对过去项目的反思。我必须承认，我的一些项目也很糟糕，无法维护，甚至一团糟，但今天以及未来，我想有一个新的 outlook。

我对所有架构师、开发人员以及项目经理的挑战是创造优秀的系统。为正在创建的东西深思熟虑，并真正问自己“团队如何才能做得更好？”你能否创建一个更好的系统，这是可维护、可扩展并满足客户需求的圣杯？现在，我希望你们都在问“我们该如何做？”

我简单的答案是“简化”。我希望你们都听说过“KISS”这个说法“保持简单，蠢货”。这个哲学已经流传了很长时间，但没有人真正贯彻执行。

我最近的一个项目要求我创建数百封表单信函，通过电子邮件或传真发送，并整合系统中的各种数据元素，需要能够被调用和重新发送。业务需求，即使很少，也要求我为每封信函创建单独的屏幕。公平地说，每封信函都需要来自系统中不同区域的不同信息。也许，我的管理层只是想让我忙上几周，创建所有这些报告或信函，但我决定保持简单。所以，我懒得仔细思考，并在 4 天内生成了这些表单。不仅创建了上百个，而且在几分钟内创建了额外的无限数量。

让你们反思和考虑可能的解决方案，很多人会提供很多反馈。创建的是一个带界面的引擎。引擎能够收集关于表单信函的信息，填充系统中的任何额外信息，允许用户填写必要的额外信息，发送电子邮件或传真，并保存发送时的原始文件以供历史记录。信函以 RTF 格式存储，表格能够选择要发送的正确信函和版本。所有录入字段的 XML 也被存储起来，以便随时调用。一旦创建了这个引擎，源代码多年来都没有被触碰过。它处理任何额外的表单，甚至各种版本，但仍然能够调用任何旧版本。

这个引擎是什么？嗯，允许我离题一下。我一直在关注新技术，以及解决问题的各种方法。多年前，作为一个狂热的游戏玩家，我开始注意到那些远远超出《吃豆人》或《俄罗斯方块》时代的大型游戏；我开始关注《光环》、《GTA》以及各种其他游戏，并研究它们是如何创建的。是的，它们都有图形引擎来帮助处理 3D 应用程序，但我还得出结论，一定有一些脚本遵循其特定的故事情节。我发现了为什么不能将此应用于应用程序？我意识到它们可以应用于许多现实世界的情况。

现在回到架构，是的，这需要更多的思考，我说是将问题泛化为通用功能。这不是过度设计问题，添加功能并非必要。而是设计一个优雅的解决方案，并且能在许多应用程序中使用。我宁愿编写一次解决方案，而不是一次又一次地陷入重写解决方案的困境。在现实世界的例子中，几乎所有的制造和机械类工作都是通过某种形式的模式或引擎完成的。为什么不将其应用于软件架构和开发呢？