CEO 的日记 - 软件瑜伽

本系列之前的文章

• 前言
• 质疑一切
• 真正困难的部分

理解至关重要

客户端/服务器系统的开发（即使没有显示部分）进展缓慢。尽管总体目标已在初步提案中描述，但大部分设计尚未完成。相反，外包开发团队在没有整体大局的情况下被分配了非常具体的项目片段。之前在向他人传达大局方面的困难促使了这种方法的出现，但它带来了自身的问题。一旦创建了代码的最小片段，它就会带有“特性”，限制其在大整体中的可用性。是时候让新人全面了解整个设计了。

传达设计

任何架构师面临的问题之一是将其设计传达给实际执行工作的人。沟通的几个方面使得架构师的生活变得困难。

深度与程序员经验

在软件方面，设计可以从高层抽象一直传达到伪代码，几乎只比实际实现高一个级别。尽管有许多良好的方法和指南来促进这一点，但目标是优化程序员完成工作所需的信息量。信息太少会导致失败，而信息太多则会“过度”。架构师（尤其是推动架构的公司 CEO）通常会获得“高薪”，因此优化传达信息所需的时间对项目成本有可衡量的影响。

然而，要做到这一点非常困难，因为你必须平衡程序员的技能与你认为他们需要的信息深度。即使是你自己的员工，经过多年的合作，这已经够难了，特别是当他们已经适应了现有的架构、工具、技术，而你却挑战他们使用一个全新的、截然不同的架构、新工具和新技术时。当部分工作被外包到世界另一端的国家时，情况就更难了。对于预算有限的小型公司来说，开发原型，这种平衡至关重要。

当然，权衡取舍是，更有经验的程序员（那些有望能接受更高层设计并将其付诸实践的人）也更昂贵。所以我们有一个三角形，其中存在文档需求、程序员技能和程序员成本的最佳点。

跳出思维定势

程序员技能其实是一种难以捉摸的品质。显然，技术技能是可以相当容易确定的。然而，更难确定的是从不同角度思考问题的能力。

抽象并非易事

在传达架构时，一个常见的问题是，程序员（即使是技术熟练的程序员）会针对架构旨在解决的特定问题领域进行实现。在传达架构时，通常缺少的是允许架构抽象的设计模式。 incorporated 了一定程度抽象的实现，当原始问题领域发生变化时，它会更具灵活性。抽象的前期投资在实现需要适应新需求或不同需求时会获得十倍的回报。同样，问题在于

• 架构抽象了多少？
• 架构在哪里抽象？
• 多少抽象被传达给了程序员？

这些都是不容易回答的问题，如果更糟的是，为了回答这些问题，程序员需要完全详细地理解架构——这是一个两难的局面。

微软的方式可能会碍事

外包公司以他们使用微软工具所获得的技能和培训以及遵循规定方式而自豪。任何“跳出思维定势”的架构都会与“微软的方式”发生冲突，并常常导致灾难性的结果。我们在项目中无数次遇到这个问题，因为一些常见技术，如数据集、远程处理、序列化等，被应用到项目中，而没有考虑性能、安全和灵活性。很难告诉某人，“好吧，忘掉你学到的关于如何做 X 的所有事情”，然后改为“这样做”。

为合适的人选择合适的任务

外包，以及任何工作关系，最终都归结为足够了解你的员工、顾问和其他团队成员，以便你能将合适的任务分配给合适的人。虽然记录设计很重要，但我们学到的一件事是，设计文档只需要足够即可，以便它适合任务和人员。

说起来容易做起来难

可悲的现实是，这说起来容易做起来难，而且随着项目进展，当整个设计被传达后，这一点就显而易见了。项目立即开始偏离轨道。如果没有详细的每个步骤的规范，外包团队就做出了需要第二天撤销的假设。语言似乎不是问题，团队的技能水平也很出色。最大的两个问题是时区（当我们上班时他们正要下班）以及与其他人经历的相同问题：他们无法理解预期的项目整体范围。

初创项目需要远见和技能

重启的项目才一个月，就开始看起来像一项不可能完成的任务。同时，还在继续寻找一种工具来帮助处理界面负载。众多谷歌搜索（你如何提问很重要……）中的一个，带来了一个关于 Code Project 的有趣链接。它描述了一个名为 MyXaml 的产品。文章的作者 Marc Clifton 创建了一个工具，该工具做了许多与微软的 XAML 相同的事情，但避免了 Avalon 环境的一些设计决策。基本上，MyXaml 的作用是读取包含 .NET 对象定义的 XML 并实例化这些对象。当然，这是一个巨大的简化，但它看起来可能是一个有用的工具。随后进行了一次简短的电子邮件交流，在此期间，Marc 接触到了整体愿景。

第二天，安排了一次电话会议。在这次谈话中，Marc 对整体计划越来越兴奋。它实际上与他已经在自己编写的应用程序中使用的许多技术非常相似，与他设计的 MyXaml 产品也非常契合，并且“感觉是对的”。有一点，他提到这是程序应该设计的方式。用户界面是独立的，业务逻辑与实际数据库访问分离。他不是唯一一个兴奋的人。在第一次电话中，人们就明显感觉到 Marc 不仅仅是一个我们可以使用的工具的作者，他还是我遇到的第一个立即理解了高层设计的人！这将是应用程序开发的一个转折点。那是 2004 年 9 月 29 日。

