軟體開發領域的10場有意思的對抗

edithfang發表於2015-04-11
這個世界是辯證統一的,正如太極所表現的那樣,共存的陰陽兩極既有對抗,又有融合。在現實生活中,共存事物間的對抗也是無處不在。比如,同為冷兵器的矛與盾之間的對抗,是最鋒利的矛厲害還是最堅固的盾厲害?同為佳餚的魚與熊掌之間的對抗,魚和熊掌不可兼得,是代表海味的魚好還是代表山珍的熊掌好?

同樣的,在軟體開發領域,這樣的對抗依然在上演。

開發技術的戰場之一:PHP vs.Node.js

PHP 絲毫不受電腦科學家的待見,卻深受那些只想用一丁點腦力就能完成 Web 開發的大眾群體所喜愛。這群人帶來了令人驚歎的框架,如 WordPress、Drupal、Joomla 等等。大部分的網站都是基於 PHP 技術所建立的。

現在,大夥們在技術的選擇上出現了分歧。年輕一代的人開始迷戀 Node.js 技術了,這是一種由 JavaScript 編寫的伺服器端機制。JavaScript 的出現,使程式設計師們發現自己寫的程式碼既能執行在客戶端也能執行在伺服器端,自己再也不用學兩種不同的語言了。Node.js 擁有自己的特點,但是它所提供的那些功能與最好的 PHP 堆疊所提供的其實基本一致。

下一代程式設計師會接受只用 JavaScript 來簡單編寫的新技術麼?或者他們會依靠 HTML 使程式碼更易於嵌入?那些喜歡 JavaScript 的人幾乎肯定都會選擇 Node,而那些使用 PHP 穩定堆疊如 WordPress 或 Drupal 來處理重活的人則會抵制 Node.js 風暴所帶來的影響。

開發技術的戰場之二:MySQL vs.PostgreSQL

兩大開放原始碼資料庫無休止的戰鬥已經持續了快 20 年了。一方面,MySQL 因其易於安裝和配置的特性在 Web 的基礎工作中已經佔據了大部分份額。另一方面,PostgreSQL 擁有在故障中保護資料的更好機制。現在,兩者都在迅速改善自己不足之處,MySQL 提供了改進的事務處理功能,而 PostgreSQL 簡化了自身的啟動流程。

兩者在很久以前存在著的差異性仍然在影響著今天的戰線,PostgreSQL 被認為更“可靠”而 MySQL 則被認為是更“快速”。這是一種先入為主的思想,正如當今的時髦黑客和討厭 Oracle 的人常會選擇 PostgreSQL 那樣,這兩個競爭對手可能還需要另一個 20 年才能改變這種思想在使用者中的影響。

開發技術的戰場之三:Swift vs.Objective-C

蘋果這些年只用 Objective-C 來為其進行定製開發,這是一門乾淨,混合了C語言的物件導向的程式語言。但是,現在時代變了,Swift 提供了一套現代化的語法免除了在蘋果平臺構建程式碼的程式設計師的許多煩惱。當然,那些從小就學習了C語言的人並不介意複雜語法與多檔案,但是那些由 Python、Ruby 甚至是 Java 入門的人卻對此抱怨頗深。

Swift 的整潔結構會抓住蘋果開發者的心麼?Python 和 Ruby 的開發者會湧向 iOS 開發領域並擠掉那些保守的 Objective-C 程式設計師的生存空間麼? 或者這個世界會被那些 Objective-C 程式設計師的可靠驚人效率所征服?蘋果曾公開表示這兩門語言能夠共存,那麼新的庫和特性是用 Swift 還是 Objective-C 來編寫?開發者們將會通過熟悉的語言來分成不同的叢集,那些喜歡 Python 或者 Java 的將會轉到 Swift,而從小與C一起長大的將會堅持使用 Objective-C。

開發技術的戰場之四:Python vs.Ruby

