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

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

　　拥抱开源技术

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

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

　　避免过度炫技

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

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

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

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

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

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

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

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

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

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

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