北京单场玩法

談談技術選型

2017-05-20

軟件開發團隊所做的軟件架構或技術棧的決策,很多并沒有經過踏實的研究和對目標成果的認真思考,而是不準確的意見、社交媒體的信息,或者就些是“熱鬧”的玩意。我稱這種作派為“熱鬧驅動開發(Hype Driven Development,HDD)”,眼見它的危害,我贊成更專業的做法,就是“腳踏實地的軟件工程”。下面我們一起看看HDD的來龍去脈,想想能如何改進。

新技術帶來新希望

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

熱鬧驅動開發

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

  • Reddit驅動開發。在選擇技術、架構、設計方案時,團隊和個人的決策依據是知名博主的文章,或者Reddit、Hacker News、博客、Twitter、 Facebook、GitHub以及其它社交媒體上的熱門信息。

  • 技術會議驅動開發。仔細觀察觀察,參會回來的家伙們有什么表現。他們聽了演講興致高漲。然而這是雙刃劍。他們沒有做足夠的研究,就開始使用最新最熱的類庫、框架、架構范式,于是可能踏上通往地獄的高速公路。

  • 嗓門驅動開發。有人整天談論新框架/類庫/技術,他自己其實沒有實際經驗,但是反復念經終于讓團隊決定采納他的意見。

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

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

HDD就是開發團隊自掘墳墓

湊熱鬧的問題是:它很容易導致錯誤決策。無論是糟糕的架構決策,還是糟糕的技術棧決策,對團隊的影響都常常持續數月甚至數年。最壞的結果是造成極其嚴重的軟件工程問題,只能推倒重來。但推倒重來而成功的案例幾乎沒有。

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

湊熱鬧的起承轉合

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

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

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

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

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

第三階段:狂熱現身

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

第四階段:心灰意冷

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

第五階段:反省領悟

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

HDD舉例

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

舉例 1:React.js

  1. Facebook遇到了一個問題,Facebook自己的復雜單頁面應用里會出現各種狀態改變的事件,必須追蹤到發生了什么,并且保持狀態的連貫一致。

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

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

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

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

舉例 2:TDD被DHH殺死了

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

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

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

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

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

舉例3:微服務

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

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

  3. 讓我們重寫所有的服務!我們的單體系統已經是一鍋粥了。得把所有東西都拆成微服務。

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

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

舉例 4:NoSQL

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

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

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

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

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

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

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

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

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

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

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

推而廣之

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

正面的例子

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

先測試、研究,再決定

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

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

何時開始?

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

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

找到對的人

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

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


  • 查看地圖,了解我們的位置
  • 關注微信,一舉一動盡在掌握

億校云是一支致力于開拓學校型軟件的團隊,
專注于為校園互聯網建設提供解決方案。

    • 公司:杭州億校云信息技術有限公司
    • 地址:杭州市濱江區濱文路426號文苑大廈13樓1308
    • 電話:0571-85100351
    • 郵箱:[email protected]
Close
北京单场玩法 北京pk10单期计划网此 曲棍球视频 牌九至尊手机版 火龙果计划app AG甜一甜屋开奖数据 必中一位 金花线上娱乐 捕鱼来了ss级炮开拓者 彩票领奖后出门被跟踪 抢红包赚钱APP下载