英文原文：11 Laws of The System Thinking in Software Development

　　“我會更加努力地工作” —— 一匹名叫Boxer的馬（出自喬治·奧威爾的《動物農(nóng)莊》）

　　彼得·圣吉在其著作《第五項(xiàng)修煉》中提到的系統(tǒng)思維定律同樣適用于軟件開發(fā)。

　　1. 今日的問題源于昨日的解決方案（Today’s problems come from yesterday’s solutions）

　　當(dāng)解決問題時(shí)，我們會感到很高興。我們經(jīng)常不考慮后果。令人感到意外的是，我們提出的解決方案可能會產(chǎn)生反作用，并帶來新問題。

• 作為對取得巨大成功的團(tuán)隊(duì)的獎勵，公司決定為團(tuán)隊(duì)中的少數(shù)骨干成員發(fā)放獎金并晉升職位。團(tuán)隊(duì)中的其他成員會感到不公平，并且會喪失積極性。最終使團(tuán)隊(duì)成員之間的關(guān)系更加緊張，后續(xù)項(xiàng)目也就很難再取得成功。

• 項(xiàng)目經(jīng)理頻繁要求開發(fā)者修復(fù)一個(gè)新的軟件Bug，或者處理客戶的緊急需求，而開發(fā)者盡力滿足這些要求。但是，過于頻繁地分散精力會妨礙他們完成迭代過程中的主要任務(wù)。因此，項(xiàng)目進(jìn)展很慢。

　　2. 用力越大，系統(tǒng)的反作用力也越大（The harder you push, the harder the system pushes back）

　　當(dāng)事情的進(jìn)展結(jié)果并非如我們所愿時(shí)，我們會固執(zhí)地堅(jiān)持自己的方法。我們沒有時(shí)間來停下來思維并尋找更好的替代方案，而是“義無反顧”地向前沖。有時(shí)候雖然解決了問題，但往往又發(fā)現(xiàn)深陷于其他問題之中。

• 當(dāng)一個(gè)系統(tǒng)遠(yuǎn)未完成時(shí)，經(jīng)理通常會不斷催促員工加班加點(diǎn)地工作，并且要求按時(shí)完成。系統(tǒng)bug數(shù)量的持續(xù)增加及整體質(zhì)量的急劇下降，導(dǎo)致更多的延誤。因此，需要做更多的工作來部署軟件系統(tǒng)。

• 為了滿足新系統(tǒng)的要求，開發(fā)者勇敢的對原有的系統(tǒng)架構(gòu)進(jìn)行擴(kuò)展，但死板陳舊的方法已經(jīng)不能滿足這些新需求。他們忙于做這件事，以至于沒有時(shí)間停下來仔細(xì)分析并且改變方法，從而導(dǎo)致系統(tǒng)質(zhì)量下降。

　　3. 福兮禍之所伏（Behavior grows better before it grows worse）

　　短期的解決方案，會給我們帶來短暫的休息和狀況的暫時(shí)改善，但是不會從根本上解決問題。這些問題終究會使情況變得更糟。

• 公司為顧客提供豐厚的優(yōu)惠并投入巨資宣傳，讓很多人購買軟件 。但是，顧客購買之后很不滿意，因?yàn)檐浖o法使用也不可靠。

• 管理層承諾，如果開發(fā)團(tuán)隊(duì)能夠按時(shí)完成系統(tǒng)開發(fā)，公司會提供巨額的獎金。一個(gè)團(tuán)隊(duì)開始努力的工作，但很快他們就意識到這是不可能實(shí)現(xiàn)的。于是開發(fā)者變得悲觀并喪失動力。

　　4. 最容易出去的方法往往會導(dǎo)致返回來（The easy way out usually leads back in）

　　在生活中學(xué)到的一些解決方案能夠幫助我們輕易地并且更早的地獲得成功。我們總是試圖把它們強(qiáng)加到任何情形上，而忽略了特殊的背景以及相關(guān)人員。

