PDFIDE 的大爆炸理论
CASPAR BOEKHOUDT，信息方法学
当您思考着不断扩展的 IDE 宇宙的浩瀚时，您可能会想：“一个可用的 IDE 要求是不是太高了？”
还记得那些美好的日子吗？那时开发只需要一个文本编辑器、一个编译器和某种调试器（如果仅仅使用几个 printf() 语句还不够的情况下）。在计算机发展的早期，这些都是独立的工具，在开发的黄金圈中迭代使用。在某个时候，我们意识到更紧密地集成这些工具可以加快开发过程。因此，集成了开发环境 (IDE) 就诞生了，它是一个用于软件开发的框架和用户环境，实际上是一个对软件创建至关重要的工具包。起初，IDE 只是简单地连接了三大件（编辑器、编译器和调试器），但如今大多数 IDE 都远远超出了这些最低要求。事实上，近年来，我们目睹了 IDE 构成功能的爆炸式增长。
这难道不会让您思考这一切将走向何方吗？我一直在想，这是否可能类似于大爆炸。该理论假设宇宙始于一场猛烈的爆炸，将物质抛向太空，导致我们现在观察到的宇宙持续膨胀。但它的未来会怎样呢？有很多理论：有些人认为它将继续无限膨胀；另一些人认为膨胀会减慢并最终停止，达到平衡；还有一群人相信振荡行为，即宇宙在达到最大膨胀点后将再次开始坍缩（有时称为大坍缩）。对这种混合局面重要的和深刻的补充是能量、熵和混沌的考量——这些在当今的开发者世界中都非常明显。
自从 1964 年 Dartmouth Basic 推出了可以说是第一个 IDE 以来，我们已经看到了许多 IDE 的兴衰。几乎从任何角度来看，IDE 多年来都取得了巨大的进步，但显然这还不是一个处于平衡状态的宇宙，而且许多（如果不是全部）这样的开发环境都存在严重的缺陷。今天的 IDE 技术水平揭示了一个持续不断的扩展，其中 IDE 似乎每分钟都在变得越来越大。但是，IDE 供应商要实现一个简单的常识性目标还有很长的路要走：让开发人员的生活更轻松，使开发团队更高效，并产生更高质量的软件产品。
今天的开发问题
十年前，生活要简单得多。我们大多数人通常只用一种特定的语言编写代码，在一个特定的操作系统环境中运行，这几乎就是您的全部工作。也许在尝试掌握特定系统的所有 API 时会遇到一些最初的难题，也许您还需要掌握一些其他供应商的分层产品，这些产品也是您的整体解决方案鸡尾酒的一部分，但这已经是糟透了。
如果您像我一样，那么如今您正在为具有更多移动部件的系统进行开发。对于当今多层 Web 部署的应用程序，我们有很多新的难题。首先，开发人员可能需要至少了解四种基本编程语言：C++、Java/J2EE、VB 和 C#/ .NET。开发人员还需要相当程度地了解几个关键的操作系统环境：Unix（Solaris、HP-UX 和 AIX）、Linux、MS Windows 和 Macintosh（以及可能的 Pocket PC 和 Palm）。接下来是各种 Web 部署的数据描述表示，例如 HTML、WML、XML、XSLT、XSD、DTD、CSS——然后是数据访问方法和后端集成之类的东西，例如 SQL、JDBC、ADO 等。还有您可能需要在前端使用的各种脚本语言和技术：JavaScript、CGI、JSPs/struts 和 servlets（用于 J2*E）或 ASP/ASPXs（用于 Windows）、Perl、Python 和 PHP。最后，我们不要忘记所有这些组件化技术，例如 EJBs 和 COM/COM+。我们甚至还没有开始谈论 Web 服务的进展。
这个问题的最糟糕之处在于，当您最终了解了当今结局中涉及的所有不同部分时，您必须确保所有这些不同的参与者在最终的首次亮相舞会上相遇时能够愉快地共舞。遗憾的是，除非您首先进行一系列试舞以在他们盛大的公开演出之前看到他们的全部表演，否则很难看到这种情况发生。
那么，我们到底有什么可以使用的呢？让我们看看当今开发领域的状况。
今天的工具：“超越你的能力，成为一个 IDE”
您是否注意到，昨天相当有用的独立工具可能已被包装并打包成今天的 IDE？许多工具供应商被工具集成的闪闪发光的奖品所迷惑，似乎将“集成”与“将所有工具都放在一个屋檐下”混淆了。为了提供一种工具或组件来满足一个包罗万象的 IDE 中每个可以想象的开发人员需求，供应商未能专注于改进其 IDE 中提供的每个特定工具的功能。
更重要的是，真正的集成需要考虑特别重要的工具集合的协同作用（例如 Java 类文件导航器、源代码浏览器/编辑器和 Java 开发平台的调试器）。相反，IDE 供应商似乎正在提供的功能，往往首先急于通过捆绑许多组成组件（无论是其他集成工具、向导还是附加组件）来“覆盖地球”，而对软件开发过程几乎没有价值。
哥斯拉来晚餐了：系统要求
IDE 供应商旨在通过在其产品中捆绑所有此类功能来减轻我们开发人员的痛苦。实际上，IDE 有能力让您的生活变成人间地狱（我发现通常就是这种情况）。仅仅这些 IDE 的大小似乎就很荒谬。表 1 回顾了一些流行的 IDE 的推荐系统要求（在 Windows 平台上）。
实践经验告诉我，如果要让它们稍微有用一些，每个 IDE 都需要比广告宣传的更多的资源。因此，虽然这些轻量级“用餐要求”的幻想可能继续在产品的营销材料中流传，但任何以最低水平进行有意义开发的开发人员都会很快发现自己身处一个慢动作世界，或许为“停机问题”的概念增添了新的含义（参见 http://www.cgl.uwaterloo.ca/~csk/halt/）。
“又胖又蠢不是人生的出路，孩子”（我们需要什么，不需要什么）
随便挑选今天的主要 IDE 中的任何一个，您都会发现它们大多数都提供了一系列工具：XML 编辑器、解析器和验证器；XSLT、DTD、HTML、CSS 和文本编辑器；FTP、SFTP、Telnet 和 SSH；源代码和版本控制软件；数据库客户端等等。一些 IDE 甚至捆绑了整个应用程序服务器和数据库。尽管这些单独的功能都没有什么不好，但不幸的结果是橄榄球队的“堆积”。供应商用您从未要求的工具埋没您。不幸的是，核心工具无法提取，导致空间和其他资源的严重浪费。
此外，许多组成工具——即使是那些旨在解决重要功能的工具——也常常只是玩具。尽管单个供应商提供并集成到其框架中的许多工具可能对最基本的任务有用，但它们通常不够强大，无法满足您的全部需求。您最终会同时打开至少六种不同的开发工具和/或环境，每种工具都充当一个单独的 IDE，并配有集成的工具和相关的包袱。
数量级上来说，使用 IDE 的组合（包括每个 IDE 中包含的大量大多无用的功能）不如独立使用更原始的工具有用。这些功能丰富的捆绑包不仅消耗宝贵的系统资源，而且它们的性能负担，加上它们给您带来的干扰，浪费了您的时间——而时间是当今高压快速周转软件开发生命周期中最宝贵的商品之一。
例如，尽管 Visual Studio .NET、NetBeans IDE、Eclipse 和 Sun ONE Studio 都集成了 XML 编辑器和 HTML 编辑器，但您会迅速发现自己正忙于下载和安装 xmlspy 或 Dreamweaver（或两者兼而有之）。现在打开了三个 XML 编辑器，以及每个 IDE 带来的任何其他集成工具，但这些工具对于您当前的任务来说根本不需要。这些旨在成为复杂开发项目的救星的工具集成环境，具有讽刺意味的是，可能会通过吞噬您的系统资源并迫使其在一种或多种此类开发工具的组成部分之间颠簸来减慢开发速度。
这一切都发生在大多数编程从业人员需要越来越根本地依赖这些工具来帮助管理他们正在其中开发组件设计的日益复杂的软件系统的规模之时。工具供应商最好专注于其工具的主要目的：帮助开发人员构建优雅的、粒度合适的组件，并将它们集成到正在开发的整个软件系统中。相反，我们观察到一些功能，这些功能充其量只会增加臃肿，最坏的情况实际上会阻碍开发。有什么出路吗？
表 1 资源比较 |
||||
| |
Sun ONE Studio 5* | NetBeans 3.5 IDE | Visual Studio .NET 企业架构师版 | Macromedia ColdFusion MX |
| CPU | 奔腾 III 1 GHz |
奔腾 III 700 MHz |
奔腾 III 600 MHz |
奔腾 - 不适用 |
| 内存 | 768 MB | 384 MB | 160 MB | 512 MB |
| 磁盘空间 | 700 MB | 125 MB | 系统驱动器上 900 MB，安装驱动器上 4.1 GB | 400 MB |
| *标准版 数据编译自公司网站的产品信息页面。 |
||||
模块化（少即是多，多即是少）
模块化为克服当今开发人员框架中的巨型怪物提供了希望。在 IDE 或开发人员框架中支持添加和删除模块，使开发人员能够仅安装他们需要的工具，而不会在不相关的模块上浪费资源。他们只下载他们需要的模块，并且只将必要的工具加载到内存中。这节省的不仅仅是磁盘空间和内存——这也意味着不会浪费时间在启动时初始化模块，也不会浪费时间弄清楚这个工具是什么以及它的作用。此外，如果当前的工具只是不称职，您可以轻松地删除它，并（在存储副本后）用更好、更合适的模块替换它。
那么，如果模块如此出色，为什么 IDE 如此庞大，为什么包含的模块不够有用呢？
大多数 IDE 都支持插件或附加模块，但此功能也带来了一系列自身的问题。IDE 默认可能包含太多模块，并且 IDE 附带的许多模块根本不够强大，或者在某种程度上受到限制，以至于除了最简单的用途之外都毫无用处。例如，Sun ONE Studio 和 NetBeans IDE 都包含一个 CVS（并发版本系统）客户端模块，但该客户端不支持 SSH（安全外壳），并且仅支持 pserver 连接。集成的 XML 编辑器是另一个例子。Sun ONE Studio、NetBeans IDE、Eclipse、Visual Studio .NET、Macromedia Dreamweaver 和许多其他 IDE 都捆绑了其中一个。大多数都包含一个 XML 解析器来验证您的 XML 是否格式正确，但可能缺少 XSLT 工具、XML 模式或 DTD 生成器/编辑器或 XPath 检查（或全部三个）——从开发人员的角度来看，有效地使用 XML 所需的重要功能。
模块功能增加了选择要使用哪个模块的负担。除了担心您的开发系统是否有足够的内存来加载巨大的 IDE 之外，您还必须确定最佳可用模块。您的团队成员是否为同一任务使用不同的模块，这可能会产生不兼容的代码（或者，天哪，可能比您正在使用的模块更好）？
另一个大问题是，大多数模块都必须专门针对特定的 IDE 制作。如果您要开发一个新工具，您会发现您必须为每个主要的 IDE 开发一个新模块。工具供应商看到当前的状态，并决定：“嘿，真麻烦。为什么要编写一个只能与一个特定 IDE 一起使用的模块？我最好编写一个单独的工具。顺便说一句，我最好把所有这些额外的简单工具都扔进去。伙计，我有自己的 IDE 了！”因此，我们发现自己陷入了越来越多的 IDE 的可怕螺旋中，每个 IDE 都变得越来越大。
向导（或“与三体人的麻烦”）
如今，如果哪个 IDE 不会自动为您编写代码，它怎么能认为自己是体面的呢？欢迎来到向导。好吧，如果使用得当，向导可能会非常出色。它们可以通过生成用作完成复杂组件起点的必要基础代码来显着提高生产力。另一方面，向导可能对软件工程师的健康非常有害。除了消耗空间和增加加载时间外，设计糟糕的向导有时可能很虚弱，生成的简单存根背后没有任何实际功能。这几乎毫无用处。在其他情况下，向导可能会生成过多的机制，坦率地说，这可能比其他情况更糟糕。
假设向导生成了合理数量的代码，那么该代码的质量可能会有很大（且疯狂的）差异。有时，向导生成的代码可能非常复杂，以至于普通开发人员无法理解它，因此理所当然地不愿修改它。在许多情况下，向导会掩盖一些输出代码的功能，而您实际上需要理解这些功能（向导的命名或许很恰当）。这很容易使您与系统在生成的代码运行的级别上的关键方面隔离开来。许多经验不足的开发人员进来时只知道如何驾驶这些工具，但不了解周围的机制。这可能会很快导致使用工具来代替适当的思考。
例如，Visual Studio .NET 的简单对象访问协议 (SOAP) Web 服务/客户端向导易于使用，并且非常擅长生成简单但完整的 Web 服务和客户端。除了生成幕后代码外，Visual Studio .NET 还为每个 SOAP 客户端生成一个 Web 服务代理。只要您不需要修改生成的代码，它就可以很好地工作。但是，如果需要增强 SOAP 客户端以执行更复杂的操作，则需要向上帝祈祷 IDE。首先，像大多数向导一样，生成的代码仅包含描述函数用途的最简短的注释。缺少的是描述其功能背后的逻辑的文本（为什么它选择某些类，为什么它执行它所做的事情，以及它是如何执行的）。
向导鼓励懒惰的开发人员（我们中最优秀的一些人也很懒惰）过度依赖生成的代码。如果它看起来可以工作，我们为什么要费心去理解它做了什么？还记得我的 Visual Studio .NET SOAP 客户端代理示例吗？默认情况下，向导为每个 SOAP 客户端创建一个代理类。您可能会争辩说，只要它能工作，为什么要修改它？另一方面，拥有一个可以被所有常见的 SOAP 客户端使用的 Web 代理不是更有意义吗？只需进行少量更改，就可以将项目设计为具有一个代理类来处理一组客户端，而不是每个 SOAP 客户端一个代理。当调试和修改单个代理类而不是每个服务一个代理类时，有明显的好处。可惜向导和 IDE 无法处理这个问题。
大多数向导也缺乏真正的选项。它们可能会为您提供诸如您希望它包含的类的名称以及要查找的包名称之类的琐碎内容，但它们的可配置性不高。事实上，Visual Studio 为什么不为您提供关于代理类的选项，这让我百思不得其解。为什么不添加一个简单的选项，让您可以选择是希望它创建一个特定于您的客户端的新代理，生成一个可以被一组类似客户端使用的通用代理，还是引用现有代理？那将很有用。
当然，向导也被认为会生成不完全符合行业、项目甚至个别开发人员自己的编码标准的代码。如果生成的代码可以工作并且永远不需要触及，这可能被认为是可容忍的。但是，在许多情况下，仅通过稍微调整生成的代码就可以显着提高事项（我敢提性能吗？）。
当您调试代码时，您会遇到另一个重要问题：如果问题出在生成的代码中怎么办？如果您只是无法理解所有这些混乱怎么办？我想这永远不会发生在您身上！您认识多少初级人员认为向导生成的代码是万无一失的？即使是经验丰富的开发人员也可能花费数小时甚至数天的时间在自己的代码中寻找问题，而从不怀疑生成的代码是罪魁祸首。如果微软或 Sun 的向导生成了代码，那么它不可能是错误的。再想一想。
向导并不总是最佳答案，在许多情况下，它们带来的麻烦比它们的价值更大：用 Edsger W. Dijkstra 的话来说，它们可能更属于问题集而不是解决方案集。（“我们如何讲述令人痛苦的真相？”在《计算机精选作品：个人视角》，施普林格出版社：纽约，1982 年。）
我们走向何方？
虽然无法确定未来会怎样，但我们可以推测一些可能的演变方向。如果您觉得大爆炸的比喻很贴切，那么可能会有三种潜在的结果：IDE 可能会继续无限膨胀；它们最终可能会停止膨胀；或者它们可能会达到一个必须再次缩小的点。
永恒膨胀
如果 IDE 宇宙继续其扩张趋势，通过累积比我们目前的思维所能想象的更多集成工具而变得越来越大，那会怎么样？
在我看来，即使是摩尔定律也无法为这条道路带来任何希望。Visual Studio .Net 2003 Architect 装在五张 CD 上，这让我怀疑我必须将多少张 CD 放入我的电脑才能安装 2006 版本。也许它很快就会装在它自己的硬盘上，或者考虑到 Web 下载软件的趋势，也许我应该计划每季度休假七八天来以这种方式安装它。一旦我为我需要的六七个 IDE 加载了软件，我只需插入四个新的 64 处理器刀片和半个手提箱的内存，就可以开始运行了。
大竹子——高原
第二种可能性是，在未来的某个时候，IDE 将包含一个有限的集成工具集合，足以完成每项任务。对未来持乌托邦式观点，这条道路将引导我们走向一个“真正施瓦辛格式”的开发环境。这种结果的含义在许多方面与永恒膨胀模型相似。首先，这样的环境必须包含支持每项可能的开发任务的工具（最重要的是，要很好地支持它们）。此外，这些工具必须非常强大，以至于您不需要使用任何其他工具。
当 IDE 包含所有可能的工具，并且没有可以想象的任务可能需要新的集成工具时，它的大小保持不变。这种结果似乎不太可能发生。您能想象有一天我们会拥有能够处理可能出现的每项任务的工具吗——这些工具能够处理每种可能的未来技术、模式和任务？仅仅是人性似乎就确保了我们永远无法实现它。即使我们决定选择一种主要的开发宗教（例如，Java 与 .NET），我们真的能够同意只使用一个 IDE 吗？
这条道路的讽刺之处在于，在一定程度上，营销和产品差异化继续基于定量功能清单（主要是嵌入式工具与它们的个体质量、它们的整体集成或任何实际的最终开发人员生产力的衡量标准），那么在不断扩展的 IDE 宇宙中，许多不断扩展的 IDE 星系的未来，以及由此暗示的可怕的生产力下降，几乎是不可避免的。
然而，尺寸高原的一种可能的途径是完美的模块化。如果 IDE 能够实现这一点，我们或许能够拥有尺寸保持不变的开发环境，其中包含开发人员需要的所有工具，并且能够动态交换模块以获得更好或更新的模块来处理更新的技术、模式和任务。换句话说，IDE 比目前更大，但在未来的某个时候，由于旧模块被丢弃和新模块被添加的平衡，将停止扩展。
公平地说，在 .NET 和 Java 阵营中，这种情况已经开始发生。如果工具供应商甚至可以开始就不同工具组件和模块之间的文档化接口达成一致，那么跨 IDE 模块可能会有一些小的希望。这引出了我们接下来要讨论的...
大坍缩
至少有可能在未来的某个时候，我们的软件开发宇宙和/或其各自的 IDE 将开始缩小尺寸。为了使这种模型奏效，IDE 要么必须变得高度模块化，要么不同的工具集成框架之间必须发展出更优雅的关系，或者两者兼而有之。也就是说，我们可以想象一个提供独立的可集成工具的宇宙，这些工具可以在多个 IDE 平台/框架中重用。这需要高效的模块化组件，这些组件可以移植到许多不同的开发人员框架和平台。
今天，许多模块仅适用于特定的 IDE。如果可以构建它们，以便模块可以在竞争的 IDE 中使用，那么软件达尔文主义应该会产生足够强大的模块，以至于不需要围绕每个工具都有一个完全独立的 IDE。如果可以将 xmlspy 加载为模块并在 Visual Studio .NET、Dreamweaver 或 Sun ONE Studio 中使用它，那不是很好吗？想象一下，一台计算机上只安装了一个 XML 编辑器——而不是平均开发人员机器上当前安装的 10 到 20 个。如果这成为可能，那么单独的工具（或它们的小套件）可以变得更加专业化，专注于它们自己的主要目标。
想象一下，在一个世界里，您不必打开 10 个应用程序，其中 7 个应用程序包含完全相同的工具。我们只能梦想和希望。
今天的 IDE 由相互竞争的供应商设计，他们不友好相处。微软开发和包含一个用户可以向其中添加由 Sun 开发的模块的接口的可能性目前微乎其微（尽管两者都会争辩说他们已经支持这样做）。相反，IDE 供应商似乎受到一种明显的竞争驱动，即添加新功能——不是因为开发人员要求它们，而是因为它们在营销规格竞争中表现更好。
结论
尽管 IDE 不会消失，但它们的未来仍然不明朗。与企业资源计划 (ERP) 软件和其他应用程序一样，它们的规模和复杂性不断扩大，以缩小与竞争对手的功能差距，IDE 必须找到一种方法来管理复杂性并提高开发人员的生产力。
我们发现自己身处 IDE 大爆炸之中。IDE 随着每个新版本的发布而变得更大，它们的扩展似乎正在加速。我们这些软件工程师和开发人员，我们的工作是理解这个 IDE 宇宙，我们一直都在努力掌握知识和理解，因为我们的开发环境似乎呈指数级地向各个方向扩展。
如果使用得当，开发工具可以极大地加快开发速度，但这些锋利的工具缺乏安全防护。在不明智的人手中，这些工具可能是危险的；当坏程序员使用今天的最佳工具时，只会加速我们的灭亡。然而，良好的软件开发仍然依赖于既了解业务问题又了解代码，并且能够应用团队和行业最佳实践、利用标准并对相关技术有整体了解的开发人员。您只使用和做您知道的事情。
今天的工具就像一级方程式赛车。它们包含许多实验性部件，当您坐在方向盘后面时，您的生命确实掌握在您自己手中，尤其是在您被要求全速驾驶它们时。我对赛车队的建议是什么？确保你们有训练有素的赛车手。
与 IDE 一起的开发人员的一天
你们有多少人有幸只专注于一项开发任务，甚至只专注于一种开发语言？我发现我必须一次打开大约 10 个开发工具应用程序：一个用于 XML，一个用于 HTML 和 JavaScript，一个用于 C# 或 Java，一个用于 SQL，等等。在 Web 应用程序开发项目中，我通常会打开以下应用程序：SecureCRT、TOAD、Sun ONE Suite 或 Visual Studio .NET、FTP、MS Word、Outlook、TextPad、xmlspy、Dreamweaver、Photoshop、Visio 等等（如图 1 所示）。
同时管理所有这些应用程序是一个主要的障碍。我扩展了我的任务栏，使其可以显示两行应用程序，但是，按照目前的速度发展下去，我的显示器很快就会有一半被任务栏覆盖，几乎没有空间留给正在运行的应用程序本身。然而，这使我成为 Alt-Tab（在 Windows 下）的大师。如果您还没有发现这一点，它就是按住 Alt 键同时操作 Tab 键的艺术，就像那些玩 Game Boys 的孩子（以半自动武器的方式），在您打开的不同应用程序之间循环切换。
IDE 的扩散
不仅每个给定的 IDE 都在自身范围内扩展，我还生活在一个由越来越多的独立 IDE 组成的宇宙中，如果我要涵盖完成我的开发项目所需的合适范围的语言和系统环境，我就必须掌握所有这些 IDE。对于我学习的每项技术，似乎都有一个相应的新的 IDE 让我掌握。我不但必须学习和掌握新技术（以及它所包装的新 IDE），我还必须掌握这个新 IDE 也选择集成的其他 30 个工具的无缘无故不同的用户界面；我最终发现这 25 个工具对其所谓的用途完全无用，因此必须用另一个供应商的工具替换它们。您听说过指数增长吗？我很快发现自己运行着 12 个不同的 IDE，情况看起来像死亡竞赛 2003。这种情况听起来您熟悉吗？我只能说 Code Warrior 的名字很贴切。
虽然现在我已经学会了如何使用这些 IDE，开发速度快了很多，但选择工具仍然是一个偏好问题（以及预算）。有一件事保持不变：无论您购买什么 IDE，即使它声称它为您所有的需求提供工具，一旦您超出最基本的任务，您肯定最终会使用“再一个”IDE。
集成的讽刺
我一直在观察到，厂商特定的工具或组件被集成起来，形成了它们自己的 IDE 巨石。我想要的是能够将功能组件（工具）集成到不同厂商的 IDE 中，并更容易地集成不同 IDE 本身产生的代码（以及它们通常代表的运行环境）。尽管一些框架特定的标准允许工具集成，但我没有看到允许工具组件集成到多个框架中的标准。
原则上，NetBeans 框架旨在为不同的开发者和/或厂商提供一个基础，以构建在该环境中集成的组件。作为一个开源环境，它旨在成为一个厂商中立的基础，用于集成开发者工具组件。然而，由于 NetBeans 越来越多地被 Java 采用，它似乎变得更加专注于解决 Java/J2EE 开发问题。.NET 的领域与这个星系几乎无关。
音频行业似乎已经解决了这个问题：我的 Sharp 电视似乎可以很好地与我的 Sony PlayStation、Bose 音响、Philips DVD 播放器和旧的 Atari 2600 配合使用。我对我的 IDE 的要求是否过分？显然是这样：不要要求 VS .NET 使用 Dreamweaver HTML 编辑器和 xmlspy XML 编辑器，而不是它捆绑的编辑器。IDE 制造商必须明白，开发者想要的只是针对每项任务的最强大的特定功能工具，并将它们封装在自己的 IDE 中。我希望他们停止添加功能，并开始定义框架接口。
开发者生产力 vs. 可持续性？
向导、IntelliSense 和调试功能（例如设置断点和单步执行代码）可以极大地提高生产力。但我看到 IDE 如何改变了我的合作开发者看待代码的方式。将代码调试出来比从头开始思考和设计代码更容易（例如，桌面检查代码的效率、准确性和其他问题）。这可能会在系统部署后发现错误时给我带来很多痛苦。如今，很少在代码中插入跟踪或日志语句，因为 IDE 在开发时是如此全能。
管理层（和市场）要求你和我更快地完成项目，但也期望我们不要粗心或草率地依赖允许更快编码的功能。我经常发现自己问管理层，“你们是想要做得快，还是做得对？” 确实，使用这些特殊的 IDE 功能（例如断点和代码步进，就像我构建它一样）而不是在实现本身中创建调试或性能分析框架，我可以更快地在功能上编写程序。但是，稍后，当系统投入生产时，我们很难弄清楚为什么它没有按预期工作。我发现我们陷入了两难境地，即快速编码和良好编码之间的平衡点在哪里。
CASPAR BOEKHOUDT，Information Methodologies (imi) 的负责人，imi 是一家为高等教育提供领先企业 Web 集成的公司，他是一位软件架构师和开发者。他是 Sun 认证的 Java 2 平台程序员和 IBM 认证的 XML 和相关技术 V1 开发者。他曾参与架构和规划，并使用 XML、XSLT、XPath、HTML、Java、C#、Perl、C++、JavaScript、VB 和 SQL 的组合开发了各种企业应用程序——在此过程中，他几乎使用了目前市场上所有主要的 IDE。可以通过 [email protected] 联系到他。
资源
NetBeans IDE 3.5.1（适用于 Java 平台）：http://www.netbeans.org。
Sun ONE Studio 5（适用于 Java 平台）：http://wwws.sun.com/software/sundev/jde/
Eclipse（适用于 Java 平台）：http://www.eclipse.org/。
Visual Studio .NET 2003（适用于 .NET 平台，支持 C#、VB .NET、J# 和许多其他语言）：http://msdn.microsoft.com/vstudio/productinfo/features/default.aspx。
Macromedia ColdFusion MX 6.1（适用于 ColdFusion）：http://www.macromedia.com/software/coldfusion。
Macromedia Dreamweaver MX 2004（适用于 HTML/DHTML）：http://www.macromedia.com/software/dreamweaver。
TextPad 4.7.0（通用编辑器）：http://www.textpad.com。
TOAD（SQL 编辑器）：http://www.quest.com/toad/。
WinCvs（版本控制）：http://cvsgui.sourceforge.net/。
最初发表于 Queue vol. 1, no. 7—
在 数字图书馆 中评论这篇文章
更多相关文章
Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
虽然加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。存在许多由各种安全要求驱动的加密哈希标准，但在非加密方面，存在一定程度的民间知识，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者凭直觉接受，良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改善 DevEx 的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果，研究生产力差异，从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。在其快速前进的匆忙中，它容易受到时尚的异想天开的影响，并且可能会忘记或忽略针对其面临的一些永恒问题的成熟解决方案。用例最初于 1986 年推出，后来普及，是那些成熟的解决方案之一。
© 保留所有权利。