【IT168 技术】无论大家是否认同二元论在人类思维与社会形成当中所扮演的重要角色以及基础性地位，这种“非黑即白”的审视角度已经成为我们日常生活当中组织定义的重要手段之一：共产主义与资本主义、咸党与甜党、足球运动中的转球与带球。环视我们身边，每一种事物似乎都被锁定在一场与其对立面的永恒对抗当中，而这也让我们能够随时随地对自己的的喜好或者选择进行分析以及决断。

　　这种思维方式在计算机技术领域的作用则更为明显——二者选其一，众多各有所长的方案在努力争夺我们的感性支持、理性支持以及口袋里的钞票——这些技术成果往往牢牢坚守着自己的差异化设计思路，进而导致用户很难从中找到万全的决策结论。如果一边标榜自身是X，那么另一边则常常会以“非X”自居并将此作为核心卖点。双方阵营的拥护者开始纷纷站队，并向对立阵营的成员们大加嘲讽或者拉拢。如果没有这些争斗、没有由此带来的激烈辩论与两难选择，两套方案可能早就已经合而为一、并成为用户没有选择中的最好选择。然而缺少了这种多样性，创新活动将受到严重束缚、我们的世界也不可能如此丰富多彩。

　　在今天的文章中，我们将了解开发人员们最感兴趣的十大二选一难题。每当一个新项目火热出炉，我们都需要面对隐藏在其差异化技术实施机制之下的本质性问题。我们到底更倾向于简便还是正确?更喜爱开源体系还是商业支持?成熟框架还是空白但无拘无束?正如阴阳对立但又彼此依存，相信对这些问题的探讨能够帮助企业开发人员在面临取舍难题时作出更为明智的判断。

　　开发技术之争第一位：PHP对Node.js

　　作为一款从未受到计算机科学家青睐的语言，PHP受到想为自身网站增添一点智能元素的开发人员的热烈追捧。这些包含激情的技术人员为我们带来了众多令人赞赏的框架，例如WordPress、Drupal以及Joomla等等。时至今日，大多数Web内容都由PHP所构建。

　　现在这套已经相当成熟的模式面临着新的挑战者。刚刚入门的新人们更推崇Node.js，这是一套基于JavaScript的服务器端编程机制。几乎在一夜之间，程序员们已经可以编写出有能力运行在客户端或者服务器端的代码，而且根本不需要额外再学习一门新语言。

　　Node.js拥有自己的独特风格，但众多出色的现有框架已经能够使其获得可与各类非常好的PHP堆栈相比肩的功能特性。下一代开发人员是否会出于编写便捷性考量而选择且只选择JavaScript?又或者，他们会继续坚持使用更易于嵌入至HTML当中的编码方式?很明显，原本喜爱JavaScript的开发人员会毫不犹豫地投身于Node怀抱，而希望使用WordPress或者Drupal等源自PHP的稳定堆栈的从业者则将与这场Node.js普及风暴谨慎地保持距离。

　　开发技术之争第二位: MySQL对PostgreSQL

　　在过去近二十年当中，这两款堪称伟大的开源数据库方案一直在争斗不休、而且时至今日我们也看不到双方握手言和的可能性。在一方面，MySQL在Web基础工作负载领域拥有无可匹敌的巨大份额占比，这要归功于其简便易行的安装与配置机制。而在另一方面，PostgreSQL长久以来则始终承诺提供更理想的事务处理机制、从而保护数据免受潜在漏洞的威胁。这两位重量级选手都在向对方学习优势与长处，现在MySQL已经拥有更出色的事务处理功能、而PostgreSQL也对自身的初次启动流程进行了大刀阔斧的精简。

　　不过历史的惯性仍然推动着二者在当下保持着对立关系。PostgreSQL通常被视为更具“稳定性”的解决方案，而MySQL的长处则在于“快捷性”。不过平心而论，这两种差异如今更多地反映在固有印象而非实际表现层面。所谓积重难返，这两套软件包可能还将在未来二十年中继续这种激烈的对抗，而杰出的技术大牛与甲骨文反对者们的鼎力支持似乎让PostgreSQL拥有更为顺遂的发展前景。

　　开发技术之争第三位：Objective-C对Swift

　　苹果长久以来一直将Objective-C这款C语言精简化版本且具备面向对象编程的开发方案作为独苗而呵护有加。然而时过境迁，现在Swift已经闪亮登场并为开发人员带来更具现代特色的语法体系，允许大家在摆脱大量规范束缚的前提下更轻松地为苹果的移动平台创建代码。诚然，从C语言起步学习开发技术的从业者们并不介意面对一大堆未分类文件，但从Python、Ruby甚至是Java领域转向iOS平台的新手们纷纷表示这种机制简直反人类。

