程序猿和架構(gòu)師都應(yīng)該了解“康威定律”(Conway's law)

程序猿和架構(gòu)師都應(yīng)該了解“康威定律”(Conway's law)

什么是康威定律

康威定律是一句格言,指出組織設(shè)計(jì)系統(tǒng)來反映他們自己的溝通結(jié)構(gòu)。它以計(jì)算機(jī)程序員梅爾文·康威的名字命名,他于1967年提出了這個(gè)想法。他最初的措辭是:

organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations. —?M. Conway

一個(gè)組織的系統(tǒng)通常被設(shè)計(jì)成這個(gè)組織通信結(jié)構(gòu)的副本

Jietu20200201-174349@2x.jpg

我的理解:你的組織是什么樣子的,最終這個(gè)組織信息系統(tǒng)肯定也是相同樣子。效率高的組織,系統(tǒng)效率自然也高。效率低的組織,做成的信息系統(tǒng)效率也肯定不高。

后來康威定律被引申為下面的四條

第一定律 Communication dictates design
組織溝通方式會(huì)通過系統(tǒng)設(shè)計(jì)表達(dá)出來

第二定律 There is never enough time to do something right, but there is always enough time to do it over
時(shí)間再多一件事情也不可能做的完美,但總有時(shí)間做完一件事情

第三定律 There is a homomorphism from the linear graph of a system to the linear graph of its design organization
線型系統(tǒng)和線型組織架構(gòu)間有潛在的異質(zhì)同態(tài)特性

第四定律 The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems
大的系統(tǒng)組織總是比小系統(tǒng)更傾向于分解

如此簡(jiǎn)單的一句話怎么成為了定律

其實(shí)這不過作者的經(jīng)驗(yàn)總結(jié),發(fā)表在《Datamation》雜志上。但是后來Brooks在著名的《人月神話》中引用康威的觀點(diǎn),并將其稱贊為我們熟知“康威定律”。

Adding manpower to a late software project makes it later --Fred Brooks, (1975)

為了趕進(jìn)度加程序員就像用水去滅油鍋里的火一樣(無奈大家還是前赴后繼)。

Because the design that occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.

由于首先發(fā)生的設(shè)計(jì)幾乎從來不是最好的可能,因此流行的系統(tǒng)概念可能需要更改。因此,組織的靈活性對(duì)有效設(shè)計(jì)至關(guān)重要。

由此可知,大牛們?cè)缭诎雮€(gè)世紀(jì)前就告知我們先優(yōu)化組織,在優(yōu)化系統(tǒng)。沒有敏捷的組織,就沒有敏捷的開發(fā)團(tuán)隊(duì)。

在康威的文章中,他還提到了

There is never enough time to do something right, but there is always enough time to do it over
時(shí)間再多一件事情也不可能做的完美,但總有時(shí)間做完一件事情

聽著很耳熟不是嗎,這不就是現(xiàn)在的持續(xù)集成和敏捷開發(fā)么。

康威定律如何指導(dǎo)我們實(shí)踐

  • 我們要用一切手段提升溝通效率,比如slack,github,wiki。能2個(gè)人講清楚的事情,就不要拉更多人,每個(gè)人每個(gè)系統(tǒng)都有明確的分工,出了問題知道馬上找誰,避免踢皮球的問題。
  • 通過MVP的方式來設(shè)計(jì)系統(tǒng),通過不斷的迭代來驗(yàn)證優(yōu)化,系統(tǒng)應(yīng)該是彈性設(shè)計(jì)的。
  • 你想要什么樣的系統(tǒng)設(shè)計(jì),就架構(gòu)什么樣的團(tuán)隊(duì),能扁平化就扁平化。最好按業(yè)務(wù)來劃分團(tuán)隊(duì),這樣能讓團(tuán)隊(duì)自然的自治內(nèi)聚,明確的業(yè)務(wù)邊界會(huì)減少和外部的溝通成本,每個(gè)小團(tuán)隊(duì)都對(duì)自己的模塊的整個(gè)生命周期負(fù)責(zé),沒有邊界不清,沒有無效的扯皮

參考資料

文章內(nèi)容引用

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容