CEO 的日记

Marc Clifton 的一句话

我于 2004 年 9 月认识了 XAKTSoft 的 CEO Tony Lewis。在与他合作了近一年之后，我建议我们一起撰写一系列文章，介绍我们所创建的技术。这是我们计划撰写的系列文章中的第一篇，将涵盖技术札记、设计与架构以及技术部分。虽然项目构思的故事非常有趣，但您还将阅读到公司决策、技术挑战以及产品设计中涉及的其他考虑因素。此外，还有一些独立的组件，我们认为社区会从中受益，我们将在技术讨论中提供这些组件的代码。但现在，请坐下来，享受 Tony 撰写的关于一切如何开始的故事。

引言

灵活性是复杂性的母亲。虽然目标和功能简单的系统非常适合经典的程序设计模型，但在“计算机 101 实验项目”以上的复杂程度，事情就会变得相当复杂。

大多数现代编程方法都是为了满足日益复杂的应用程序开发需求而诞生的。将更多程序员投入工作的经典方法很快就会达到无法进一步提高收益的程度。当前的方法试图通过代码重用、简化升级的模块化设计、隔离功能以便轻松自动测试单个单元以及面向对象开发来管理专业化和强制封装等技术来解决大型系统开发中的困难。此外，还演变出了社交方法论文化，其中最著名的是极限编程。

开发人员拥有一个日益壮大的常用且易于理解的方法论和技术工具包，可以应用于该项工作中。

• 面向对象编程
• 应用程序层（用户界面/业务逻辑/数据访问）
• 瘦客户端（更多是为了简化管理而非程序开发）
• 基于浏览器的开发
• 利用存储过程、触发器等的数据库中心模型。
• Web 服务
• Remoting
• XML

每一个新概念通常都被宣传为解决数据处理世界所有问题的圣杯。事实上，许多这些工具都是了不起的创新。如果没有它们，我们今天所享受的现代、交互式、基于 Web 的计算环境是不可能实现的。

然而，经典的观察仍然适用：“当你手里只有一把锤子时，看什么都像钉子”。盲目信奉任何一种技术或方法论，往往会导致系统由于其复杂性而几乎无法维护。这通常是由于为工作选择了错误的工具。

这一背景是导致“UltraTier”开发过程中思维的核心。首先，重要的是要说明 UltraTier 是什么——一个用于灵活开发以数据为中心的业务应用程序的平台。它不是圣杯，但如果你的“钉子”碰巧是那些以数据为中心的业务应用程序之一，那么 UltraTier 可能是你的“锤子”。

是时候改变了

与所有创新一样，UltraTier 最初是对需求的响应。在这种情况下，需求是一个具有特定挑战的业务系统。

• 一套高度复杂的通用核心功能。
• 不断变化的环境，需要对核心功能进行频繁更新。
• 该所需功能存在重大的区域差异，涉及用户界面、业务逻辑和数据模型的更改。
• 实质性的模块化需求，以满足特定的相关行业需求。这些模块通常需要与核心功能进行紧密集成和修改。
• 影响工作流、业务逻辑和数据需求的特定用户需求。

被替换的系统是一个经典的二层“胖客户端”项目，该项目试图满足其中一些需求，并且变得越来越庞大和复杂。尽管存在这些障碍，但它仍然是一个非常成功的商业产品，拥有超过 130 个安装实例。它有一些新系统必须满足并超越的功能。

• 整个系统安装只需要不到 5 分钟的电话协助（加上下载时间）。
• 所有用户都可以定期自行进行版本升级，耗时也一样，并且完全自动化（包括数据库更新）。
• 用户能够向现有表和屏幕添加用户定义的字段，从而在底层数据库中创建真正的类型化列。
• 用户能够向某些主记录添加相关表，并为其设置自己的一组用户定义字段。这些表允许捕获多条记录的数据，这些数据同样存储在数据库的标准表中。
• 报表生成器允许访问所有标准数据和用户定义数据，以及数据库平台可访问的任何其他数据。

该产品也有其局限性，这导致了重写决策的产生。

• 该产品针对特定地区的需求。这种针对性帮助了它取得的成功，但也限制了它在其他地方的适用性。
• 用户定义文件功能能够捕获特定行业的数据，但实现业务逻辑的唯一方法是通过数据库存储过程和触发器。
• 用户定义的屏幕和处理用户定义表的特殊屏幕只能处理用户定义的数据。
• 标准数据无法在这些屏幕上显示或维护。这使得这些屏幕在使用标准工作流的一部分时显得笨拙，如果需要用户定义信息的话。
• 某些业务逻辑与用户界面的紧密集成意味着某些功能在不同地方被重复。
• 这种集成还要求对系统中的工作流进行一定程度的控制，这导致了模态窗口的排他性使用（用户执行一个功能必须完成后才能打开另一个屏幕）。
• 工作站能够访问应用程序之外的数据库后端。这是一个涉及广泛安全和隐私问题的行业，因此需要消除这一点。
• 频繁的数据库访问给网络系统带来了压力，尤其是在连接速度相对较慢的 WAN 环境中。
• 锁定问题有时也很麻烦。
• 系统中各种工作流路径使得自动化测试几乎不可能，导致了昂贵的质量保证工作，并偶尔会出现灾难性的故障。
• 对行业所需的多种标准的と支持导致了不灵活的代码孤岛的混乱组合，这些代码往往无法很好地协同工作。

是时候做出改变了！迈向改变的第一步是确定新系统的需求。此时的思考过程仅涉及最终应用程序的需求。基于这些需求，将确定开发平台。

定义新需求

新程序需要具备以下特点

• 易于开发和维护的用户界面、业务逻辑和数据库访问，
• 分发紧凑，
• 安装简单，
• 终端用户无需协助或只需很少协助即可升级，
• 与其他产品和系统交互，
• 网络效率高，
• 足够紧凑，可以在单台工作站或 PDA 上运行，
• 可通过多种接口访问——网络连接的 PC、Web 客户端或带有同步功能的断开连接的客户端，
• 模块化（并非所有安装都需要所有功能），
• 能够接受标准修改集，以实现所需区域功能，
• 客户或客户的外部资源可以对其进行修改，而不会失去升级核心应用程序或任何其他模块化系统或区域修改的能力。

虽然这不是一个长长的列表，但这些属性的组合将很难找到。为了让这项任务更加困难，还需要考虑该行业的其他特征。

• 大多数客户都没有重要的内部 IT 专业知识。
• 大多数客户都是非营利组织，预算非常有限。
• 使用该应用程序的员工流动性很大，而且许多人是专业人士，他们没有多少时间或兴趣关注技术。
• 用户安装的范围从年营业额不足 50 万美元的小企业的单用户系统，到拥有数百名用户和数百万年营业额的基于 WAN 的多站点系统。

这些因素的结合立即淘汰了许多有前途的平台。高昂的初始采购成本、持续的费用、人员要求和其他因素使得它们在这种环境下无法正常工作。

在搜索过程中遇到的挫折导致了诸如“这应该很简单”和“为什么它不能像这样工作？”的想法。大多数开发者都有过同样的想法。通常，现实会让你妥协于现有的解决方案。如果找不到这些解决方案，就需要将问题追究到底：“要实现我需要的东西需要付出什么？”这时，另一个现实检验通常会停止这个过程。然而，这一次，从事了几十年的思考这些问题开始产生了一些答案。现在唯一的问题是“如何做到”？

这个问题将在下一期中讨论。