要“軟體工藝”還是要“足夠用的設計”
InfoQ的一篇譯文：http://www.infoq.com/cn/news/2010/05/sufficient-design
Joshua Kerievsky：要“軟體工藝”還是要“足夠用的設計”
作者 Mike Bria 譯者 韓鍇 釋出於 2010年5月30日 下午7時42分
社群 架構 , Java, Ruby, .NET, 敏捷 主題 商業, 企業級敏捷 標籤 精益, 設計準則
分享 |
在過去的一段時間裡，“軟體工藝”在不斷地被熱議。 針對軟體工藝運動所強烈崇尚的“程式碼必須時刻保持乾淨”的信仰，Joshua Kerievsky提出了另一種可能從反方向審視的視角，他稱之為“足夠用的設計”。在此我們將探究Joshua的想法，並聽一聽Bob Martin和Ron Jeffries對此的評價。
Kerievsky首先講述了他遇到的問題，然後表示會發表一系列關於“足夠用的設計”的文章。
...有些程式設計師堅持軟體的每一段程式碼的設計質量都應該儘可能地高。“不能生產乾淨的程式碼就稱不上軟體匠人”...
這個建議的初衷是好的。我們中的很多人都見過被沉重的技術債拖垮的專案。
然而，軟體工匠的觀點並沒有考慮到一個簡單的經濟學：如果你花時間去雕琢那些對使用者價值不高的程式碼，你就是在浪費時間和金錢。
事實上，有些程式碼並不需要非常卓越的設計，比如一些實驗性的程式碼，或者不重要的特性。
Joshua接下來講述了一個發生在他自己的開發團隊中的故事：應用程式中的Action類的processWith方法按照基類的約定，應該返回字串型別的值，但是其中一個Action不需要返回值，因此他們決定讓Action直接返回null。這就帶來了一個設計上的壞味道。這段有問題的程式碼就這樣存在了很多年，期間還團隊還嘗試過重構程式碼將它移除，但沒有成功，它依然存在。Joshua說，這段問題程式碼並有影響到他的團隊。他非常肯定，這個問題並沒有阻礙他的團隊的開發進度，因此花時間去處理這個問題並不明智，還不如把時間用於開發更重要的特性上。這個故事的寓意是：
對於關鍵的部分，我們需要高質量的設計，反之，可以放低對質量的要求。
...
今天，軟體設計質量的藝術是這樣定義的，它取決於個人或者團隊能否根據特性的重要程度來調整設計的錶盤，從而創造人們喜愛又能賺錢的產品。
對於軟體質量，沒有放之四海皆準的方法。
如果你個“新特性癮君子”，總是不斷地增加新特性，而不對軟體的設計多做些思考的話，那麼在釋出4.0版的時候就會被技術債拖垮了。
如果你是個“質量癮君子”，那麼就會對所有事情都過度設計。
當精益遇到工藝時，就有了“足夠用的設計”。
最近一直引領著“軟體工藝運動”的Bob大叔（Bob Martin）很快給出了回覆，可能令所有人驚訝的是，他竟然也支援Joshua的結論：
在我看來，Josh的行為正說明他是一個十足的軟體工匠。他擔心過那些軟體工匠們應該擔心的事情。他也做出了軟體工匠們應該做出的務實的決定。他沒有在系統中尚殘留著大量糟糕設計的時候，就急著去實現下一個特性。相反，他非常在乎他的程式碼。
Martin還繼而澄清了他的立場，“軟體工藝”傳達的並不是“要麼完美，要麼完蛋”的二元選擇，就像Joshua已經暗示的那樣：
軟體工匠們首先是實用主義者。他們對高質量程式碼的嗅覺非常靈敏；但是他們也不會為了追求完美而嚴重地犧牲經濟利益。
Ron Jeffries也發表了類似的觀點。他也一直在積極倡導保持程式設計成果清晰乾淨。Ron的文章可以濃縮為兩句話：第一，設計債是“遲早都要還的”；第二，我們應該努力讓自己的有能力幹得又快又好：
如果你以犧牲質量換速度，那麼從長期質量來看，欠下的債總是要還的。
從另一角度來看，如果那時我們自身比現在更優秀，就不必透過犧牲質量來換速度了。我們需要提高。但是不能一口吃成胖子：今天我們暫時透過犧牲質量來換取速度。但是應該在牆上寫下：
如果犧牲質量能讓我們更快一些的話，那麼這就清楚地表明我們還有很大的空間有待提升，以更快的速度交付更好的軟體。
不久之後，Kerievsky又發表了該系列的第二篇文章（正如他表示過的，會有很多），這一次他更加直率地表示，有時候“足夠用”就意味著不必把某些事情做得足夠好。他講了另一個發生在Industrial Logic開發團隊的故事，這次的主角是一個“巨型類”，它出現在實現“播放列表”功能的程式碼中。播放列表特性包含在eLearning的一次重要釋出中：
經過不斷地使用播放列表，並且對使用資料進行分析，一年以後我們知道：
我們的使用者的確在使用播放列表。
還沒有使用者抱怨過播放列表。
使用者並沒有像極力稱讚其他一些特性那樣，稱讚播放列表。
在銷售的時候，當聽到播放列表將來會針對一些特定的主題提供一個具有時效性的資訊列表後，未來潛在的使用者表現得很有興趣。
那麼，我們不要不花錢去解決播放列表中存在的設計問題呢？
不。
原因如下：
沒有新行為：在過去的一年裡，我們沒有新增或者改變原來的播放列表的任何行為。
不用改變程式碼：在過去的一年裡，我們只在UserLibrary（播放列表設計債的主要來源）中做了少量的修改，這些變化也不會影響到播放列表的功能。
問題被隔離了：儘管播放列表的設計很糟，但是它被隔離了，並沒有滲入到過去一年中其它新特性的開發中。
播放列表只是取悅我們最大的客戶的一份甜點而已。
這個特性確實有用，但是它並不屬於產品開發的關鍵部件。
在播放列表中的程式碼壞味道，比如“巨型類”和“複雜的條件判斷”，並沒有讓我們的開發慢下來。
我們管理質量的出發點是：
如果我們決定給使用者一個更加完善的播放列表功能，那麼在開始以前，我們會無怨無悔地償清設計債的。
Joshua解釋說，當未來的特性牽涉到播放列表時再來解決這些問題，他並不覺得很麻煩。這種信心從大的方面講是由於他的團隊的能力和嚴格遵守的TDD，另一方面也是因為他明白並接受這一點：有時候低質量也是可接受的，有時候錶盤也要調節到高質量檔。他總結道：
這一年來我們對播放列表的程式碼滿意嗎？
由於我們沒有對它投入必要以外的時間和金錢，對此我們很滿意。
我們樂於讓設計變得更乾淨，但是要等到正確的時間。
這就是“足夠用的設計”。
你怎樣想？Joshua的建議能夠被普遍接受嗎？你用類似的方法在自己的專案中取得成功了嗎？還是失敗了？進一步的討論還需要再考慮哪些因素？
檢視英文原文：Joshua Kerievsky Introduces "Sufficient Design" To The Craftsmanship Discussion
Joshua Kerievsky：要“軟體工藝”還是要“足夠用的設計”
作者 Mike Bria 譯者 韓鍇 釋出於 2010年5月30日 下午7時42分
社群 架構 , Java, Ruby, .NET, 敏捷 主題 商業, 企業級敏捷 標籤 精益, 設計準則
分享 |
在過去的一段時間裡，“軟體工藝”在不斷地被熱議。 針對軟體工藝運動所強烈崇尚的“程式碼必須時刻保持乾淨”的信仰，Joshua Kerievsky提出了另一種可能從反方向審視的視角，他稱之為“足夠用的設計”。在此我們將探究Joshua的想法，並聽一聽Bob Martin和Ron Jeffries對此的評價。
Kerievsky首先講述了他遇到的問題，然後表示會發表一系列關於“足夠用的設計”的文章。
...有些程式設計師堅持軟體的每一段程式碼的設計質量都應該儘可能地高。“不能生產乾淨的程式碼就稱不上軟體匠人”...
這個建議的初衷是好的。我們中的很多人都見過被沉重的技術債拖垮的專案。
然而，軟體工匠的觀點並沒有考慮到一個簡單的經濟學：如果你花時間去雕琢那些對使用者價值不高的程式碼，你就是在浪費時間和金錢。
事實上，有些程式碼並不需要非常卓越的設計，比如一些實驗性的程式碼，或者不重要的特性。
Joshua接下來講述了一個發生在他自己的開發團隊中的故事：應用程式中的Action類的processWith方法按照基類的約定，應該返回字串型別的值，但是其中一個Action不需要返回值，因此他們決定讓Action直接返回null。這就帶來了一個設計上的壞味道。這段有問題的程式碼就這樣存在了很多年，期間還團隊還嘗試過重構程式碼將它移除，但沒有成功，它依然存在。Joshua說，這段問題程式碼並有影響到他的團隊。他非常肯定，這個問題並沒有阻礙他的團隊的開發進度，因此花時間去處理這個問題並不明智，還不如把時間用於開發更重要的特性上。這個故事的寓意是：
對於關鍵的部分，我們需要高質量的設計，反之，可以放低對質量的要求。
...
今天，軟體設計質量的藝術是這樣定義的，它取決於個人或者團隊能否根據特性的重要程度來調整設計的錶盤，從而創造人們喜愛又能賺錢的產品。
對於軟體質量，沒有放之四海皆準的方法。
如果你個“新特性癮君子”，總是不斷地增加新特性，而不對軟體的設計多做些思考的話，那麼在釋出4.0版的時候就會被技術債拖垮了。
如果你是個“質量癮君子”，那麼就會對所有事情都過度設計。
當精益遇到工藝時，就有了“足夠用的設計”。
最近一直引領著“軟體工藝運動”的Bob大叔（Bob Martin）很快給出了回覆，可能令所有人驚訝的是，他竟然也支援Joshua的結論：
在我看來，Josh的行為正說明他是一個十足的軟體工匠。他擔心過那些軟體工匠們應該擔心的事情。他也做出了軟體工匠們應該做出的務實的決定。他沒有在系統中尚殘留著大量糟糕設計的時候，就急著去實現下一個特性。相反，他非常在乎他的程式碼。
Martin還繼而澄清了他的立場，“軟體工藝”傳達的並不是“要麼完美，要麼完蛋”的二元選擇，就像Joshua已經暗示的那樣：
軟體工匠們首先是實用主義者。他們對高質量程式碼的嗅覺非常靈敏；但是他們也不會為了追求完美而嚴重地犧牲經濟利益。
Ron Jeffries也發表了類似的觀點。他也一直在積極倡導保持程式設計成果清晰乾淨。Ron的文章可以濃縮為兩句話：第一，設計債是“遲早都要還的”；第二，我們應該努力讓自己的有能力幹得又快又好：
如果你以犧牲質量換速度，那麼從長期質量來看，欠下的債總是要還的。
從另一角度來看，如果那時我們自身比現在更優秀，就不必透過犧牲質量來換速度了。我們需要提高。但是不能一口吃成胖子：今天我們暫時透過犧牲質量來換取速度。但是應該在牆上寫下：
如果犧牲質量能讓我們更快一些的話，那麼這就清楚地表明我們還有很大的空間有待提升，以更快的速度交付更好的軟體。
不久之後，Kerievsky又發表了該系列的第二篇文章（正如他表示過的，會有很多），這一次他更加直率地表示，有時候“足夠用”就意味著不必把某些事情做得足夠好。他講了另一個發生在Industrial Logic開發團隊的故事，這次的主角是一個“巨型類”，它出現在實現“播放列表”功能的程式碼中。播放列表特性包含在eLearning的一次重要釋出中：
經過不斷地使用播放列表，並且對使用資料進行分析，一年以後我們知道：
我們的使用者的確在使用播放列表。
還沒有使用者抱怨過播放列表。
使用者並沒有像極力稱讚其他一些特性那樣，稱讚播放列表。
在銷售的時候，當聽到播放列表將來會針對一些特定的主題提供一個具有時效性的資訊列表後，未來潛在的使用者表現得很有興趣。
那麼，我們不要不花錢去解決播放列表中存在的設計問題呢？
不。
原因如下：
沒有新行為：在過去的一年裡，我們沒有新增或者改變原來的播放列表的任何行為。
不用改變程式碼：在過去的一年裡，我們只在UserLibrary（播放列表設計債的主要來源）中做了少量的修改，這些變化也不會影響到播放列表的功能。
問題被隔離了：儘管播放列表的設計很糟，但是它被隔離了，並沒有滲入到過去一年中其它新特性的開發中。
播放列表只是取悅我們最大的客戶的一份甜點而已。
這個特性確實有用，但是它並不屬於產品開發的關鍵部件。
在播放列表中的程式碼壞味道，比如“巨型類”和“複雜的條件判斷”，並沒有讓我們的開發慢下來。
我們管理質量的出發點是：
如果我們決定給使用者一個更加完善的播放列表功能，那麼在開始以前，我們會無怨無悔地償清設計債的。
Joshua解釋說，當未來的特性牽涉到播放列表時再來解決這些問題，他並不覺得很麻煩。這種信心從大的方面講是由於他的團隊的能力和嚴格遵守的TDD，另一方面也是因為他明白並接受這一點：有時候低質量也是可接受的，有時候錶盤也要調節到高質量檔。他總結道：
這一年來我們對播放列表的程式碼滿意嗎？
由於我們沒有對它投入必要以外的時間和金錢，對此我們很滿意。
我們樂於讓設計變得更乾淨，但是要等到正確的時間。
這就是“足夠用的設計”。
你怎樣想？Joshua的建議能夠被普遍接受嗎？你用類似的方法在自己的專案中取得成功了嗎？還是失敗了？進一步的討論還需要再考慮哪些因素？
檢視英文原文：Joshua Kerievsky Introduces "Sufficient Design" To The Craftsmanship Discussion
相關文章
- 還是要理性
- [軟體工藝]
- 除了程式設計還有其它的要學程式設計
- 軟體工藝運動的目標是什麼？
- 為什麼要這樣設計，還是我理解錯誤
- 記憶體不夠用還要速度快，終於找到可以基於 File 的 Cache 了記憶體
- 軟體開發者六要
- 該寫的總結還是要寫
- 要麼程式設計要麼被程式設計程式設計
- 記憶體分頁不就夠了？為什麼還要分段？還有段頁式？記憶體
- 作為ui設計師，你必須要熟練的幾款設計軟體UI
- 《軟體故事》：軟體和程式設計藝術的興起程式設計
- 軟體正在改變世界，為什麼程式設計師卻得不到足夠的尊重？程式設計師
- 程式設計師要搞明白CDN，這篇應該夠了程式設計師
- 中國程式設計師還要多久才能超越美國同行？程式設計師
- 手機應用軟體測試的思路與要點
- [筆記]軟體工藝1－4筆記
- 換ip軟體的挑選要點
- 軟體測試內容的要點
- 什麼是工業物聯網？IIoT的要點
- 軟體測評中心簡要分析：為什麼要進行軟體效能測試?
- 程式設計師憤怒了：我們不僅要當管理者還要當CEO！程式設計師
- 軟體是一門藝術
- 【架構設計】你的類足夠“專一”嗎架構
- 軟體工程設計模式——行為型模式之策略模式簡要概述軟體工程設計模式
- 為什麼要學習設計模式(Design Patterns) - 軟體設計大師之路 (轉)設計模式
- 軟體框架設計的藝術----讀書總結框架
- APP測試設計測試用例的要點APP
- 設計師為什麼要學程式設計，開發者為什麼要學設計？程式設計
- 一個好的軟體測試計劃要怎麼寫？
- 軟體測試要學什麼（6）發展前景及工資待遇
- CRM軟體定製要多少錢？
- 防毒軟體要慎用!分享防毒軟體的幾個誤區防毒
- 網站設計要點網站
- 有效銷售軟體的四點要點
- 程式設計師的日常生活：年底如何搞定那些要跳槽的員工？程式設計師
- 那些拿命換錢的程式設計師，換著換著還是要讀一讀《程式設計師健康指南》程式設計師
- 程式設計要自學或報班這事你都想不明白， 那必然是你智商不夠程式設計