• 開發(fā)者還沒有準(zhǔn)備好接受結(jié)對編程或者測試驅(qū)動開發(fā)這樣的實(shí)踐時(shí)，敏捷教練強(qiáng)行實(shí)現(xiàn)完全的極限編程。這會給任何敏捷方法帶來壓力、沖突以及負(fù)面影響。

• 開發(fā)者把設(shè)計(jì)模式應(yīng)用到任何地方，這是徒勞的，而且這會讓系統(tǒng)變得復(fù)雜。

　　5. 治療帶來的結(jié)果可能會比疾病導(dǎo)致后果更嚴(yán)重（The cure can be worse than the disease）

　　有些熟知的方法可能會更危險(xiǎn)，比如在編程的時(shí)候喝啤酒，來減輕不切實(shí)際的任務(wù)期限帶來的壓力。

• 由于不信任全職開發(fā)者，一家公司雇傭了大量的承包商來開發(fā)核心功能。結(jié)果，系統(tǒng)不具有概念完整性，自己公司的開發(fā)者看不懂，并且無法做出修改。所以，公司員工也不了解相關(guān)領(lǐng)域的知識、解釋以及概念。

• 開發(fā)者會走捷徑，拷貝相似功能的代碼來趕進(jìn)度，并且爭取盡快發(fā)行第一個(gè)版本。他們一開始進(jìn)展迅速，但是代碼最終會變成大泥球(比喻系統(tǒng)結(jié)構(gòu)不清晰)。

　　6. 欲速則不達(dá)（Faster is slower）

　　當(dāng)我們看到成功的曙光，我們會全力以赴，不再小心謹(jǐn)慎。然而，最優(yōu)增長速率通常會比可能的最快增長速率要慢得多。

• 經(jīng)理們往往為已經(jīng)成功的項(xiàng)目增加很多人手，但總體進(jìn)展就會變慢，因?yàn)榻涣魉玫幕ㄙM(fèi)增加，以及團(tuán)隊(duì)成員之間失去默契。

• 在沒有對代碼進(jìn)行合理重構(gòu)及改善的情況下，開發(fā)者快速的為系統(tǒng)添加新的功能，會使系統(tǒng)變得難懂，而且難以修改。

　　7. 在時(shí)間和空間上，因果并不密切相關(guān)（Cause and effect are not closely related in time and space）

　　我們善于為出現(xiàn)的困難尋找原因，即使這些原因很牽強(qiáng)，并且遠(yuǎn)非是真正的根本原因。

• 為了按時(shí)完成系統(tǒng)，開發(fā)團(tuán)隊(duì)不再接受來自客戶的需求改變。因此，客戶對發(fā)行的軟件不滿意。

• 實(shí)時(shí)系統(tǒng)歷經(jīng)坎坷之后，管理層迫使開發(fā)者同意，并且在給系統(tǒng)做出任何修改之前撰寫詳細(xì)的技術(shù)說明。結(jié)果開發(fā)者失去了為系統(tǒng)做出任何改進(jìn)的動力，并且開始拖延。

　　8. 微小的改變可以產(chǎn)生明顯的效果，但這種杠桿效應(yīng)最大的地方往往也最不明顯（Small changes can produce big results-but the areas of highest leverage are often the least obvious）

　　像改變公司政策、愿景或者廣告用語這樣顯而易見并且關(guān)系重大的解決方案往往不起作用。相反，小而普通，但持續(xù)的改變卻會帶來大不相同的效果。

• 開發(fā)者每天都與客戶進(jìn)行交流，并且做出大部分決定。因此，能夠更好地理解客戶的需求、做出更好的決定并且給出最優(yōu)的解決方案。

• 開發(fā)者為系統(tǒng)的每項(xiàng)功能設(shè)計(jì)自動化單元測試。因此，設(shè)計(jì)更靈活、人們更自信、系統(tǒng)在每此修改之后都能得到完全的測試。

　　9. 魚與熊掌可以兼得，但不是同時(shí)兼得（You can have your cake and eat it too – but not at once）

　　我們經(jīng)常會面對刻板的“非此即彼”選擇。如果我們改變一下自己的觀點(diǎn)及系統(tǒng)規(guī)則，這些選擇有時(shí)并不會使我們進(jìn)退兩難。

