如何做好企业/团队的技术选型？

好的技术选型，能最大程度地提高企业和团队的效率，从而开发出满足用户需求的产品。作为一线的技术管理者，他们都是怎样做的呢？

大公司或者大一点的团队的技术选型几乎不需要太多讨论，因为最后会不可避免地绕到技术官僚的话题上去。这里我简单说说技术型创业团队的技术选型问题。

拥抱开源技术

如果只能选择微软的技术路线，比如团队只会用微软技术，也不想学别的，那么似乎没有别的办法，将就一下吧。如果还有的选择，尽量使用开源技术。这样不但可以有效降低软硬件成本，还有更多的部署方案可供选择，服务器上线甚至还能避免病毒的侵袭。开源技术的好处是出了问题，你总有办法可以找到答案。而用微软的产品，可能平时不出问题，但一出问题，你根本没什么办法。微软的产品使用门槛倒是低，但复杂度可一点都不小，而且随着发展，成本越来越高。国内有几个大中型网站，比如天涯、5173、大众点评、京东等，怕是深有感触吧，有的因为成本太高而继续被捆绑，有的则破釜沉舟要摆脱这种束缚，但不管怎样，总要付出一定的开销。

开源技术路线有数种分支，该怎样选择呢？选择大路货，选择可以掌控的开源技术产品、语言、程序、框架，乃至解决方案。比如PHP，比不上Ruby阳春白雪，但用户基数大，总能找到不错的工程师。PHP虽然粗糙，但是管用。以PHP作为开发语言的成功产品不计其数，很多东西根本不需要你再开发，稍加定制即可。技术本身没有高下之分，差别在于使用技术的人。

避免过度炫技

技术人员创业最容易犯的一个错误就是“炫技”，即热衷于使用最新、最时髦的技术。新东西的确可以给技术人员以满足感，但也很快会将你的时间资源消耗进去，除非你准备做的是一款基础产品，否则你要花时间去学新规范、熟悉新功能、对付新出现的软件Bug……但这时你最需要做的是开发产品，而不是捣鼓其他东西。一些新技术或者方案，可以花些时间分析一下但没必要立刻就用，只需确保将来有一天能真的用上时，对一些重大的陷阱或是缺陷能够了然即可。

很多人神往37Signals的成功，但你一定要知道类似37Signals的团队，默默无闻地夭折掉的不知道有多少。每当看到创业团队就那么1~2个人还整天捣鼓Go、Erlang这些东西，并想硬生生地用到产品中去，我就知道，这样的团队要悬了。有这些精力和能力，应该想办法尽快让技术变现，研究一下怎样改进产品、怎样给用户带来更大的价值，而这些不一定用最好的技术才能做好。想办法尽快让产品发布，尽快接受更多人给你第一轮反馈，只凭创业团队几个人闭门冥想是很难出来好产品的，有时产品推出的时机比完备的功能更重要：GroupOn最早不过是搭建在WordPress上的几个页面，而阿里巴巴网站最初也不过是一个论坛，你又何必等到所有细节都打磨好呢？

拥抱开源技术，避免过度炫技，如果技术型团队创业（做互联网），这两条都能坚持的话，我想你已经抓住了问题的80%的部分，基本上你不会做太多的无用功。

另外，刚启动时不要直接招技术总监、技术经理、架构师这些看起来级别很高的人，因为他们未必认同你的想法和你现在的团队。建议找能实现你产品想法的人。最后有一点必须要说一下：不要因为一个人的技术喜好而舍弃整个技术团队，在任何时候这都是很愚蠢的事情。

作者冯大辉，丁香园网站CTO

在重大产品决策或者大规模应用开发前一般需要进行技术选型，其目的是为了降低产品研发的技术风险。所以首先需要明确为什么需要技术选型、需要达到什么目的，整个过程需要有一套的组织流程来保证。

一般可以将整个过程分为调研、候选对比、关键技术验证、原型验证几个阶段。在调研阶段主要调研对象是目前该范围业内主要产品以及开源产品，需要了解其主要技术特点和各自的优势和劣势；在候选对比阶段，是在前一阶段基础上选出两种倾向用于最终路线的技术进行进一步的研究和对比。在关键技术验证阶段，需要列出所有的技术验证点，对验证点描述、验证方法、验证步骤、验证前提、验证环境以及最后的交付物和评估方法指标在验证方案中体现；在原型验证阶段，主要是针对重点关注的场景，通过一个原型来整体验证比较。在这个阶段一般需要进行概念模型、编程模型以及结构设计例如设计时视图、系统结构图等，定义需要的API，必要时还需要划分子场景，在场景中包括场景描述、Feature、预研点以及相关设计。

当然也需要对人员角色进行分工，一般划分程序经理、开发人员、测试人员几种角色。程序经理需要确定原型目标范围，编写原型目标文档并组织评审；制订和跟踪原型开发计划，对原型进行验证，确保原型符合原型目标要求。开发人员需要从开发角度提出原型需求，评审原型目标文档，按照原型目标文档和原型开发计划完成原型相关设计和开发。测试人员需要Review原型目标文档，根据原型目标文档采用一定的测试手段验证原型是否符合原型目标要求。

在最近我们进行的ESB新产品中，就采用了类似上述的流程。我们确信技术选型的最主要目标是要自主掌控，所以从非常底层的技术开始，重点关注并发、资源隔离这样的目标，解决在不确定环境中实现交易控制和可扩展的目标。所以我们设计了一个三段式的SEDA架构，基本原则是要实现架构的资源可分配性，提升吞吐率，当然最初实现的功能可以比较简单。通过上述流程，有效保证了我们在新产品研发过程中的效率和产品架构质量。