　　那么Swift的简洁化架构能否牢牢抓住苹果开发人员的心呢?Python与Ruby开发人员又是否会大量涌向iOS环境，并给传统Objective-C开发人员造成冲击甚至是排挤压力呢?又或者，久经考验的Objective-C程序员也许能凭借着自身惊人的开发效率继续在新形势下保持统治地位?新的代码库及各类功能特性会通过Swift还是Objective-C加以创建?苹果公司已经公开表示，两款编程语言完全可以共存，所以开发人员无论如何选择、都能找到属于自己的立足空间。那些喜爱Python或者Java的从业者将投向Swift的怀抱，而以C语言为起点的老鸟们则不妨继续坚持自己的Objective-C之路。

　　开发技术之争第四位: Python对Ruby

　　很久很久以前，有一款脚本语言堪称软件领域的功能较多胶。如果大家需要将多个大型项目接驳在一起，那么只需要在操作系统当中简单编写一些代码、任务就能得到顺利完成。

　　以此为起点，喜爱这些小型语言的开发者们开始拓展其规模、旨在进一步发挥其已经得到证明的出色效果。Ruby在与Rails框架牵手之后爆发出了强大的能量——二者的结合体让开发人员能够以短短几行代码即将复杂的前端与数据库对接起来。

　　与此同时，Python也找到了自己的粉丝团体——计算机科学家。如今它已经在世界各地的科学实验室中成为当之无愧的天王巨星。而随着统计分析技术在全球各大企业当中不断涌现，作为领头羊的Python在数据科学实验室的强力推动之下、顺利在业务环境中找到了施展的平台。

　　那么新生代的开发人员是否会由于Python框架那允许使用空格的简便特性而投身其中?Ruby又能否超越Rails，在发展道路上更进一步?Python的内置功能是否会使其成为凌驾于Ruby之上的理想选择?相比之下，与科学家和与Web技术牛人为伍，哪边更酷、更具吸引力?也许这条战线还将延续下去甚至永无休止，其中Web大师们会继续坚持自己的Rails道路、而科学家则安然隐居在Python库所构建起的象牙塔中。

　　开发技术之争第五位: SQL对NoSQL

　　审视本轮比试的两位选手，大家会发现其中之一居然是我们祖父辈的技术人就在使用的解决方案。数据能够很好地填充到表当中，而数据库则通过执行外部查询操作将其匹配到对应的表以及正确的行。在另一方面，NoSQL显然代表着一股新生势力，它承诺在速度与并行效率上带来飞跃性提升。不过它也有自己的缺陷——有时候表现会比较糟糕，数据库将返回错误或者前后不一的查询结果。

　　经验丰富、久经考验的传统数据库方案能够运用其多年沉淀而成的事务处理机制为我们的数据提供理想保护?又或者，大家更倾向于选择一款速度更快、成本更低廉且更具现代特性的工具，从而将工作负载高效地传播到整套设备集群中去?当然，一致性与准确性也同样值得关注，但这些对于一份来自互联网的、内容完全随机的数据表而言明显毫无意义。我们有必要对一切信息都像数据科学家那样加以严格保护吗?答案(通常)是：只有银行或者航空公司等对一致性要求极高的企业才需要利用传统SQL数据库来保障真实事务处理的可靠性。除此之外，其它用户不妨选择速度更快、使用更便捷且更具可扩展性的NoSQL方案。

　　开发技术之争第六位: JavaScript对 Dart与Go (或者说是对抗谷歌本身)

　　JavaScript也许在谷歌公司内部也拥有一部分坚定的支持者，但从技术巨头无休止地打造自有方案来看、我们丝毫体会不到其对于JavaScript的高度肯定与依赖。最初，谷歌拿出了GWT(即Google Web Toolkit)，这是一款颇具智能特性的跨界式编译器，能够将Java代码转换为JavaScript。如果大家查看过Gmail或者其它谷歌产品的代码堆栈，就会发现其并非利用JavaScript进行手工编写。接下来，谷歌公司又创造出了Dart与Go两款编程语言，它们的诞生意义很明确——有朝一日在浏览器环境下彻底取代JavaScript。

　　Dart与Go二者都拥有正确的发展思路与存在价值。它们的作用在于修复JavaScript以及浏览器堆栈当中所固有的突出问题，但很多人对此表示并不在乎。JavaScript在服务器端已经获得了爆炸式的份额增长，而这完全要归功于Node.js。好了，这就是开发人员关注的一切——其它的，管它呢。

