漫谈技术选型

  最近读了《恰如其分的软件架构》一书，尽管书本身没有帮我打开新世界的大门，但还是给了我不少的启发，在平时的软件开发中可以使用里面的很多核心思想，帮助我梳理清楚到底该想什么，该做什么。
  无论是最近的工作中，还是业余时间写开源项目的过程中，都会面临技术选型的问题。对于日常玩票性质的项目，技术选型从来不是一个非常要紧的事情。由于业余项目的目的更多是学习，因此可以使用更新的、自己没有使用过的技术。但是工作中的技术选型就没有那么随意了，最近在工作中也有涉及技术选型的经历，这篇文章用以梳理一下最近做技术选型的思路，里面使用的一些方法论有借鉴《恰如其分的软件架构》一书，所以说这本书给了我不少的启发。

从需求与风险出发

  软件工程从来不是一件天马行空的事情，每一个软件工程师都是在一定的问题域里面设计软件、开发代码的。功能需求是我们最先接触的问题域，也是最显而易见的问题域。几乎每一个软件工程师都知道我们的系统必须满足特定的功能，所以我们选择使用的技术也是立足于我们准备实现的功能需求的。
  满足功能需求是每一个工程师的共识了，所以不做过多论述了，我想把注意力集中到风险中。这里的风险主要特指软件的非功能性风险。由于功能性的风险需要由产品经理或系统分析师把控，所以往往是开发人员无法控制的。另一方面，产品经理或系统分析师可能不会把注意力放在系统的非功能性需求上，因此开发人员就必须把注意力集中到非功能性需求了。
  这里用了“风险”一词，而不是用非功能性需求，除了受《恰如其分的软件架构》中提出的“风险驱动设计”启发以外，更想说明对于不同的系统，所面临风险的重要程度是不一样的，甚至不同的系统对非功能性需求的取舍也是不一样的。重要的、必须实现的非功能性需求才能称之为风险。更重要的是，“风险”一词可以提醒开发人员，甚至是所有系统的利益关系人（客户、产品经理、测试人员等）功能性风险如果处理不好，影响面可能是局部的，而且问题很容易被暴露；但非功能性风险处理不好，影响面可能是整个系统，而且问题可能等系统上线后才可能发现。
  在开始考虑技术选型问题之前，识别系统可能面临的风险也是非常重要的一步。对于处理敏感数据的系统，安全性是首要考虑的风险；对于包含复杂业务逻辑的系统，可扩展性和可修改型是首要考虑的风险。开发人员，甚至是所有的系统干系人，都应该都系统可能面临的风险有一个共识，包括系统的非功能性风险有哪些，这些风险的重要程度又是怎么样的。
  风险为我们技术选型提供了更多的线索和方向，不至于在茫茫的技术海洋中迷失。仅仅根据需求进行技术选型，往往是提供不了足够的理由让我们下定决心使用某个技术的。细想一下，在我们遇到的90%的功能里面，有多少是python能实现而java实现不了的？开发java web程序的时候，struts和spring mvc的功能都没有非常本质的区别，那么该如何选择呢？同样的功能可以有多种多样的实现方式，但每一个实现方式的关注点都不一样。有关注性能的、有关注扩展性的、有关注安全性的，不一而足，只有带着风险去考虑和筛选，才能在茫茫技术海洋中捕捉到我们所需要的。

剖析候选技术

  带着问题，我们可以在茫茫的技术社区中寻找我们需要的技术了。这里指的技术是一个很广泛的概念，比如架构模式、框架、组件、类库等等。只要我们不打算自己造轮子，那么总有机会需要面临选择的问题。因为解决同样的问题，无论是开源社区还是COTS，都有各种各样不同的解决方案。这些形形色色的解决方案，初看都是可以解决我们手头上的问题的，但是细细地分析，他们又有可能各不相同。
  比如现在在前端领域非常流行的MVVM框架，社区里有着各色各样的框架。有名门出身的reactjs、angularjs等；也有由牛人主导的民间框架，比如backbonejs、vue.js等。但框架的设计重点却各有不同。angularjs以controller和model为核心，强化了数据双向绑定的功能，因此有复杂交互或者复杂表单的情景，angularjs有天生的优势。但由于angularjs的性能一般，在性能敏感的系统中需要谨慎使用。另外angularjs的模版语法是嵌入到页面的HTML里的，这对于跟后台MVC框架的模版引擎集成，或更换前端框架都带来的极大的不方便。
  与angularjs同样是MVVM框架的reactjs则是走另外一种的设计思路。reactjs主要以View为核心，无论是组件化还是自创的JSX都是为方便模块化view层而设计的。如果系统需要有复杂的界面展现，reactjs能实现更为方便维护的前端代码。同时reactjs的模版引擎代码不会嵌入到页面的HTML中，对于与后台模版引擎集成和更换前端模版引擎都有莫大的好处。由于reactjs没有专门的controller层控制逻辑，对应业务逻辑代码的组织没有angularjs清晰，而且没有数据的双向绑定，view的状态需要开发人员自己维护和出发变更，但这也带来了一个好处：reactjs的性能比angularjs的性能好。
  从上面我们对比两个不同的MVVM框架可以看到，在分析技术之前，首先要对技术有一个宏观的了解，比如MVVM框架包含了View、Model、Controller等模块。然后就可以开始通过不用维度分析目标技术了，比如性能、扩展性、与其他技术集成、升级的难易程度、bug fix的及时程度等等。我们未必需要360度无死角的分析一个技术的每一个特性，只要我们之前已经分析过了系统的需求和风险，有针对性地重点分析我们关系的维度，就可以了。

选择最合适的，而不是最“好”的

  这个论述几乎已经是老生常谈了，每一个有经验的工程师都会强调这个。但很多出入职场的工程师，包括一年前的我，都会压抑不住自己的满腔热情，看到有新的技术，并且刚好可以满足项目的需求，便跃跃欲试。可是坑往往是在上文提到的风险中。新的技术往往可能有bug；也由于新的技术不成熟，后续版本很可能会推翻旧版本的很多设计，导致向下兼容很不友好，导致已有系统的升级困难重重。但是可以不升级吗？新的bug只在新版本中修复，官方不维护旧版本怎么办？
  当然，旧版本就一定好吗？新项目还用java 1.4的话，我还是觉得这样太作了。冷静地分析项目的需求和风险，冷静地分析技术的优点和缺点，冷静地把项目的特点和技术的特定匹配起来，这需要经验的辅助，方法论只能提供一个寻找道路的方法，但至于找到的路如何就真的看各人修为了。
  但是保持对新技术的热情是每个工程师必需的。因此我非常建议每个开发人员都在github上发布自己的代码。在这里我们可以尽情使用自己喜欢的技术，尽情学习各种各样的新技术，尽情开展各种各样的实验，发泄自己对技术的热情，也只有这里可以不需要考虑各种风险，哪怕代码错漏百出也不会有人干涉。