很久以前,對於軟體來說指令碼語言就像萬能膠。如果你需要把大專案粘合在一起,你可以在作業系統中編寫簡單的指令碼程式碼就可以完成。

在這個過程中的某個時候,那些喜歡擺弄這些小巧語言的人們發現用它們構建大型程式也是非常有用的。當 Ruby 與 Rails 框架聯姻之後,這個組合瞬間火爆了——它們把一個複雜的資料庫前端簡化得只有少量幾段程式碼了。

與此同時,Python 在科學領域建立了它的粉絲俱樂部。它被廣泛運用於每個地方的實驗室,伴隨著統計學理論在企業界各個角落的破殼而出,尖端的 Python 被認為是獲得商業領域資料科學實驗的動力。

下一代的程式設計師會被使用空格進行程式碼設計的 Python 的簡潔所吸引麼?Ruby 的擴張速度會超過 Rails 麼?Python 的內建函式比 Ruby 的“塊”更好?與那些科學家或者 Web 黑客站在同一陣線看起來是否更酷?或許是積習難改,那些網站的站長現在仍然堅持使用 Rails,而科學家們則只對 Python 的庫情有獨鍾。

開發技術的戰場之五:SQL vs.NoSQL

道路的一側是你的先輩們過去就曾使用的資料庫——資料很好的融入表格之中,資料庫執行外部查詢來與表格進行匹配並找到正確的行數。道路的另一側是突然崛起的 NoSQL,它注重速度與並行性,當事情可能變得更糟糕的時候它會每隔一段時間發出一些小的警告,資料庫將會從錯誤中回退並重新作出不同的操作。

使用傳統事務保護機制的傳統資料庫“腰帶+吊帶”式的處理方法是你的資料所需要的東西?或者你需要一個在計算機叢集中能夠有效的將負載進行均衡擴散的更快更便宜更時髦的工具?穩定性與準確性對銀行業來說固然很重要的,但那些來自網路上喋喋不休的廢話它也需要麼?是否所有行業都需要得到資料科學家那種層次的保護?這些問題通常的答案會是:那些需要絕對穩定性的行業如銀行業和航空業在處理事務時應當使用傳統的 SQL 資料庫,而其它那些無此特定需求的行業可以選擇使用快速、簡單、可擴充套件的 NoSQL。

開發技術的戰場之六:JavaScript vs.Dart 和 Go (或者說與谷歌本身的對抗)

在谷歌這個地方 JavaScript 也有自己的粉絲,但是你可能還不知道它還常被其它語言不斷替代實現。最早的時候,谷歌推出了 GWT (Google Web Toolkit),這是一種聰明的跨平臺編譯器,能夠把 Java 轉化成 JavaScript。但是,如果你曾經看到過 Gmail 或者谷歌其它產品的程式碼堆疊,你會發現它們並不完全是用 JavaScript 實現的。在稍晚的時候,谷歌創造了 Dart 和 Go。這是兩種可能在未來某天在瀏覽器上完全取代 JavaScript 的語言。

Dart 和 Go 在各自領域都有其獨特的用處。它們修復了使用 JavaScript 和瀏覽器堆疊的一些主要突出但是卻不被許多人在意的問題。而由於 Node.js 的原因,JavaScript 在伺服器端異常火爆,人們已經不再需要其它東西了。

為了掌握絕對的權力,谷歌將面臨著一場與大批曾經學習了 JavaScript 而現在想要用它重寫伺服器堆疊的程式設計師大軍之間的艱苦鬥爭。要戰勝習慣是非常困難的,但是那些從早期就深刻體會到 Dart 和 Go 乾淨語法和簡化模型的最佳體驗者所發出的讚美將會成為大眾不可忽略的聲音。

開發技術的戰場之七:Chef vs.Puppet