Marc 有一些空闲时间，并且对该项目感兴趣，所以我们开始着手将一切整合在一起。检查了外包团队的原始第一阶段迷你项目，并设计了一个简单的演示来测试这些概念。在三天之内，就完成了一个概念演示，附带了许多概念图。用清晰的格式将事物记录下来是 Marc 对这项工作的主要贡献之一。

在一个月之内，该应用程序已经运行，拥有声明式设计的屏幕、自动生成的数据库访问以及数据容器和对象。按照这个速度，似乎所有工作将在年底完成。结果，时间是合适的，但年份错了。在十月底，我们为新项目制定了一个“待办事项清单”。要解决的问题清单如此之多，以至于面对面拜访似乎是合适的。

即便如此……

十一月第二周的会议非常有启发性。漫长而持续的设计、澄清、概念测试和“假设”的会议，识别出底层平台需要开发的领域。即使 Marc 理解了高层架构，但在实现方面也存在困难，再次 dealing with 适当的抽象和支持架构概念的正确类结构。虽然有一个“演示”平台在运行，但它远非最初设想的灵活引擎。即使有限制，基础也是正确的。其中一个问题是在编写整个系统之前尝试验证基础功能。编写了大量的系统测试（AUT，Marc 的另一项贡献），看到所有“灯变绿”令人兴奋，但“这实际上符合我们的要求”的反馈却缺失了。

在服务器工作的同时，外包团队被赋予了“增强”一组组件的任务，以支持新平台的一些附加要求。与此同时，通过 MyXaml 屏幕定义和一些内置逻辑，实现了视觉确认。

第一次“哇”的体验

一旦前几个组件可用，就构建了新屏幕（手动编码 XML）来测试这些概念。一个屏幕向表中添加了“人员”，另一个屏幕使用了一个组合框（数据驱动），从中选择人员。第一个“哦，哇！”的时刻发生在打开一个带有组合框的表单，然后打开另一个表单（请记住，这些是无模式的）具有“添加人员”功能时。当添加新人员时，他们立即出现在组合框的可用数据中。这不仅在单个客户端上使用无模式对话框有效，而且在另一台机器上启动第二个客户端时，完全相同的过程也自动更新了另一个客户端。

下图说明了代码中发生的情况，这些图表略过的一些细节将在未来的架构文章中讨论。

所有这些都是通过声明式编码、抽象和通用的数据管理实现的，最重要的是，客户端或服务器都没有为该任务编写专门的代码。数据事务、持久化存储和缓存事务/更新过程都是通用功能，*独立于*特定客户端表单和数据库模式。会有更多这样的时刻，但这第一次简单验证了“这些东西确实有效”！

灵活的软件——程序员的瑜伽

保持专注

这种开发类型持续面临的挑战是保持对长期目标的关注。大多数程序员都知道创建可重用代码有多难。倾向于“按时编码”，创建每个新功能以满足已呈现的特定需求。拥有一个显示特定功能的测试环境，将那些旧习惯带回了隐藏的地方。即使我们使用“服务器端业务规则”，它们也是以非常僵化的方式编码的，有时与客户端控件紧密相连。为了测试平台的其他部分，有必要这样做。主要目标是阻止这种方法渗透到核心逻辑中。

保持坚强

即使在设计非常通用的功能（如“缓存文件同步”）时，最初的方法也是在命令数据包中添加逻辑来同步文件中的数据。缓存文件本身在客户端实现为一种特殊类型的表。之后，当添加了非缓存表更新后，很明显，缓存表更新只是同一要求的特例。通过在两个地方利用完全相同的逻辑，整个系统可以变得更加健壮。这也会使系统的单元测试更加直接。

Pranayama

与任何软件项目一样，重构在不断进行。团队不断改进的一个领域是减少“只求完成”的方法。每当发现新需求时，都会有意识地努力退一步，将其视为可能在其他领域有用的通用功能。同时，我们查看已实现的逻辑，以确定新功能是否可以与现有逻辑合并，以使整个系统更具灵活性。

保持灵活性

设计通用业务平台最困难的部分是确保绝大多数需求都得到支持并且易于使用。在一定范围内，允许额外的灵活性来支持标准框架之外的独特需求也很重要。使用 .NET 作为后端平台意味着服务器几乎可以做任何事情。

为了支持真正的跨平台和基于 Web 的客户端，而无需为每个环境进行定制，有必要为客户端功能建立一个基线。任何支持所有这些功能的客户端都是“兼容客户端”。使用 MyXaml 的技术，还可以为客户端添加其他功能（新组件、业务逻辑等）。任何依赖于该扩展客户端功能的应用程序都将是一个“不兼容”的应用程序。开发 UltraTier 的目标是确保绝大多数应用程序可以在兼容框架内实现。

冲刺阶段

尽管困难重重，开发仍在进行，并且看到了希望。即使是那些看过该系统的怀疑者，也对其功能印象深刻。作为开发者，我们从不满足。在过去，替换相对较新的软件一直是我的业务的标志。UltraTier V2.0 的设想已经在讨论中！到目前为止，这些文章大多是非技术性的。这正是意图所在，为驱动 UltraTier 设计的决策奠定背景。之后会有更多文章，概述其中一些方法的细节。Marc Clifton 将主要承担这项任务。