阻礙改善設計的常見觀念

     既然軟件設計如此重要，那麼忽視它就是一種戰略短視行爲。軟件工程師最重要的工做內容理應是進行真正的、創造性的軟件設計，而不是隻忙於簡單地修補漏洞。漏洞是得補，但得補得有藝術、有深度，而不是頭痛冶頭、腳痛冶腳地補。那種沒有深度的修補方式註定是在爲未來埋下更大的×××，也能夠預見將來的軟件維護工做將越發的困難。
     重視軟件設計的首要條件是相關人員（包括軟件工程師、項目管理者等）真正明白什麼是軟件設計，形成忽視軟件設計這種現象的緣由正是相關人員不明白什麼是軟件設計，而不是知道什麼是卻故意不重視它。爲此，作好軟件設計的關鍵要素是人 —— 項目組擁有掌握軟件設計方法和設計思想的軟件工徎師，以及項目團隊是在理解和倡導軟件設計之重要性這類管理者的領導之下。
     軟件開發彷佛老是容易進入混亂狀態，而要從這種混亂狀態中走出，應當經過逐步改善設計的方式，而不應是等待那種一次性的「顛覆性時刻」的到來。之因此出現很多項目安於現狀，受盡煎熬卻無心經過改變走出困境，是由於存在幾種常見的觀念，這些觀念阻礙着項目組去改善設計。

測試能夠成爲替罪羊或測試是救命稻草？
     測試是軟件質量保證很是重要的一個手段，是驗證軟件功能是否與需求相一致的必需方法，可是千萬不能將其看成是軟件質量的惟一保證方法，更不該當讓測試成了軟件缺陷的「替罪羊」或質量的「救命稻草」。
     現實工做中存在這麼一種現象，只要軟件發現了新的缺陷，就有人會指責測試部門「爲何沒有測出這個問題？」。理論上測試部門應當對最終的產品質量負責，由於它們是質量衛士，但實際上要作到這一點並不容易。緣由在於測試部門不管如何努力工做，他們不可能構造出全部的異常測試用例，對於大型系統和分佈式系統更是如此，這也是爲何軟件行業存在「測試只能證實失敗」這種觀點的緣由。提出「別讓測試成了替罪羊」這種觀點的目的不在於爲測試工程師沒有經過測試找出缺陷進行責任開脫，而在於提醒軟件開發工程師應更多地從設計的角度去審視「這種缺陷可否經過設計避免？」，或者思考「是否是如今的設計註定了會出現這麼多的缺陷，真正有效、完全的解決方法應當是從新設計（或稱之爲重構）！」。
     做爲開發軟件工程師，應當明白，若是軟件設計沒有作好，測試工程師也很難單方面保證最終的軟件質量。最終的軟件質量必定來源於開發工程師所作出的優良設計，以及測試工程師別出心裁的測試用例設計。設計沒有作好卻將測試看成「救命稻草」是件很可怕的事，不光項目最終作很差，參與其中的每個人都將揹負沉重的包袱。對於軟件工程師來講，在這種項目上工做極可能是在浪費時間。試想想，一個根基很差的建築，咱們將其裝修得再好也不能說這一建築質量就好，而軟件設計若是建築的根基、測試如同裝修。千萬不要將質量保證的口號變成「測試，測試，再測試！」，而應當是「設計，設計，再測試！」。
     一個設計很糟糕的軟件，開發工程師能夠試着想想，若是本身是一名測試工程師，是否能經過設計出完善的測試用例去保障軟件的最終質量呢？若是本身以爲也不行，那說明只能經過改進設計去嘗試着改變這一問題的答案。