最后，在技术选型产出物上，一般的结果可以有三类，有马上转化应用的新产品，也可以是结合现有产品的一个解决方案，或者是某个方面的一个提升点（如一个新的组件）。

作者冯兴智，普元信息资深架构师

关于公司/团队技术选型的话题涉及到很多非技术层面的问题，特别是大公司在技术选型方面，不可避免要受到企业官僚的影响。
下面我结合自己公司的实际情况，谈谈初创企业或小型开发团队的技术选型。技术选型涉及产品/项目开发流程中各个环节所用到的工具和技术。例如项目开发前期的需求收集、整理分析工具、开发阶段的IDE和版本控制系统、测试阶段的测试工具等。

我们作为初创企业在进行技术选型时会根据产品的需求、技术的复杂性、可扩展性、跨平台可移植性以及成本来做出最终的决策。

成本因素

初创企业的资源特别是资金往往不是很充裕，如果采用商业化的技术解决方案，往往价格不菲，像Visual Studio专业版、Windows Server、SQL Server的价格动辄上万，这种情况下不妨考虑一些免费开源的技术框架。比如使用SharpDevelop代替Visual Studio，MySQL代替SQL Server。此外，也可关注并加入一些针对初创企业的扶植计划。例如我们创业前所工作的公司采用的都是微软技术，大家对微软技术掌握得很熟练，这样自己成立公司开发自己的产品时同样优先考虑微软技术。我们通过加入微软的BizSpark计划，有效降低了成本。

复杂性，成熟度

我们在做技术选型时最忌讳的就是盲目追崇新技术和框架。有些技术刚刚面世不久，还没有成熟的社区支持和成功案例。如果这时为了赶时髦或者在产品的推广宣传上加点花头而采用新技术的话，往往会导致项目陷入泥潭。采用不成熟技术而导致失败的案例比比皆是，如网景在Java刚面世不久就使用Java重写Netscape Navigator浏览器，导致用户体验大幅下降及用户群的流失。还有当时被称为下一代Windows客户端技术的WPF，到现在发展得仍然不瘟不火，如果仅仅是为了更炫的展现效果而使用WPF，结果肯定会得不偿失。

产品自身因素

技术选型不可避免地要以产品为中心。如果产品是Windows智能客户端软件，那么微软的技术框架必然成为优先考虑。如果开发Android软件，Eclipse和Android SDK同样必不可少。

作者石钰，奈特软件联合创始人、首席架构师

我在微软和腾讯从事了三年的软件测试和团队管理工作，期间涉及两大类的研发工作：第一，用于质量控制的各种平台系统，例如缺陷管理系统、用例管理系统、产品健康指数可视化系统、自动测试管理系统等；第二，用于具体的产品测试工具，例如桌面软件的UI自动化测试工具、JavaScript自动化测试工具、Web服务压力/性能测试工具等。

在团队的建设和技术选型上，遇到过一些困惑也走过一些弯路，总结出来有两点经验。

阅读公司文化，借鉴成功团队经验

测试团队一定要深刻阅读和理解公司文化，作为其技术选型的首要考虑因素。比如，在微软，无论是构建质量控制系统，还是开发各种产品测试工具，都以Windows+IIS+.NET作为技术框架；在腾讯，就会选择LAMP这样的开源技术框架。

在选定了技术框架的基础上，还面临一个问题，就是应该如何去设计和实现出具体的系统或者工具。一个非常重要的经验就是一定要借鉴成功团队的经验，站在巨人的肩上。例如，当初在腾讯，我们需要评测QQ地图的POI检索功能的质量和用户满意度。于是，我们花两周时间设计了一个自以为完美的盲测系统，结果在评审时才发现该盲测系统功能过于简单而且性能达不到指标。后来，我们在与腾讯SOSO团队讨论时，才发现他们经过多年的研发，已经有一款非常完善的搜索盲测系统，直接借鉴过来，就能很好地解决项目测试的问题。这点特别是对很多新任命的团队负责人，是很重要的经验。

敏捷务实，持续集成，切勿过设计

工程的基本要素是实用和强调执行力。对于一个软件/互联网企业或者团队而言，最重要的是先解决眼前遇到的具体问题，而不是盲目追求系统的扩展性和性能。例如，我们在测评QQ地图后台服务的性能状况时，首先想到的是选用的测试方案要具备良好的功能特性，可扩展性要强、足够开放，能够与已有的一个研发管理系统做集成。按照这个标准，我们选择了LoadRunner，这是一个比较复杂的工具，光配置就花掉了大量的时间。结果，导致实际测试的时间太靠后，发现的性能问题都无法在即将发布的版本中得到修正。这就是一个非常典型的因为过设计而引发的技术选型耽误工程进度的例子。后来，我们选用http_load这个开源、简单、实用的工具对后台服务做快速的压力测试，从而在第一时间得到测试报告。然后在没有测试任务的时候，花时间将该工具集成至研发管理系统中，做到了持续集成。

其实总结起来，测试团队的技术选型首先要顺应公司的框架性要求，然后在具体实施过程中，要以解决问题作为决策目标，多向成功团队取经，敏捷务实，切勿过设计。

作者刘舒，阿里巴巴高级产品经理，曾任微软测试开发工程师、腾讯测试经理

本文选自《程序员》杂志2011年03期，更多精彩内容敬请关注03期杂志

《程序员》杂志订阅火热进行中