12.合理地使用技术

“你开始了一个新的项目,在你面前有一个长串关于新技术和应用框架的列表。这些都是好东西,你真的需要使用列表中所有的技术。想一想,你的简历上将留下漂亮的一笔,用那些伟大的框架,你的新应用将具有极高技术含量。”

阅读 ‧ 电子书库

广告:个人专属 VPN,独立 IP,流量大,速度快,连接稳定,多机房切换,每月最低仅 5 美元

从前,作者之一Venkat的同事Lisa向他解释自己的提议:她打算使用EJB。

Venkat表示对EJB有些顾虑,觉得它不适合那个特殊的项目。然后Lisa回答道:“我已经说服了我们经理,这是正确的技术路线,所以现在不要用扔‘炸弹’了。”这是一个典型的“简历驱动设计”的例子,之所以选择这个技术,是因为它很美,也许还能提高程序员的技能。但是,盲目的为项目选择技术框架,就好比是为了节省税款而生孩子,这是没有道理的。

在考虑引入新技术或框架之前,先要把你需要解决的问题找出来。你的表达方式不同,会让结果有很大差异。如果你说“我们需要xyzzy技术,是因为。。。”,那么就不太靠谱。你应该这样说:“。。。太难了”或者是“。。。花的时间太长了”,或者类似的句子。找到了需要解决的问题,接下来就要考虑:□ 这个技术框架真能解决这个问题吗?是的,或许这是显而易见的。但是,这个技术真能解决你面临的那个问题吗?或者,更尖锐一点说,你是如何评估这个技术的?是通过市场宣传还是道听途说?要确保它能解决你的问题,并没有如何的毒副作业。如果需要,先做一个小的原型。

□ 你将会被它拴住吗?一些技术是贼船,一旦你使用了它,就会被它套牢,再也不能回头了。它缺乏可取消性(查阅【HT00】),当条件发生变化时,这可能对项目有致命打击。我们要考虑它是开放技术还是专利技术,如果是开放的技术,那又开放到什么程度?

□ 维护成本是多少?会不会随着时间的推移,它的维护成本会非常昂贵?毕竟,方案的花费不应该高于要解决的问题,否则就是一次失败的投资。我们听说,有个项目的合同是支持一个规则引擎,引擎一年的维护费用是5万美元,但是这个数据库只有30条规则。这也太贵了。

当你在考察一个框架(或者任何技术)的时候,或许会被它提供的各种功能吸引。接着,在验证是否使用这个框架的时候,你可能只会考虑已经发现的另外一些功能。但是,你真的需要这些功能吗?也许为了迎合你发现的功能,你正在为它们找问题。这很想站在结账处一时冲动而买无用的小零碎(那也正是商场把那些小玩意儿放到那里的原因)。

不久前,Venkat遇到了一个项目。咨询师Brad把一个专有框架卖给了这个项目的管理者。在Venkat看来,这个框架本身也许还有点儿意思,但是它根本不适合这个项目。

尽管如此,管理者却坚决认为他们要使用它。Venkat非常礼貌地停手不干了。他不想成为绊脚石,阻碍他们的工作进度。一年之后项目还没有完成——他们花了好几个月的时间编写代码来维护这个框架,为了适应这个框架,他们还修改了自己的代码。

Andy有过相似的经历:他的客户想完全透明地利用开源,他们拥有“新技术大杂烩”,其中的东西太多,以至于无法让所有的部分协同工作。

如果你发现自己在做一些花哨的东西(比如从头创建自己的框架),那就醒醒吧,闻闻烟味有多大,马上该起火了。你的代码写得越少,需要维护的东西就越少。

例如,如果你想开发自己的持久层框架,记住Ted Neward 的评论:对象—关系的映射就是计算机科学的越南战场(Ted Neward 曾写过The Vietnam of Computer Science 著名文章,逐一探讨了对象—关系映射的缺点。——编者注)根据需要选择技术。首先决定什么是你需要的,接着为这些具体的问题评估使用技术。对任何要使用的技术,多问一些挑剔的问题,并真实地作出回答。

阅读 ‧ 电子书库

切身感受

新技术就应该像是新的工具,可以帮助你更好地工作,它自己不应该成为你的工作。

平衡的艺术

? 或许在项目中真正评估技术方案还为时太早。那就好。如果你在做系统原型并要演示给客户看,或许一个简单的散列表就可以代替数据库了。如果你还没有足够的经验,不要急于决定用什么技术。

? 每一门技术都会有优点和缺点,无论它是开源的还是商业产品、框架、工具或者语言,一定要清楚它的利弊。

? 不要开发那些你容易下载到的东西。虽然有时需要从最基础开发所有你需要的东西,但那是相当危险和昂贵的。