37 Signals的實用最小主義實踐

儘管有那些可能性——複雜度、延誤和不可預知的改動——還是有許多軟體寫出來、交付出去、而且最終被使用。偶爾軟體會很好。在一些罕見情形下，軟體的確有創新和價值。在一些案例中，還真按計劃達成了目標。

在這些稀有案例中，成功往往是鐵一般紀律的副產品——一種堅決做出又在每次遇到挑戰時大聲重申的選擇，限制著專案的範圍。在軟體的成功故事中，你總 能發現善於拒絕的人們。如同有意只在調色盤上塗抹一種顏色的畫家、寧肯寫十四行詩也不寫自由體詩歌的詩人，或者只固守小規模優勢產品線的廠商一樣，成功的 程式設計師也在約束中成長，而非沒有約束。有時候，約束是環境的產物——預算少、時間緊、目標有限。有時，約束是有經驗的程式設計師或經理強加給自己的，他們懂得 如何避開結局不可預料的——以軟體界的說法來講，“未繫結的”——專案。無論哪種情形，都更多地考慮“大即險”，而不是“小即美”。

約束是打造偉大產品的關鍵

有家位於芝加哥、名為37 Signals的小公司，正是這種擁抱限制的方式之代表者。37 Signals最初是一家網頁設計資訊公司，後來為了滿足自身需求而將業務擴充套件到軟體開發領域。他們編寫了一些用於專案管理的內部工具。為了和客戶溝通， 就向客戶開放了部分系統。公司創始人和總裁傑森•弗瑞德（Jason Fried）解釋說，在他們自己意識到之前，已經做出了一套基於網頁的應用。又做了4個月，他們把軟體轉換為稱作Basecamp的服務。 Basecamp釋出於2004年2月，很快在類似Flickr和Google的Gmail等新Web富應用天堂中名列前茅。

Basecamp只是這家公司花一年多時間投入少量程式設計師做出來的一系列值得注意的小而精的產品之一。Basecamp之後是Ta-da List，用於儲存和共享待辦事項（及類似事項）列表。幾個月後推出了Backpack，它允許使用者儲存和共享便籤及檔案。每種產品都可靠並易於使用，而 且都是精心設計的。每種產品通常也都只包括少量新特性。例如，Basecamp就有一些精巧的電子郵件功能：和其他服務和程式一樣，也可以設定郵件到達提 醒——還可以從另外的計算機或手機等移動裝置向Backpack網頁傳送郵件，郵件文字就會在頁面上顯示出來。

我剛開始使用Backpack時，是用來儲存本書的零散調研筆記。2004年秋天在一個技術大會上偶遇弗瑞德，我問他37 Signals怎麼能在如此之短的時間內做出這麼有用的軟體。他大力鼓吹自己的方法——他公司開了個名為“製作Basecamp”的訓練班，將所用原則做 成了一套PowerPoint幻燈片——而且逼著我在酒店大堂裡聽了45分鐘關於其方法論的概要介紹。

首先，37 Signals只有一位開發者，所以就避開了布魯克斯法則的泥沼——就像米奇•卡普爾最初做Lotus 1-2-3那樣，當時也只有喬納森•薩赫斯（Jonathan Sachs）一位程式設計師。開發者之間的協調不成問題。37Signals唯一的開發者戴維•海因梅爾•漢森（David Heinemeyer Hansson）住在丹麥，就連這似乎也不成問題。弗瑞德說，在大多數公司裡，地理上的分隔會被看做是嚴重問題，不過時差卻讓他們真的只有區區幾個小時可 以討論，所以他們會高效利用這點時間，跟著開發者們就能平心靜氣地寫程式碼，不受干擾。

照37 Signals的做法，約束是朋友。“約束是打造偉大產品的關鍵，”弗瑞德說，“約束產生創意。如果有人說，給你全世界的財富，讓你做任何想做的東西，那這東西多半永遠釋出不了。給我一個月就好！”