資源永遠不足？
     或許讀者也深深地認同軟件設計的重要性，但必定有人其心裏深出會發出這樣的聲音 —— 「但是咱們沒有這麼多的時間去作設計啊！人員原本就不足！」，這種想法說到底就是提出資源不足。
     對於提出時間不足的讀者，有一點筆者須要提醒的是，請確保你的項目組的確存在具有設計能力的人，不然時間不足不是最爲緊迫的一個緣由。在此姑且假設項目組存在這類人，不然得到這類人應當是項目組的當務之急。
     人的慾望是無限的，但資源倒是有限的。時間是有限的、人員是有限的、開發設備是有限的等等，固然歸根結底都是由於項目資金是有限的。項目也頗有可能由於資源不足的因素而進入混亂狀態，可是走出這些混亂狀態的途徑不該是一味的要求投入更多的資源，而應當考慮在現有資源配置條件下嘗試着「亂中求冶」。進入混亂相信有資源缺少的客觀因素，但也頗有多是人爲形成的（筆者認爲這是絕大多數情形），好比不良設計就會形成軟件項目成爲一個資源「黑洞」，在這種情形下不管投入多少資源可能都是於事無補（推倒重來是一個特例），誰能保證資源投入多了設計就必定好了呢？另忘了資源與行事方式是正交的！若是行事方式不對，投入更多的資源那將意味着更大的浪費。相反，在相同的資源配置條件下，若是每次嘗試着「扣」出一點資源來進行設計改進，時間長了就會出現量變到質變的飛躍，從而有可能最終走出困境。
     對於一個已經投入使用的軟件，當缺陷已讓項目組以爲負擔沉重時，請不要幻想有一天上司對你說「接下來的半年咱們再也不增長新的功能，而是專門改進設計以提升質量」。即便有人說了，那頗有多是指其它的意思，或許想表達「由於咱們的軟件質量太差了，客戶都不肯意用了，只能等質量好一點他們纔再考慮使用」。等到這種時候再去考慮改進設計，團隊的壓力反而大了，爲何不平時多花一點努力去作一些微小的改進呢？在投入更多的資源時必定要確保項目組對資源的使用是正確的，若是隻是簡單地增長時間或人力而在思路或方法上並無改變那頗有可能意味着這種資源的投入是一種盲從。
     資源不足不該成爲阻礙改善設計的永遠藉口，也不該期望對系統進行一次性的顛覆改進。「亂中求冶」的方法其實能有效地控制風險，也給了項目組更大的自由空 間。一件事情若是是在「非作好不可」這種壓力下進行的，那很容易出現「瓦倫達心態」，那結果頗有多是作很差，由於頗有可能瓶頸在於團隊的能力，而能力是 在短時間內沒法得到突破性提高的。而「亂中求冶」的方法不一樣的是，能夠有選擇性地讓能力更強的人去作改進工做，這樣團隊能力的不足與「非作好不可」情形相比 不會太明顯。固然，「亂中求冶」的方法也有必定的反作用。原本資源已不足了還得抽出一些資源來作改進之事，這會讓項目組在短時間內承擔更多的工做量。可是， 這也是考驗項目組的機會。項目組應當清楚地認識到，這種短時間的壓力是有回報的，它意味着項目在朝更好的方向發展，也意味着會擁有一個更好的未來。另外，亂 中求冶能爲項目組提供一種持續鍛鍊能力的機會。如何在混亂中找到問題的根結並經過設計進行解決是很具挑戰性的，每克服一個困難，項目組的能力可能就得到了 必定的提高，並且這類提高將隨着時間的推移產生放大效應。除了軟件設計質量的提升，亂中求冶還能夠幫助打造團隊的文化，一種積極面對混亂的創造性文化。

不改變就能夠規避風險？      另外一種阻礙項目組進行設計改進的思想來源於風險控制意識，具備這種意識的人一般是擔憂由於改變而增長了風險，且擔憂過了頭。      風險與創造性彷佛是一對矛盾，不少組織大力提倡創造性但卻嚴格控制風險。嚴格控制風險意味着很難得到改變的機會，那創造性也頗有可能被扼殺。風險應當有大小之分，若是嚴格控制全部的風險那意味着全部的風險都是同樣的，間接的否定風險有大小之別。控制風險當然重要，但應當有個度，對於小風險的事情應當倡導團隊去嘗試。什麼都不作、不去改變就沒有風險了嗎？處於混亂情況的項目，其風險不會由於不去改變而消失，運用複雜度守恆定律去理解的話，如今不去改變那將意味着未來會有更大的風險。顯然，如今不改變可能短時間不會暴露風險，但從長遠來看必暴無疑。支持不選擇承擔短時間風險的緣由頗有多是「過了兩年之後不知這個項目還作不作」，或者是「管它呢，過了幾年再說，到時也無論個人事了」。      過分的風險意識不少情形是來源於項目管理者，就做者的工做經驗來看，大部分的軟件工程師都敢於去承擔必定的風險，由於那樣的工做對於他們來講才變得有趣且能學到更多的東西，也有很多工程師甚至爲了學習技術而不顧風險的存在。做爲管理者控制風險是對的，只是要注意方法和度。好比，在作設計改進以前是否能夠考慮先引入單元測試的方法以防改出另外一個「噩夢」，等等。必定可控的風險，對於項目組的健康是有益的。別忘了除了控制風險，管理者很重要的一個責任是培養團隊，一個沒有必定風險存在的團隊，其工做必定很無趣，也沒法激發團隊的工做激情和創造力。每一個團隊或多或少都存在能力強的工程師，若是不給他們一點具備風險性的工做（這類工做一般更具挑戰性），那頗有可能留不住這些人。      控制風險的一種有效方法就是運用前面提到的「亂中求冶」的思想，經過不斷的小改進能夠作到讓團隊在必定的風險刺激之下，同時風險也不至於過大。這麼多的好處，爲何不嘗試這種方法呢？反之，若是必定要等到整個組織從上到下都關注意（設計）質量改進，那時壓力必定很大，風險也必定很高，實在是應當避免出現這種讓團隊沒有退路的境況。      最後，管理者擔憂改變的風險頗有多是對團隊的能力不信任，或者團隊的能力真的讓人不信任。但能力是經過改變和犯錯積累的，就這個角度來講，也應當放手讓團隊去作一些小小的嘗試，由於只有這樣團隊的能力纔有可能提升。由於不信任團隊而懼怕改變所帶來的風險，或許是在爲本身製造一個悖論。