　　即使倾尽所有力量，谷歌也仍然面临着一场非常艰难的苦战。规模庞大的程序员群体很久以前就开始学习JavaScript，如今也有意愿利用这款语言对自己的服务器堆栈进行重写。要与人的习惯思维对抗真的非常困难，但或许早期采纳者们的赞扬之声以及Dart与Go那清晰的语法和简洁的模型真能让这两位后起之秀在群众中得到一定程度的关注——至少不会彻底被人们所忽视。

　　开发技术之争第七位: Chef对Puppet

　　很久以前，一家企业只需要在机房里部署几台服务器、并为其安装新软件即可，多么轻松、多么简便。然而云计算随后席卷而来，每一家网站——无论有无必要——都被迫运行规模庞大的设备集群，并为之配备更为强劲的维护团队。这意味着要在N台设备上重复N次同样的操作，但又不能出现任何误差或者纰漏。Chef与Puppet是两款已经拥有极高人气的工具，旨在帮助管理员们以统一化方式对大量云设备进行配置。

　　DevOps专家们对于Chef作为一款配置管理工具的卓越灵活性赞不绝口，它允许大家利用Ruby编写指令并实现设备创建。“大家可以轻松发挥Ruby的全部功能，”他们感叹道。Puppet的作用同样在于集群配置，但却专门使用一种类似于JSON的语言、希望能集中办好一类工作。尽管Puppet的新型版本也开始部分引入Ruby，但其基础语言仍然占据着统治地位。现在问题就在大家面前：到底是为任务创建一套定制化语法好呢，还是将一款受众广泛、用途多样的编程语言的一切能力(但也包括危险)直接塞给用户好?

　　开发技术之争第八位: Hudson对Jenkins

　　持续集成的核心思路在于以自动化方式对提供到资源库内的所有新代码进行测试与部署。而在这类方案收到良好效果之后，人们就开始对这笔宝贵的遗产加以争夺。此轮对抗的一方是Hudson，属于Eclipse基金会的官方分支项目，且由众多原本效力于Sun、后因收购而转投甲骨文旗下的技术人员负责运作。他们拥有一流企业所特有的审慎态度，构建出了一套稳定且值得信赖的企业级工具。

　　另一方则是Jenkins，众多技术人员最喜爱的实验性环境。Jenkins的发展节奏与前者相比要快得多，其几乎每个礼拜都会推出新版本。

　　这场Hudson与Jenkins之间的对抗象征着开发人员领域即将爆发的一场规模更大的争斗：一方是坚持对提交代码进行严格测试、重视稳定性的保守派，另一方则是重视快速开发、快速修复，希望能从规模化开发者社区获取更庞大代码贡献数量的激进派。

　　开发技术之争第九位: MySQL对MariaDB

　　说起甲骨文所支持项目面临的选择难题，我们就不能不提到MariaDB与MySQL之间的恩怨情仇。

　　当初甲骨文买下MySQL时，开源拥护者们担心这位以独断专行著称的红色巨人会打造出一款强大但专有的工具。尽管他们的担心在很大程度上并没有什么实质性依据，但这并没有阻止Monty Widenius——MySQL项目的创始人之一——从头开始建立自己的fork版本。

　　MariaDB所提供的语法与功能与MySQL几乎如出一辙，但现在它已经拥有众多新特性与存储引擎，能够带来更理想的运行速度——至少在MariaDb的支持者们看来是如此。

　　那么市场会选择斗志旺盛、充满活力的MariaDB，还是坚持规模庞大且多年以来一直占据主导地位的MySQL?全世界的开发人员会选择规模较小但创新能力极强的新生力量，还是稳固可靠的企业集团?

　　开发技术之争第十位: 编译对脚本

　　编译化与脚本化之间的区别并不像当初的即时编译器与优化器之间的差异那样明显，但这种不同在程序员们看来仍然非常重要。他们希望自己的代码被剖析、调整、优化并翻译成更为简单的机器码?还是更希望以相对轻松的方式让计算机在运行时中进行代码解释——仅仅偶尔允许代码对自身进行修改?

　　一方面的代表性角色有C以及Java等经典语言，它们拥有精巧的开发套件作为支持。另一方面的代表性角色则是Python、Ruby以及JavaScript等精简化脚本语言，它们能够在文本编辑器内完成创建并立即被推送至小型运行时解释器当中。而令情况进一步复杂化的是，Groovy这类混合解决方案能够以脚本类语言的姿态运行在Java虚拟机当中，而且它本身就是一款能够对运行时进行高度优化的工具。也许二者之间的区别正在逐步弱化，但这并不能阻止人们就此作出争论、探讨编译器费尽心力完成的工作到底是否拥有实际价值。