人們經常談論優秀設計和糟糕設計。你的設計屬於哪一種?
有很多軟件開發團隊的設計從來經不起思考。他們採用一種我稱之為“任務板挪卡” 的方法來代替設計。團隊有一個開發任務清單,比如 Scrum 產品待辦列表,其中的任務被張貼在“任務板”上,然後他們可以將一張便利貼從“任務板”上的“待辦”泳道移動到“進行中”泳道,這就是“任務板挪卡”。
產品經理提出待辦項(任務),然後來一次“任務板挪卡”,這便構成了關於設計的全部“真知灼見”,剩下的就交給程序員大神們去瘋狂輸出代碼。很少有團隊會這樣做,如果真的這樣做了,業務就會為這些不存在的設計付出最高昂的代價。
這種情況常常是因為團隊必須按照苛刻得近乎殘忍的時間表去發佈軟件,管理層只會使用 Scrum 控制交付節奏,卻對它最重要的信條之一:知識獲取 (Knowledge Acquisition) ,視而不見。
在我獨立進行諮詢和培訓的經歷中,經常會遇到相同的情境。軟件項目如履薄冰,所有團隊成員都在努力地維護著系統穩定,每天面對著代碼和數據打補丁。以下是我發現的一些潛在問題,有趣的是,
這一切都似乎發生在“設計無法帶來低成本的軟件”的觀念下。而這時常是出於商業上的簡單考慮,軟件開發人員並不知道還有其他更好的選擇。“軟件正在蠶食整個世界”,對你而言重要的是,軟件不但可以蠶食你的利潤,也可以提供一場利潤盛宴。
你一定要明白,臆想出來的“不做設計能省錢”的觀念簡直是一個謬論,它已經巧妙地愚弄了那些不思考周詳設計而只會對軟件交付施壓的人們。這是因為設計仍然會從每個開發人員的腦海流淌到在鍵盤上不斷敲打著代碼的指尖之中,這些設計並不需要來自其他地方的輸入,包括業務。以下這句話可以很好地總結這種現象:
關於設計是否必要或是否負擔得起的問題根本都沒有問到點上:設計是不可或缺的。除了優秀設計就是糟糕設計,根本不存在“不做設計”一說。儘管 Martin 先生的這句評論並非專門針對軟件設計,但這同樣適用於我們的技藝,考慮周詳的設計同樣無可取代。在剛才的情景中,如果一個項目由五名開發人員參與,那麼“不做設計”將會產生五種不同的設計。也就是說,在沒有任何真正領域專家的協助下,你開發出來的軟件將會混雜著五種不同的、虛構出來的、對業務語言的詮釋。
事實上:無論承認與否,我們都是在構建模型。
這就好比修建道路。一些歷史悠久的道路最開始是跑馬車的,經過歲月的碾壓最終變得年久失修。為了滿足少數人的需要,它們被加入了不明所以的轉彎和岔路,並被改造得迂迴曲折。在某個時刻,它們會被剷平並且會被重新建設,為的是讓越來越多的旅客感到舒適。這些將就湊合的道路到現在還有人路過,不是因為它們設計良好,而僅僅是因為它們存在著而已。如今很少有人能夠了解行走在這些道路上彆扭不堪的原因。而現代道路都會依據人口、環境以及可預測的流量來規劃和設計。兩種類型的道路都會被建模。一種模型只是做了最基本、最簡單的思考,另一種則最大程度地發揮了聰明才智。軟件建模也可以從這兩種角度出發。
如果你擔心周詳的設計會帶來高昂的軟件開發成本,那麼設想一下,將來為了維護甚至修繕一套糟糕設計的軟件就需要付出更為昂貴的代價。當我們把軟件作為你的公司與其他公司之間的差異,並依靠它帶來可觀的競爭優勢時,尤其如此。
“有效(Effective)”一詞和“優秀(Good)”意義相近,它能更準確地表達我們應該在軟件設計中努力追求的目標:“有效設計”(Effective Design)。有效設計可以滿足商業組織希望藉助軟件超越競爭者的訴求。它可以驅動企業去思考哪些核心業務必須成為其競爭力,還可以指引構建正確軟件模型的方向。
Scurm 中的知識獲取是通過不斷的試驗及協作學習完成的,這被稱為“知識付費”(Essential Scrum)。知識永遠都不是免費的,但在《領域驅動設計精粹》中,我將提供一些方法幫你更快地獲取它們。
如果你對有效設計的影響仍心存疑慮,別忘了那位曾洞察其重要性的人:
絕大部分人錯誤地認為設計只關乎外觀。人們只理解了表象——將這個盒子遞給設計師,告訴他們:“把它變得好看一些!”這不是我們對設計的理解。設計並不僅僅是感觀,設計也是產品的工作方式。 ——喬布斯軟件開發中,有效設計最為重要。如果只有一個選擇,那麼我首推有效設計。
本文節選自《領域驅動設計精粹》(Domain-Driven DesignDistilled)一書,該名家名著現已全面上市,點擊擴展鏈接瞭解詳情。
本書適用於對快速學習DDD核心概念和主要工具,表面上看最主要的讀者是軟件架構師和開發者,因為他們是在項目中實踐 DDD的人,也跟容易發現DDD的美妙之處。然而,本書同樣可以幫助高管、領域專家、經理人、業務分析師、信息架構師和測試人員快速理解這一主題並認識到其獨特價值。閱讀原文將帶你領略DDD大師Vernon的這部新作,它必將成為國內眾多團隊快速引入和落地DDD的絕佳指導。