前言Designing the Requirements： Building Applications that the User Wants and Needs在对IT应用程序开发思考了大约15年之后，我终于写出了这本书。20世纪90年代后期，我开始做IT架构，当时写了一本名叫《IT Architecture and Middleware： Strategies for Building Large, Scalable Systems》的书（那本书的第2版是与Peter Bye合写的，于2004年出版，现在还可以买到）。那本书讲的是构建集成应用程序（integrated application）所需的技术，以及怎样确保应用程序的可扩展性、高可用性以及安全性。那时还有其他一些人也持有类似想法，由于我们的基本思路是向开发者提供一些可复用的服务，使其能够通过集成技术来迅速拼装应用程序，因此，业界把Peter与我所提出的那种解决方案称为面向服务的架构（Service Oriented Architecture，SOA）。SOA显然有很多优势，但实际上并没有发挥太大作用，因为其中好像缺了点什么。我从一开始就怀疑，缺少的那个东西，应该是应用程序的开发。换句话说，我们没办法很好地回答怎样开发SOA应用程序这个问题。此问题也可以表述为：有人向我提出了一些要求，我该怎样确保最后得到的是一套SOA解决方案，而不是一个单独的应用程序呢？接下来的几年里，我对于架构问题想得少了一些，而对应用程序的开发问题，则想得比较多。
我刚开始编写应用程序，是在20世纪70年代后期。从那以后，我主要是在系统与环境软件的领域中进行bug修复及设计工作，我花了很多时间去修整数据管理软件，偶尔也会修复几个编译器或操作系统的bug。在这个过程中，我对系统软件的设计与编程有所接触。其后，我开始从事数据库和资源库的设计工作（对于版本控制问题，我有很多话要讲，但奇怪的是，没几个人愿意听）。到2000年的时候，我对计算机技术的很多方面都已经有了一些经验，但由于自己并没有直接从事大量的应用程序设计与编程工作，因此我还无法坦然地走到应用程序开发者面前，指出他们的做法是彻底错误的。
那时的程序开发专家对架构并没有多少兴趣，而是在开发方法上面彼此较劲。有些人崇尚BDUF（big design up front，大设计先行），他们提倡根据UML（Unified Modeling Language，统一建模语言）来做设计，提倡要安排好设计的结构，要用良好的文档描述这套设计，并且要在质量控制流程的监督之下完成整个设计。还有一些人崇尚敏捷（agile），他们认为应该尽快交付软件，然后通过一系列短期的迭代来对软件进行完善，使其满足利益相关者的需求。这两派的关键分歧，在于开发者与利益相关者之间究竟是什么关系。BDUF派认为两者是契约关系，认为软件开发项目应该有一个正规的需求收集环节，而敏捷派则认为应该把软件的功能分成小块，只有在准备实现某个小块的时候，才需要去制定详细的需求，而且认为应该在当前这一小块完工之后，就尽快把可用的软件拿给利益相关者去看。他们希望能够从利益相关者那里不断地获得反馈意见，并据此对软件开发的走向持续进行微调，以便最终实现出正确的产品。笔者试着把这种敏捷开发方法讲给IT领域之外的人听，那些人觉得这不太可靠，然而敏捷派对BDUF派的批评，则确实引起了共鸣。因为利益相关者在没有看到实际运行的软件之前，确实不太了解他们当时提出的那个程序到底会做成什么样。合约并没有一种神奇的能力，可以保证做出来的IT程序一定会讨人喜欢。
这两派都不能够让人了解SOA究竟为什么开发不出来。对于他们来说，这个问题似乎并不存在。
那么，应用程序的开发为什么会背离SOA呢？一个原因在于，很多IT项目无法在预算之内准时交工，而且也拿不出利益相关者想要的产品。这就给IT开发者造成了压力，而IT开发者在压力之下的一个反应，则是严格划定项目的范围。他们想要控制项目范围之内的所有事务，同时对范围之外的事情不闻不问。这种应用程序开发项目所实现出来的成果，是一个单独的应用程序。如果只做一个大项目，那就会得到一个大程序，如果分成很多小项目来做，那就会得到很多小程序。此外，由于大型IT项目特别容易失败，因此开发者总是愿意把大项目分成多个小项目，从而做出很多小的程序，而不是只做出一个大的程序。但是另一方面，IT架构师却总想劝说程序开发者不要去构建单独的应用程序，而是应该构建一些服务，并且构建必要的机制，使这些服务能够合起来满足项目的需求。架构师的这种想法，当时并没有实现。在21世纪初，笔者开始认真地观察应用程序的开发过程，这一观察我才发现，原来内向的开发项目会做到如此令人震惊的地步：就连程序员和数据库设计者之间的关系都相当紧张。程序员对当前项目的目标太过专注了，他们没心思去想这些数据应该如何在各种组织之间分享并管理。
于是，笔者打算对应用程序的开发做出第一个变革，我要找出一种对架构有利的方式，使得每个应用程序都能对整体的架构起到推进作用，而不是破坏作用。
如果项目变得内向，那么其中一个原因就是需求变得内向，换句话说，这是因为开发者只关注某
購物車/收銀台(0) | 在線留言板
| 付款方式
| 聯絡我們
| 運費計算
| 幫助中心 |
加入書簽
HOME
新書上架
