軟件開發(fā)領(lǐng)域那些經(jīng)典的技術(shù)之爭.doc

開發(fā)技術(shù)之爭第一位：PHP對Node.js作為一款從未受到計算機科學(xué)家青睞的語言，PHP受到想為自身網(wǎng)站增添一點智能元素的開發(fā)人員的熱烈追捧。這些包含激情的技術(shù)人員為我們帶來了眾多令人贊賞的框架，例如WordPress、Drupal以及Joomla等等。時至今日，大多數(shù)Web內(nèi)容都由PHP所構(gòu)建?，F(xiàn)在這套已經(jīng)相當(dāng)成熟的模式面臨著新的挑戰(zhàn)者。剛剛?cè)腴T的新人們更推崇Node.js，這是一套基于JavaScript的服務(wù)器端編程機制。幾乎在一夜之間，程序員們已經(jīng)可以編寫出有能力運行在客戶端或者服務(wù)器端的代碼，而且根本不需要額外再學(xué)習(xí)一門新語言。Node.js擁有自己的獨特風(fēng)格，但眾多出色的現(xiàn)有框架已經(jīng)能夠使其獲得可與各類最佳PHP堆棧相比肩的功能特性。下一代開發(fā)人員是否會出于編寫便捷性考量而選擇且只選擇JavaScript?又或者，他們會繼續(xù)堅持使用更易于嵌入至HTML當(dāng)中的編碼方式?很明顯，原本喜愛JavaScript的開發(fā)人員會毫不猶豫地投身于Node懷抱，而希望使用WordPress或者Drupal等源自PHP的穩(wěn)定堆棧的從業(yè)者則將與這場Node.js普及風(fēng)暴謹(jǐn)慎地保持距離。開發(fā)技術(shù)之爭第二位: MySQL對PostgreSQL在過去近二十年當(dāng)中，這兩款堪稱偉大的開源數(shù)據(jù)庫方案一直在爭斗不休、而且時至今日我們也看不到雙方握手言和的可能性。在一方面，MySQL在Web基礎(chǔ)工作負(fù)載領(lǐng)域擁有無可匹敵的巨大份額占比，這要歸功于其簡便易行的安裝與配置機制。而在另一方面，PostgreSQL長久以來則始終承諾提供更理想的事務(wù)處理機制、從而保護數(shù)據(jù)免受潛在漏洞的威脅。這兩位重量級選手都在向?qū)Ψ綄W(xué)習(xí)優(yōu)勢與長處，現(xiàn)在MySQL已經(jīng)擁有更出色的事務(wù)處理功能、而PostgreSQL也對自身的初次啟動流程進(jìn)行了大刀闊斧的精簡。不過歷史的慣性仍然推動著二者在當(dāng)下保持著對立關(guān)系。PostgreSQL通常被視為更具“穩(wěn)定性”的解決方案，而MySQL的長處則在于“快捷性”。不過平心而論，這兩種差異如今更多地反映在固有印象而非實際表現(xiàn)層面。所謂積重難返，這兩套軟件包可能還將在未來二十年中繼續(xù)這種激烈的對抗，而杰出的技術(shù)大牛與甲骨文反對者們的鼎力支持似乎讓PostgreSQL擁有更為順?biāo)斓陌l(fā)展前景。開發(fā)技術(shù)之爭第三位：Objective-C對Swift蘋果長久以來一直將Objective-C這款C語言精簡化版本且具備面向?qū)ο缶幊痰拈_發(fā)方案作為獨苗而呵護有加。然而時過境遷，現(xiàn)在Swift已經(jīng)閃亮登場并為開發(fā)人員帶來更具現(xiàn)代特色的語法體系，允許大家在擺脫大量規(guī)范束縛的前提下更輕松地為蘋果的移動平臺創(chuàng)建代碼。誠然，從C語言起步學(xué)習(xí)開發(fā)技術(shù)的從業(yè)者們并不介意面對一大堆未分類文件，但從Python、Ruby甚至是Java領(lǐng)域轉(zhuǎn)向iOS平臺的新手們紛紛表示這種機制簡直反人類。那么Swift的簡潔化架構(gòu)能否牢牢抓住蘋果開發(fā)人員的心呢?Python與Ruby開發(fā)人員又是否會大量涌向iOS環(huán)境，并給傳統(tǒng)Objective-C開發(fā)人員造成沖擊甚至是排擠壓力呢?又或者，久經(jīng)考驗的Objective-C程序員也許能憑借著自身驚人的開發(fā)效率繼續(xù)在新形勢下保持統(tǒng)治地位?新的代碼庫及各類功能特性會通過Swift還是Objective-C加以創(chuàng)建?蘋果公司已經(jīng)公開表示，兩款編程語言完全可以共存，所以開發(fā)人員無論如何選擇、都能找到屬于自己的立足空間。那些喜愛Python或者Java的從業(yè)者將投向Swift的懷抱，而以C語言為起點的老鳥們則不妨繼續(xù)堅持自己的Objective-C之路。開發(fā)技術(shù)之爭第四位: Python對Ruby很久很久以前，有一款腳本語言堪稱軟件領(lǐng)域的萬能膠。如果大家需要將多個大型項目接駁在一起，那么只需要在操作系統(tǒng)當(dāng)中簡單編寫一些代碼、任務(wù)就能得到順利完成。以此為起點，喜愛這些小型語言的開發(fā)者們開始拓展其規(guī)模、旨在進(jìn)一步發(fā)揮其已經(jīng)得到證明的出色效果。Ruby在與Rails框架牽手之后爆發(fā)出了強大的能量二者的結(jié)合體讓開發(fā)人員能夠以短短幾行代碼即將復(fù)雜的前端與數(shù)據(jù)庫對接起來。與此同時，Python也找到了自己的粉絲團體計算機科學(xué)家。如今它已經(jīng)在世界各地的科學(xué)實驗室中成為當(dāng)之無愧的天王巨星。而隨著統(tǒng)計分析技術(shù)在全球各大企業(yè)當(dāng)中不斷涌現(xiàn)，作為領(lǐng)頭羊的Python在數(shù)據(jù)科學(xué)實驗室的強力推動之下、順利在業(yè)務(wù)環(huán)境中找到了施展的平臺。那么新生代的開發(fā)人員是否會由于Python框架那允許使用空格的簡便特性而投身其中?Ruby又能否超越Rails，在發(fā)展道路上更進(jìn)一步?Python的內(nèi)置功能是否會使其成為凌駕于Ruby之上的理想選擇?相比之下，與科學(xué)家和與Web技術(shù)牛人為伍，哪邊更酷、更具吸引力?也許這條戰(zhàn)線還將延續(xù)下去甚至永無休止，其中Web大師們會繼續(xù)堅持自己的Rails道路、而科學(xué)家則安然隱居在Python庫所構(gòu)建起的象牙塔中。開發(fā)技術(shù)之爭第五位: SQL對NoSQL審視本輪比試的兩位選手，大家會發(fā)現(xiàn)其中之一居然是我們祖父輩的技術(shù)人就在使用的解決方案。數(shù)據(jù)能夠很好地填充到表當(dāng)中，而數(shù)據(jù)庫則通過執(zhí)行外部查詢操作將其匹配到對應(yīng)的表以及正確的行。在另一方面，NoSQL顯然代表著一股新生勢力，它承諾在速度與并行效率上帶來飛躍性提升。不過它也有自己的缺陷有時候表現(xiàn)會比較糟糕，數(shù)據(jù)庫將返回錯誤或者前后不一的查詢結(jié)果。經(jīng)驗豐富、久經(jīng)考驗的傳統(tǒng)數(shù)據(jù)庫方案能夠運用其多年沉淀而成的事務(wù)處理機制為我們的數(shù)據(jù)提供理想保護?又或者，大家更傾向于選擇一款速度更快、成本更低廉且更具現(xiàn)代特性的工具，從而將工作負(fù)載高效地傳播到整套設(shè)備集群中去?當(dāng)然，一致性與準(zhǔn)確性也同樣值得關(guān)注，但這些對于一份來自互聯(lián)網(wǎng)的、內(nèi)容完全隨機的數(shù)據(jù)表而言明顯毫無意義。我們有必要對一切信息都像數(shù)據(jù)科學(xué)家那樣加以嚴(yán)格保護嗎?答案(通常)是：只有銀行或者航空公司等對一致性要求極高的企業(yè)才需要利用傳統(tǒng)SQL數(shù)據(jù)庫來保障真實事務(wù)處理的可靠性。除此之外，其它用戶不妨選擇速度更快、使用更便捷且更具可擴展性的NoSQL方案。開發(fā)技術(shù)之爭第六位: JavaScript對 Dart與Go (或者說是對抗谷歌本身)JavaScript也許在谷歌公司內(nèi)部也擁有一部分堅定的支持者，但從技術(shù)巨頭無休止地打造自有方案來看、我們絲毫體會不到其對于JavaScript的高度肯定與依賴。最初，谷歌拿出了GWT(即Google Web Toolkit)，這是一款頗具智能特性的跨界式編譯器，能夠?qū)ava代碼轉(zhuǎn)換為JavaScript。如果大家查看過Gmail或者其它谷歌產(chǎn)品的代碼堆棧，就會發(fā)現(xiàn)其并非利用JavaScript進(jìn)行手工編寫。接下來，谷歌公司又創(chuàng)造出了Dart與Go兩款編程語言，它們的誕生意義很明確有朝一日在瀏覽器環(huán)境下徹底取代JavaScript。Dart與Go二者都擁有正確的發(fā)展思路與存在價值。它們的作用在于修復(fù)JavaScript以及瀏覽器堆棧當(dāng)中所固有的突出問題，但很多人對此表示并不在乎。JavaScript在服務(wù)器端已經(jīng)獲得了爆炸式的份額增長，而這完全要歸功于Node.js。好了，這就是開發(fā)人員關(guān)注的一切其它的，管它呢。即使傾盡所有力量，谷歌也仍然面臨著一場非常艱難的苦戰(zhàn)。規(guī)模龐大的程序員群體很久以前就開始學(xué)習(xí)JavaScript，如今也有意愿利用這款語言對自己的服務(wù)器堆棧進(jìn)行重寫。要與人的習(xí)慣思維對抗真的非常困難，但或許早期采納者們的贊揚之聲以及Dart與Go那清晰的語法和簡潔的模型真能讓這兩位后起之秀在群眾中得到一定程度的關(guān)注至少不會徹底被人們所忽視。開發(fā)技術(shù)之爭第七位: Chef對Puppet很久以前，一家企業(yè)只需要在機房里部署幾臺服務(wù)器、并為其安裝新軟件即可，多么輕松、多么簡便。然而云計算隨后席卷而來，每一家網(wǎng)站無論有無必要都被迫運行規(guī)模龐大的設(shè)備集群，并為之配備更為強勁的維護團隊。這意味著要在N臺設(shè)備上重復(fù)N次同樣的操作，但又不能出現(xiàn)任何誤差或者紕漏。Chef與Puppet是兩款已經(jīng)擁有極高人氣的工具，旨在幫助管理員們以統(tǒng)一化方式對大量云設(shè)備進(jìn)行配置。DevOps專家們對于Chef作為一款配置管理工具的卓越靈活性贊不絕口，它允許大家利用Ruby編寫指令并實現(xiàn)設(shè)備創(chuàng)建?！按蠹铱梢暂p松發(fā)揮Ruby的全部功能，”他們感嘆道。Puppet的作用同樣在于集群配置，但卻專門使用一種類似于JSON的語言、希望能集中辦好一類工作。盡管Puppet的新型版本也開始部分引入Ruby，但其基礎(chǔ)語言仍然占據(jù)著統(tǒng)治地位?，F(xiàn)在問題就在大家面前：到底是為任務(wù)創(chuàng)建一套定制化語法好呢，還是將一款受眾廣泛、用途多樣的編程語言的一切能力(但也包括危險)直接塞給用戶好?開發(fā)技術(shù)之爭第八位: Hudson對Jenkins持續(xù)集成的核心思路在于以自動化方式對提供到資源庫內(nèi)的所有新代碼進(jìn)行測試與部署。而在這類方案收到良好效果之后，人們就開始對這筆寶貴的遺產(chǎn)加以爭奪。此輪對抗的一方是Hudson，屬于Eclipse基金會的官方分支項目，且由眾多原本效力于Sun、后因收購而轉(zhuǎn)投甲骨文旗下的技術(shù)人員負(fù)責(zé)運作。他們擁有一流企業(yè)所特有的審慎態(tài)度，構(gòu)建出了一套穩(wěn)定且值得信賴的企業(yè)級工具。另一方則是Jenkins，眾多技術(shù)人員最喜愛的實驗性環(huán)境。Jenkins的發(fā)展節(jié)奏與前者相比要快得多，其幾乎每個禮拜都會推出新版本。這場Hudson與Jenkins之間的對抗象征著開發(fā)人員領(lǐng)域即將爆發(fā)的一場規(guī)模更大的爭斗：一方是堅持對提交代碼進(jìn)行嚴(yán)格測試、重視穩(wěn)定性的保守派，另一方則是重視快速開發(fā)、快速修復(fù)，希望能從規(guī)?；_發(fā)者社區(qū)獲取更龐大代碼貢獻(xiàn)數(shù)量的激進(jìn)派。開發(fā)技術(shù)之爭第九位: MySQL對MariaDB說起甲骨文所支持項目面臨的選擇難題，我們就不能不提到MariaDB與MySQL之間的恩怨情仇。當(dāng)初甲骨文買下MySQL時，開源擁護者們擔(dān)心這位以獨斷專行著稱的紅色巨人會打造出一款強大但專有的工具。盡管他們的擔(dān)心在很大程度上并沒有什么實質(zhì)性依據(jù)，但這并沒有阻止Monty WideniusMySQL項目的創(chuàng)始人之一從頭開始建立自己的fork版本。MariaDB所提供的語法與功能與MySQL幾乎如出一轍，但現(xiàn)在它已經(jīng)擁有眾多新特性與存儲引擎，能夠帶來更理想的運行速度至少在MariaDb的支持者們看來是如此。那么市場會選擇斗志旺盛、充滿活力的MariaDB，還是堅持規(guī)模龐大且多年以來一直占據(jù)主導(dǎo)地位的MySQL?全世界的開發(fā)人員會選擇規(guī)模較小但創(chuàng)新能力極強的新生力量，還是穩(wěn)固可靠的企業(yè)集團?開發(fā)技術(shù)之爭第十位: 編譯對腳本編譯化與腳本化之間的區(qū)別并不像當(dāng)初的即時編譯器與優(yōu)化器之間的差異那樣明顯，但這種不同在程序員們看來仍然非常重要。他們希望自己的代碼被剖析、調(diào)整、優(yōu)化并翻譯成更為簡單的機器碼?還是更希望以相對輕松的方式讓計算機在運行時中進(jìn)行代碼解釋僅僅偶爾允許代碼對自身進(jìn)行修改?一方面的代表性角色有C以及