高效软件开发

什么是高效软件开发？

如今，大量的开发工具层出不穷，其中许多都是基于“可视化设计”的。最典型的例子就是 Visual Studio，这是微软销售的一款工具，旨在让开发者使用其产品和开发平台。

通常还需要庞大的开发团队，并且应用程序是采用无数个“层”来开发的，以寻求不同方面（如表示层、业务逻辑层和后端）之间的所谓“独立性”，这通常被称为“N层”应用程序。

最重要的是，人们普遍认识到软件本质上是复杂的。这意味着即使是最简单的功能的创建也可能需要比简单的代码行更多的东西。

以上所有情况都导致了一系列问题，使得信息技术成为全球（几乎所有）组织中“必须但令人讨厌的”必需品。

另一方面，这些问题伴随着软件和系统集成公司的不断轰炸，它们希望向组织推销“软件如此简单……只要您与我们合作”的理念。

另一个需要考虑的问题是，用户的需求日益增长，变得越来越复杂，因为当今一代（X世代和Y世代）越来越精通技术，因此对这种复杂性有更高的要求。

以上所有因素导致大多数软件项目失败，无论它们多么昂贵、投入多少资源、有多少技术人员参与其中。

然而，令人惊讶的是，许多流行的应用程序被数千（有时是数百万）用户使用，它们能够很好地满足复杂的用户需求，并且非常稳定，而且随着时间的推移不断发展，而这并没有成为这些应用程序被广泛使用的障碍。

这类应用程序的秘密之一，就是它们是*巧妙*开发的；将大部分复杂性封装在智能代码组件中，并避免不必要的冗余和不必要的复杂层，这些层只会使事情更加复杂。

那么，什么是*高效软件开发*？它是

ESD：*一种以最巧妙的方式构建软件的范例，利用了可重用性概念、信息的动态生成/管理/功能以及避免任何真正不必要的复杂性层，从而允许更简单、更快速的维护/演进；同时基于其简洁和巧妙提供了重要的复杂性水平。*

为什么需要高效软件开发？

布鲁克斯定律

弗雷德·布鲁克斯在 1975 年提出的一个定律，即使在当今时代也极其准确。

“向一个延误的软件项目增加人力只会使其更延误。”

这简单地意味着，一个本质上复杂的项目，对于新加入的成员来说更难掌握，使得对该项目的理解在这些新成员中更难 spread。

这在当今非常现实，以至于微软等公司都有很好的例子证明了这个问题。

软件复杂性

Grady Booch（统一建模语言的合著者之一）在他的《面向对象设计》一书中，在第一章中解释了世界本质上是复杂的（包含所有事件及其属性），因此软件也必须复杂，因为它是现实的体现。然而，Booch 忽略了一个要点，即这种复杂性可以被很好地抽象，以便最终用户不必处理它。换句话说，Booch 引用人类的抽象能力只是为了解释它作为大脑过程，并将其模型化在面向对象编程范式中；但并未将其与他第一章中的复杂性联系起来。

简而言之：*尽管现实本质上是复杂的，软件是现实的模型，但通过构建一个*基础*框架，可以创建新的模型，从而简化软件；该框架隐藏了大部分复杂性，并允许上层用户只关注他们打算解决的问题的语义。*

软件构建周期

过去，最小的软件周期包括

• 分析
• 设计
• 编码
• 测试
• 实施

如今，这个周期变得越来越复杂，由于更复杂的需求，需要增加额外的阶段。诸如用例编写（用于细化需求分析）、质量保证、缺陷管理、单元测试、集成测试等步骤已被添加到上述主要步骤中（或得到扩展）。

但是，我们真的需要所有这些吗？这个问题应该让我们想起微软早期一位高管的引述：“我们公司拥有最大的技术支持团队”。一周后，当时微软的主要竞争对手 Lotus 公司发表了如下引述：“在 Lotus，我们的技术团队很小……这得益于我们的软件更好，不像拥有大型技术支持团队的公司那样容易出现故障”；明显提及了微软之前的引述。

微软开发了其广为人知的 .NET Framework，它是在其旧技术之上的一系列补丁组件，而不是从头开始重写。与微软一样，许多其他公司都有*庞然大物*，最好不要唤醒它们，以免惹怒它们。

尽管微软在大多数开发者杂志上发布了关于 Visual Studio 的精美广告，但现实是，即使是最简单的应用程序，也需要经过许多荒谬的步骤，而只需打开一个文本编辑器（当然要带有漂亮的关键字着色）并输入一个简单的“PRINT ‘HELLO WORLD’”即可。