很久以前,公司在後臺擁有很少的伺服器,並且安裝新的軟體都非常簡單。後來,隨著雲技術的興起,為了保持網站的持續運轉,需要將所有有價值的東西放在叢集裝置上。這就意味著做N件事情就會訪問N個裝置,彼此之間不會產生干擾。Chef 和 Puppet 是為了幫助管理員像流水線一樣配置雲裝置而出現的兩個工具。

開發運營專家專注於 Chef,這個配置管理工具擁有一流的靈活性——能夠讓你用 Ruby 來編寫建立裝置的指令。他們說:“你能夠無償的獲得 Ruby 的力量。”Puppet 也被用於叢集的配置, 但是用於指定做某事的指令是由類似於 JSON 一樣的語言發出的。雖然 Puppet 的幾個新版本支援一點 Ruby 了,但是基礎語言仍然佔據著統治地位。那麼,到底是為工作建立自定義語法更好呢還是給予人們完全開放、用途廣泛的語言的權力(或者危險)更好?

開發技術的戰場之八:Hudson vs.Jenkins

持續性整合是一個通過自動測試將所有全新程式碼部署到儲存庫中的想法。當這個想法獲得很大成功之後,人們開始爭奪它所帶來的利益。

戰場的一邊是 Hudson,它是 Eclipse 基金會正式專案的一部分,是由收購了 Sun 公司的 Oracle 所管理的那個分支。他們用一流的企業態度來構建企業需求使用的穩定、嚴肅的工具。而另一邊是 Jenkins,它是原 Hudson 的另外一個分支,現在它是那些眾多從很早就開始玩技術的黑客的家。Jenkins 這顆大樹成長非常迅速,它的最新版本基本每個星期就會發布一次。

Hudson 和 Jenkins 的戰場可以看作是開發者世界裡更大規模戰場的象徵,是堅定奉行謹慎測試、穩固程式碼的面向企業理念與更快發展、更快 Bug 修復、面向更多使用者群體理念之間的對抗。

開發技術的戰場之九:MySQL vs.MariaDB

說到由於 Oracle 收購所引發的戰鬥,我們不能不提到 MariaDB 與 MySQL 之間的分裂。

當 Oracle 買下了 MySQL 後,開源的支持者們開始擔心這個強大的工具會成為 Oracle 公司私有的賺錢手段。他們的擔心是多餘的,但這並不能阻止 MySQL 創始人之一 Monty Widenius 另起灶臺。在 MariaDB 擁護者眼裡,MariaDB 除了擁有與 MySQL 同樣的語法和功能,還包含了一些全新特性,甚至儲存引擎執行速度更快一些。

未來的市場將會選擇充滿活力的新事物還是堅持選擇龐大並在這些年裡佔據著主導地位的資料庫?這個世界會鍾情於矮小且衣衫襤褸的創新者還是龐大穩定而可靠的成功者?我們將拭目以待。

開發技術的戰場之十:編譯語言 vs. 指令碼程式碼

在即時編譯器和優化器面前,編譯語言和指令碼程式碼之間的區別並不明顯,但是這點對程式設計師們來說仍然很重要。一種是程式碼邏輯性更強,需要反覆揣摩,優化,更接近於底層機器邏輯處理的語言;另一種是開發更加直觀容易,甚至可讓計算機在程式碼在執行時修改自身程式碼的語言。

前者的代表都是一些傳統的語言,如C和 Java,它們都擁有精心設計的開發套件。而後者的代表都是一些結構簡單的語言,如 Python、Ruby 和 JavaScript,它們能夠在文字編輯器中建立並可隨時放入小型執行環境中進行解譯。對於解決更加複雜的問題,它們擁有混合的解決方案,如 Groovy,這是一種指令碼編譯混合類語言,它能夠執行在 Java 虛擬機器上,而它自身是一個能夠進行大量實時優化的工具。編譯語言與指令碼語言的區別正在慢慢模糊,但是這仍然阻止不了人們對於複雜的編譯程式工作是否真的值得去做的爭論。

英文原文:10 battles raging for the hearts and minds of developers 
相關閱讀
評論(1)

相關文章