實用最小主義的基礎——Web應用

37 Signals生產優秀軟體的另一關鍵要素是緊抓Web應用不放。所有東西都通過網頁瀏覽器執行，所以程式可以在任何能執行瀏覽器的計算機和作業系統上工 作。版本更新可以很容易地在執行服務的伺服器上做到，使用者無須下載和安裝更新。漢森還熱衷於Ruby，一種物件導向動態程式語言。Ruby近似於 Python，不過較少為人知，漢森發現它簡化了自己的工作。最後，37 Signals的方式還避開了編寫規約的環節；相反，一開始就做使用者將看到的詳細網頁。這些頁面設計成了規約。弗瑞德說，他的團隊很少會長時間爭辯頁面上 的每個詞、按鈕和方塊。

37 Signals只做小程式，不做野心勃勃的新平臺或應用程式框架。但在打造Basecamp的過程中，漢森還寫了一些有用的創新程式碼，改善和簡化了所有 Web應用在儲存和獲取資料時都要執行的細節基礎操作。Basecamp釋出後，他和37 Signals決定把這部分工作拿出來，作為一套開源平臺釋出，名字是Ruby on Rails。這套將被命名為Rails的框架在某種程度上通過約束程式設計師的可選手段使得編寫Web應用更為簡單。“靈活性被過分高估——約束才是解放，” 漢森說。Rails也具備實現AJAX風格增強介面的能力，這種新介面風格讓基於Web的程式足以與桌面應用抗衡。

37 Signals從Basecamp中抽出Rails的同時，還從Basecamp的經驗中歸納出一套設計哲學，體現為一系列小警句：“精簡程式碼。”“拒絕 在先。”“找對人。”“與其做半成品，不如做功能減半的優質品。”這些短句是為了通過幻燈片快速演示，不過合起來卻是一整套軟體開發方法——姑且稱之為實 用最小主義。它也許不能滿足鼓舞瞭如此多程式設計師的改變世界之癮。你也可以批評它是鋒芒盡失的表現。它看似不適用於那些別無選擇只能做大的軟體。用程式設計師們 的話來說，就是“配不上”。

Google也實用最小主義

不過依據37 Signals一直以來的跟蹤記錄，有個最大的推薦理由：它的行事方式看來的確有效。類似的方式在一家規模更大、也更為著名的軟體公司中已經獲得空前成功 ——甚至可以不太誇張地說，獲得了改變世界式的成功。Google遵循一種聽起來很像傑森•弗瑞德推崇的那種軟體開發哲學，成長為規模達數十億美元的巨 獸，並且開始挑戰微軟：每個新專案專設一個小團隊，開發期限緊迫，做出目標集中的網頁產品，然後再根據使用者反饋和領域經驗加以逐步改進。Google也讓 開發者把五分之一的工作時間花在個人專案上。這“20%時間”的勞動成果可能會變成很酷的新產品——或者不會。不用擔心，Google安撫員工說：儘管開 幹，撓你自己的癢處。

Google因打造了工程師天堂而獲得讚譽，演算法稱王、編碼者說了算。那些有幸受僱於Googleplex的人——包括安迪•赫茲菲爾德和2005 年加入的Python發明人圭多•範•羅薩姆——暫時在這裡逃離了軟體時間的困境。Google做出過一些半成品，但無人能質疑其成功的價值——從最初的 搜尋引擎到基於關鍵字的廣告業務，以及流行的新免費電子郵件服務。

實用最小主義在Google用得很好。而且它現已成為一家聲名顯赫的公眾公司，面對著跟上成長步伐和找到新收入來源的壓力。對於許多人來說，看似 Google正在一手製造矽谷的新泡沫。如果它在這種情形之下堅守其方法論，想出如何在不變慢、不變笨的前提下成長得更大，那麼它將是軟體業歷史上獨一無 二的。

---

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-567466/，如需轉載，請註明出處，否則將追究法律責任。