它是如何工作的？

框架

走向高效软件开发的第一步是创建一个足够健壮、但又（巧妙地）简单编程的框架。

一个允许动态生成用户将与之交互的任何*实时*组件或对象的框架。XML 等现代技术以及内存和硬盘空间成本的急剧下降，使得可以将许多属性放入可以*即时*动态创建的对象中。

动态类型

“抽象数据类型”概念的纯粹主义者强烈反对生成动态对象，认为这完全违背了定义类的目的。然而，必须考虑实用性，以及在动态生成方面利用现有内存和硬盘的能力。此外，当需要将一组属性暴露给用户时，鲁棒、智能的数据转换管理是关键。这是反对动态类型和 JavaScript 等语言的主要论据之一。

是的，需要为需要大量代码的语言提供非常强的类型，因为最简单的类型不匹配可能导致灾难性的后果。然而，当软件组件以一种巧妙的方式创建时，优化其代码片段并最小化代码冗余，动态类型可以使程序员以更快、更容易的方式进行编码；如果它带有更小的代码片段，可能出现的“不匹配”很容易被捕获和修复。

最终，即使是具有静态早期绑定类型的语言也需要机制来组合信息（例如转换或类型转换函数）；这正是动态类型语言（如 JavaScript）最终所做的。归根结底，每种数据类型本质上就是一组字节（或者说，一组数据项），它们具有特殊的行为，并且共同对用户有意义。不仅如此，通常还需要数据类型之间的操作（例如将字符串连接到数字和日期时间字段，或在日期和类型之间添加或减去小时、天、周、月等等）。

Web 浏览器和 HTML 的关键作用

如今，大多数 Web 浏览器都是一个庞大的应用程序，能够识别用户的大部分（如果不是全部）数据需求。它们可以处理视频、音乐、图片、文本（具有不同的颜色和大小）、几何图形（是的，JavaScript 允许绘制椭圆形和多边形，而无需非常复杂的编码，信不信由你），等等。

该范例背后的秘密是，Web 浏览器*没有*任何硬编码的组件，而是具有能够动态识别 HTML 标签并相应地应用现有行为的函数。当然，Web 浏览器会使用其他应用程序来正确地向用户呈现信息，但所有这些其他应用程序也都非常成熟且自成一体（黑盒），能够以适当的方式响应 Web 浏览器。

在本文发布之时（2008 年 11 月），Internet Explorer 的文件夹包含少于 3MB 的 DLL 和应用程序（即使考虑到它可以利用托管操作系统本身的资源；但这一事实恰恰证实了对坚实框架的需求理论）。Mozilla 略高于 30MB（主要是因为它自成一体，并且其大部分功能都与操作系统无关），其他情况也类似。那么，为什么 .NET 需要如此多的对象，而开发框架却需要超过 300MB？答案非常简单：*它因为设计糟糕而过度复杂。*有趣的是，.NET 的 Web 功能背后的任何东西都只是渲染主要的 HTML 和 JavaScript 代码。

那么，为什么还需要 .NET 呢，而我们却可以创建智能的 JavaScript 对象来动态生成 Web 浏览器能够轻松识别并相应处理的任何 HTML 部分？

这就是为什么 Web 浏览器如今可以成为一个独立的操作系统（这就是为什么出现了许多模拟专有操作系统的产品，称为“webOS”）。然而，Web 浏览器背后的理念，再次，不过是动态识别 HTML 标签和行为（JavaScript 或 Flash）代码。

最终，Web 服务器只是一个生成 HTML 代码的应用程序，然后将其发送回客户端（Internet Explorer/Mozilla Firefox）供其本地 DLL 进行解释。这就是它的开始方式（以前称为 CGI 或计算机网关接口），它是如何继续的（使用生成 HTML 代码的 .EXE 文件）直到今天（Java、JavaScript、Flash、ASP、ASP.NET、PHP 和其他最终生成 HTML 代码的平台）。

Web 浏览器背后的整个理念同样可以用于本地应用程序（在此提及的原因不一定与 Web 的普遍性有关，而是为了强调 Web 浏览器解释 HTML 代码的范例；它们只是动态渲染对象的应用程序）。

HTML、XML、CSS、JavaScript 不是微软发明的，这并不奇怪。

可重用性

面向对象编程的另一个重要概念是可重用性，它本应最大限度地减少重复编写相同函数或属性集的需要。换句话说，创建一个“黑盒”，允许忽略更深层次的细节，让程序员专注于新功能。

