预计阅读本页时间：-
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 著名文章，逐一探讨了对象—关系映射的缺点。——编者注）根据需要选择技术。首先决定什么是你需要的，接着为这些具体的问题评估使用技术。对任何要使用的技术，多问一些挑剔的问题，并真实地作出回答。
切身感受
新技术就应该像是新的工具，可以帮助你更好地工作，它自己不应该成为你的工作。
平衡的艺术
? 或许在项目中真正评估技术方案还为时太早。那就好。如果你在做系统原型并要演示给客户看，或许一个简单的散列表就可以代替数据库了。如果你还没有足够的经验，不要急于决定用什么技术。
? 每一门技术都会有优点和缺点，无论它是开源的还是商业产品、框架、工具或者语言，一定要清楚它的利弊。
? 不要开发那些你容易下载到的东西。虽然有时需要从最基础开发所有你需要的东西，但那是相当危险和昂贵的。
