nginx centos java Windows Android linux wordpress Ubuntu google 微软 开源 mysql shell Python 程序员 云计算 php apache Firefox 编程

【譯文】熱鬧驅動開發

軟件開發團隊關於軟件架構或技術棧的決策,很多並不是基於紮實的研究和對期望效果的認真思考,而是不準確的意見、社交媒體的信息,或者就些是“熱門”玩意。這種做派的危害我見過不少,稱它為“熱鬧驅動開發(Hype
 Driven Development,HDD)”。我贊成的是更專業的做法,稱之為“腳踏實地的軟件工程”。下面一起看看HDD的來龍去脈,想想我們能怎麽改進。


新技術帶來新希望

團隊把最新最熱的技術應用到項目裏,這樣的景象你見過嗎?有人是因為讀到了相關的博客,有人是看到Twitter上的潮流,還有人是剛剛在技術大會上聽到了關於某門技術的精彩演講。不久,團隊就開始采用這種亮眼的新技術(或者軟件架構設計範式),結果他們並不能更快(就像之前說的那樣)開發出更優秀的產品,反而身陷囹圄。開發的速度降下來了,信心受挫了,後續版本的交付也出問題了。有些團隊甚至幹脆專心修bug,而不是開發新功能。他們“只需要多花幾天”就能把事情搞定。


熱鬧驅動開發


熱鬧驅動開發有很多流派,也有很多渠道介入大家的項目:


Reddit驅動開發——在選擇技術、架構、設計時,團隊和個人的決策依據是知名博主的文章,或者reddit,
 hackernews, blogs, twitter, facebook, Github或者其它社交媒體上的熱點。


技術會議驅動開發——仔細觀察觀察,參會回來的家夥們有什麽表現。他們備受演講的鼓舞。這是雙刃劍。他們沒有足夠的研究,就開始使用最新最熱的類庫/框架/架構範式,而這可能是通往地獄的高速公路。


嗓門驅動開發——有人整天談論新框架/類庫/技術,他自己卻沒有經驗,但是反復念經終於讓團隊決定采納它。


Gem/類庫/插件驅動開發——在RoR社區裏特別流行這種情況,有時候我會發現一個gemfile太長,只有程序啟動時的裝載時間比它更長。這種流派源自下面的觀念:Rails裏的每個問題都應當有個gem來解決。有時候只要自己動手寫幾行代碼就能解決,但是我們還是一個勁地添加類庫/插件/gem/框架。


我還希望提到熱鬧驅動開發的一個常見流派,StackOverflow
 驅動開發——開發人員從StackOverflow(總之就是互聯網上)拷貝代碼,而沒有真正弄懂它們。


HDD就是開發團隊自掘墳墓


湊熱鬧的問題是:它很容易導致錯誤決策。無論是糟糕的架構決策,還是糟糕的技術棧決策,給團隊的影響都常常持續數月甚至數年。最糟的是它們會造成軟件工程上千瘡百孔的局面,只能推倒重來。但推倒重來幾乎沒有成功案例。


一切罪惡的根源似乎都是社交媒體——新觀點傳播得太快,還沒來得及經過檢驗。大家還來不及細想有哪些利弊,就已經傳播開去。


湊熱鬧的來龍去脈

大多數湊熱鬧的步驟是相同的,像下面這樣:

第一步:真實問題和解決方案


這些熱鬧源自於某些真的遇到了問題的公司。公司裏的團隊認為,現成的技術棧、流程、架構並不能解決這個問題,必須自己動手。所以公司研發了新的框架、類庫、範式,問題迅速解決了。


第二步:宣示、推廣、包裝關鍵詞


團隊熱衷於向他人展示自己的成果。很快他們就發布了博客,也去會議上演講。這些問題通常是有分量的,所以解決方案也是有分量的,結果也是很可觀的,團隊對此很自豪。其它人也開始為這項新技術而激動。唯一的問題是,並非所有激動的人都能徹底理解問題和解決方案的細節。畢竟,問題是有分量的,解決方案也是有分量的,所以不是一條推文、一次碎碎念、甚至是一篇博客就能講清楚的。利用博客文章、技術大會的主題演講之類的社交工具,原始信息就很容易產生偏差。


第三步:狂熱現身


HDD陰影下的開發人員都會閱讀博客、參加技術會議。然後世界各地的團隊都開始使用新技術了。因為信息眼睛走樣了,所以有些人會在框架問題上做草率的決定,即便框架沒有解決任何具體問題。但是,團隊仍然期望新的框架會帶來幫助。

第四步:心灰意冷


新鮮勁頭過去了,新技術並沒有給團隊帶來期望的改進,反而增加了很多額外的工作。大家得重寫很多代碼,花不少時間專門學習。工作的速度慢下來,管理者也沒耐心了。大家都感覺被騙了。


第五步:反省領悟


最終團隊做了復盤,認清了為新技術付出的代價,也認清了新技術適合解決的問題。大家都變聰明了,直到追逐下一次熱鬧為止。


HDD舉例


來看看幾個熱鬧驅動開發的例子,看看它是怎麽發生的。


舉例 1:React.js


Facebook遇到了一個問題,Facebook自己的復雜單頁面app裏,會出現各種狀態改變的事件,必須追蹤到發生了什麽,並且保持狀態的連貫一致。

Facebook用幾個時髦的詞包裝新範式:函數式、虛擬DOM,組件。