不幸的是，这是一个谬论，因为实际上，像 Visual Studio 和其他“强大的 RAD”工具并没有恰当地利用可重用性，而是*插入*了大量重复和冗余的代码到“程序员”在其软件项目中使用的不同部分。存在一定程度的可重用性，但最初在 OOP 中设想的概念并没有真正实现。

当然，这很大程度上与程序员的能力不足有关（这就是为什么上一段中的*词被引用了*），他们乐于从工具栏中拖放对象，然后在*无休止*的时间里编写应用程序的美容部分。简而言之，所有这些可视化工具都已成为一种机制，以比过去更高的速率复制*垃圾*；进一步使系统复杂化，从而导致软件项目成本更高，需要更大的开发团队、更大的项目管理团队、更大的测试阶段以及更大的缺陷跟踪系统。更不用说对具有更大内存/速度容量的设备的需求了（这让我想起我过去工作过的公司的一位财务总监的有趣评论。当我的一个同事请他批准购买更多内存时，他问：“这会改善库存系统吗？”；在我的同事回答“不”之后，他说：“那么，为什么需要更多的内存？一个字节就是一个字节，它保存的信息与几年前*相同*。难道字节在近几十年里*变大了*吗？您给它们*浇水*了吗，还是什么的？”）

简化优势

通过创建健壮、智能的对象，它们可以根据健壮的框架动态解释预定义的协议；程序员（和高级用户）可以简单地在一个设计精良的前端指定他们想要应用程序的解决方案的*业务*参数，而无需担心前端编程、业务逻辑和后端的细节。

业务逻辑可能需要特殊的处理和额外的编码，以及对其中技术细节（即开发人员）更深入的理解。但程序员应该忘记创建多个本质上相同的窗体或报告，只有它们的数据在内容、标签文本、用户交互（日历、复选框或单选按钮等）方面有所不同，而它们的主要区别在于它们的*业务*（语义）*含义*，而不是计算机如何处理它。

一个*良好*框架的两个主要候选者无疑是能够处理*任何* CRUD 实体的 CRUD 系统（创建、读取、更新、停用），以及一个报告系统（而不是像“Crystal”或“Reporting Services”那样的，因为它们背后的编程对于最基本和常见的报告需求来说仍然不必要地复杂）。

创建一个能够轻松处理常见的“第一”、“最后”、“前一个”、“下一个”、“编辑”、“保存”、“删除”（或者更确切地说，“停用”）、“钻取”任务；或处理“参数选择”、“报告收集”、“报告布局”、“报告总计/子总计”的框架，将节省程序员数千小时的时间，让他们只需更新一个简单的界面，定义数据的*含义*，而不是“如何”由计算机呈现和存储的细节。

M 语言是微软的一个完美例子（他们才刚刚开始研究），以及最近发布的一些其他语义语言（SDL），它们简化了对象及其功能的声明。我特别喜欢 JSON（JavaScript 对象表示法），因为它体现了“语义”（最终用户语言）业务定义的整个理念。

最终，即使是最复杂的用户也只关心他们使用的系统能够呈现他们正在寻找的数据，并且他们在不同复杂程度的级别上操作它（有些用户在使用 Excel 中的“数据透视表”功能方面非常精明，而另一些用户则只想要一个数据项的表格列表，并且对“数据透视表”一无所知）。在许多情况下，作为一名开发人员，我曾收到过由于基本的语法错误，如额外的逗号、撇号、引号或类似的错误而导致的问题。当我试图向用户解释这是一个*简单*的错误，修复起来很容易，而他们却未能成功时，他们通常会回答：“我不在乎，也不明白你在说什么。我只关心这个东西必须工作。”嗯，*高效软件开发*就是关于这个。

• 这是*对象真正可重用*。
• 这是*“黑盒”概念的真正应用*。
• 这是*真正利用当前内存和硬盘成本的降低*。
• 这是*真正的优雅/巧妙的编程技术*。

随着概念的日益普及，*可视化*编程越来越少，*巧妙*编程越来越多（让“可视化”由框架自动渲染），软件项目将以更短的时间完成，开发团队更小，因此缺陷更少，从而“缺陷跟踪”的需求也更少，更改的可维护性更快（因此，更简单、成本更低的变更管理协议）。当这一切发生时，软件项目将以更短的时间完成，并且成本将显著降低。

即使没有人正式定义这个术语，这种方法也有多个成功的例子。

不要让大型软件公司通过声称软件比实际复杂来吓唬你，仅仅因为他们的程序员不够聪明。