• 經(jīng)驗(yàn)豐富的項(xiàng)目經(jīng)理知道增加系統(tǒng)特性的數(shù)量與削減時(shí)間和開支不可兼得。然而，如果我們完善一下想法、尋找合適的人才并且避免過度開發(fā)，這也是可能做到的。

• 開發(fā)者認(rèn)為他們應(yīng)該要么采用事務(wù)腳本，要么采用域模型體系架構(gòu)模式。然而，復(fù)合域中的高性能解決方案可以將兩者結(jié)合，以得到最佳性能。

　　10. 把一頭大象分兩半不會得到兩頭大象（Dividing an elephant in half does not produce two small elephants）

　　無法整體了解系統(tǒng)，往往會做出次優(yōu)決定。

• 項(xiàng)目經(jīng)理往往通過生成的代碼量和迭代過程中實(shí)現(xiàn)的功能數(shù)來評估開發(fā)者。而開發(fā)者往往會生成大量無用代碼。

• 管理層承諾，每發(fā)現(xiàn)一處系統(tǒng)bug，測試者將得到5美元。測試者對跟開發(fā)者合作不再感興趣，并且不再試圖消除產(chǎn)生bug的根本因素。團(tuán)隊(duì)之間良好而且高效的關(guān)系不復(fù)存在。

　　11. 無可非議（There is no blame）

　　我們喜歡歸咎于客觀條件，或?qū)e人指指點(diǎn)點(diǎn)，甚至對此深信不疑。但是，我們自己以及問題的原因都是系統(tǒng)的一部分。

• 今天早上團(tuán)隊(duì)沒有發(fā)布系統(tǒng)完全是喬的過錯(cuò)。即使項(xiàng)目經(jīng)理親切地為其提供了免費(fèi)的啤酒、T恤以及披薩，他也沒能在一晚上的時(shí)間內(nèi)修復(fù)所有的缺陷。

• 人們不會使用一個(gè)公司優(yōu)秀的Web 2.0社會化應(yīng)用，用戶喜歡簡單實(shí)用的東西，并且不會感激你辛勤工作的成果。

　　然后呢？

　　以上11條系統(tǒng)思維定律表明，我們提出的所有解決方案都會產(chǎn)生一定的后果，有時(shí)非常嚴(yán)重并出乎意料。我們周圍的系統(tǒng)本就那樣，我們不應(yīng)苛責(zé)它們，而是要從中學(xué)習(xí)。要掌握系統(tǒng)思維方式并控制這些系統(tǒng)，我們需要做到如下幾點(diǎn)：

　　1. 要明白我們是在跟什么樣的系統(tǒng)打交道，是人或是軟件；

　　2. 有意識地學(xué)習(xí)相互關(guān)系、因果鏈；

　　3. 把系統(tǒng)看做一個(gè)整體，并且視其為其他系統(tǒng)的一部分。

　　系統(tǒng)思維方面有很多挑戰(zhàn)，通過獲取并且利用有關(guān)系統(tǒng)工作方式的知識，我們可以戰(zhàn)勝其中的很多挑戰(zhàn)。但是，大部分嚴(yán)峻挑戰(zhàn)是我們?nèi)祟惻c之相沖突的本性。我們的激情、感情以及本能可以輕易改變我們理智、條理分明的思維方式。掌握系統(tǒng)思維方式的第一步就是要學(xué)習(xí)如何跟自己合作。

　　后話

　　在軟件開發(fā)過程中，你有（或缺乏）哪些系統(tǒng)思維的使用經(jīng)驗(yàn)？

　　編者注：原文作者Andriy Solovey從事軟件開發(fā)已有15年，做過開發(fā)人員、軟件經(jīng)理和系統(tǒng)架構(gòu)師。關(guān)注構(gòu)建優(yōu)質(zhì)、可靠和可用的軟件。　　

　　編譯：伯樂在線 敏捷翻譯 - 朱勇

it知識庫：軟件開發(fā)中的11個(gè)系統(tǒng)思維定律，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。