狂人說:Facebook創造了未來的前端框架。我們現在就把一切用react重寫吧。

等等!要做的工作很多,但這項投資看不到什麽短期回報。

React非常適用於包含很多實時通知的復雜單頁面應用程序,但是對簡單應用來說,它不見得合適。

舉例 2:TDD被DHH殺死了


David Heinemeier Hansson(DHH,Ruby on Rails框架的創造者)意識到,Rails的框架裏沒有對OOP支持很好的架構,所以很難做測試驅動開發。於是他做了個現實的選擇:不要提前寫測試代碼。

DHH的博客和會議演講引發了熱鬧。關鍵詞:TDD is DEAD。

忘了測試吧!我們的領袖說過。一個測試也不要寫。我們可不是在假裝,而是虔誠地執行。

等等!以前一些能正常運行的代碼現在都出問題了。我們正在寫的代碼錯誤百出。

TDD無所謂生死。TDD是需要權衡的對象,權衡因素包括API變化的風險、既有設計、參與者的水平——Kent Beck。


舉例3:微服務


巨大的單體系統很難擴展。在某個時候我們可以把它拆成多個服務。如果用QPS之類的指標來衡量,擴展就容易很多,也更容易拆散到多個團隊。

熱鬧關鍵詞:可伸縮性、松耦合、單體系統。

讓我們重寫所有的服務!我們的單體系統都成了一碗“意大利面條”了。得把所有東西都拆成微服務。

見鬼!現在系統開發的速度變慢了,部署的難度提高了,我們還花了不少時間在多個系統之間追蹤bug。

微服務需要團隊有充分的DevOps能力,還需要權衡增加系統和團隊擴展性,保證投入劃算。在你遇到嚴重的規模問題之前,這樣的投資是超前的。微服務是提煉出來的,不是重寫出來的。按照Martin Folwer的說法,微服務的門檻可不低。

舉例 4:NoSQL


在應對高壓力和處理非結構化數據時,SQL數據庫有不少問題。全世界的團隊都在研究新一代數據庫。

熱鬧關鍵詞:可伸縮性、大數據、高性能

我們的數據庫太慢,而且容量不夠。我們需要NoSQL。

我們還需要聯表查詢?這可不行。簡單的SQL操作現在都越來越有挑戰了。開發速度越來越慢,我們的核心問題還沒解決。

NoSQL是用來解決特定問題的(要麽是海量的非結構化數據,或者非常高的負載)。如果水平足夠高,關系數據庫也是應對高負載和處理海量數據的好工具。一定需要NoSQL的情況,在2016年仍然不多見。

舉例 5:Elixir和Phoenix
 (或者是你喜歡的語言/框架組合)


RoR之類的Web框架不能很好地應付高性能應用、分布式應用、Websockets。

熱鬧關鍵詞:可伸縮性、高性能、分布式、容錯性。

噢,我們的系統太慢,我們的聊天系統不是可伸縮的。

才發現,學習函數式編程和分布式解決方案沒那麽容易,我們進展真慢。

Elixir和Phoenix是很優秀的框架,但學習成本太高。如果你確實需要高性能的系統,它的益處要很長時間才會顯現。

推而廣之


在軟件開發的小小天地裏,已經有太多領域是熱鬧非凡的了。在JavaScript裏,幾乎每天都有新框架誕生。Node.js(關鍵詞:事件編程),React編程,Meteor.js(關鍵詞:共享狀態),前端MVC,React.js…… 你可以隨便舉例。軟件工程領域裏新架構也在誕生:領域驅動開發,六邊形架構理論,DCI架構(數據-場景-交互)。哪種你最喜歡?


正面的例子


如果我們不能相信網上的言論或是其他人的說法,那如何做出聰明的選擇?下面是一些好的建議:


先測試、研究,再決定


快速搭建原型,不要從博客學習,而要從經驗學習。針對新技術提供的功能,在決定采用之前花一兩天搭個原型,然後組織團隊分析利弊。你可能會遇到若幹能彼此替代的技術,可以讓團隊裏不同人用不同的技術搭原型。


黑客馬拉松,這也是不錯的辦法,它讓大家真正領悟不同技術的代價幾何。讓整個團隊花一兩天來把玩所有兼具風險和誘惑力的技術。這會讓大家自主做出聰明的選擇,根據自己的經驗來決策。


何時開始?

原則上說,應當選擇投資回報巨大的時間點開始。大多數技術是用來解決特定問題的。你遇到了那個問題嗎?那個問題重要不重要?會不會節省很多時間?新技術帶來的好處能不能抵消學習成本和重新的成本?如果我們一開始就把開發速度降到1/2甚至1/4?這樣還值得嗎?


偉大的團隊有更多自主權——一些團隊只是能比其他團隊更快創造價值。他們更容易厭煩自己手頭的工作。這些團隊可以更頻繁地引入新技術。但這不是省略快速搭建原型或者黑客馬拉松的理由。相反,如果這樣的團隊在交付上遇到了麻煩,一定要加倍小心。


雇傭對的人


有良好技術背景的人——那些人了解不同的範式,理解編程的理論(算法和並發),受過良好工程文化熏陶,這樣的人很少去湊熱鬧。


有經驗的人——年輕的開發人員更喜歡湊熱鬧。如果有多年的開發經驗,見過許多技術,踩過許多坑,在選取技術時就更容易做出客觀的判斷。

延伸阅读

    评论