今天和師弟聊天聊到他們項目開發(fā)，有些同事總是提前考慮性能優(yōu)化，需求變更又是一大堆的重寫，讓我想起了Donald Knuth 提到的：對軟件的過早地優(yōu)化是萬惡的根源。這里就簡單的說幾條重要的軟件名人哲學(xué)。

1：軟件中唯一不變的就是變化。

在軟件開發(fā)過程中需求是不停的變化，隨著客戶對系統(tǒng)的認(rèn)識，和現(xiàn)有開發(fā)功能和軟件的認(rèn)識，也許以開始他提出的需求就是背離的。記得網(wǎng)上有一句笑話，師說需求變化的：

在設(shè)計和架構(gòu)中，凡事無絕對，作為架構(gòu)師或者項目負(fù)責(zé)人你必須永遠(yuǎn)的清晰認(rèn)識到?jīng)]有完美的架構(gòu)和設(shè)計，沒有萬能的軟件。只存在當(dāng)前環(huán)境，需求方案，團(tuán)隊人員素質(zhì)，物理環(huán)境，安全等綜合因素下的合適方案，由于總總原因你的解決方案可能不是某一個單一因素下的最優(yōu)解。站在這個位置你需要做的是找到這個綜合下的最優(yōu)解，權(quán)衡。不要只從表面說某個人某個團(tuán)隊的解決方案怎么查怎么不好，或者這就是當(dāng)時綜合因素的最優(yōu)解，站在同樣的位置環(huán)境你不一定做得更好。在架構(gòu)設(shè)計和人生，在我看來很相似，總是有一堆抉擇，每一次的抉擇都會帶來得和失，權(quán)衡得失取舍。

2:KISS:(Keep It Simple,Stupid):

保持簡單，但不過于太簡單。在《UNIX下的編程哲學(xué)》中提到很多保持設(shè)計簡單，我們能清晰看到這條原則?，F(xiàn)在視覺設(shè)計，都崇尚簡約設(shè)計，簡單而不庸俗，而不是一大堆的豪華奢侈打造。VB編程開始的可視化設(shè)計，可見即可得，google的首頁，商業(yè)風(fēng)格。在我們的軟件設(shè)計中也需要簡潔的設(shè)計，用戶需要的是可見可量化的功能的正確性，而是你運用了多牛b的技術(shù)模式，但絕不是一味的太過于簡單。你想把意見簡單的事情做復(fù)雜化是很容易的事情，但是把一件復(fù)雜的事情簡單化卻不那么容易。簡單的人生就是幸福。但是這里需要說明的是簡單是優(yōu)秀的，但簡單是有底線邊界的，超過底線的簡單也有變得稚幼。比如事務(wù)性腳本模式比其他3中常見模式都簡單，但往往復(fù)雜的需求它不是最優(yōu)解，因為他太過于簡單了（如果你還不了解是事務(wù)性腳本可以參見這里架構(gòu)設(shè)計-業(yè)務(wù)邏輯層簡述）。

3：面向抽象編程。

在設(shè)計模式，架構(gòu)模式，OO中都是一條完全的主線，作為oo第一原則存在。我不起那個軟件牛人曾說過：請牢記沒有接口的話就不要開始實現(xiàn)。這句話也許過于偏激，但是如果你接口理解為不變或者不易變的話，理解或契約（公司和你的合同）更貼切些吧（可能是一個不變的類，如果你能肯定的說出你的這個實現(xiàn)在以后，在項目開發(fā)維護(hù)中是不會變得，我覺得這也是接口，接口在于不變和不易變），你也許會同意這句話。對于目前的需求你肯定能夠沒有抽象沒夠接口完全寫出完美的代碼，但是第一條中我們說明的軟件中唯一不變的就是變化，在未來的需求中你能夠很好的一樣的優(yōu)秀嗎？如果不能，那么我認(rèn)為面對當(dāng)前需求就該為以后提供擴(kuò)展延伸。

我個人理解23中設(shè)計模式中大多數(shù)基本都是圍繞著這個Program to an interface, not an implementation（依賴接口而不是實現(xiàn)）第一原則為目的。當(dāng)然我們也不能不說還有第二原則：組合優(yōu)先于繼承。以后的什么DIP（依賴倒置，IOC的原則），LSP（里氏替換），OCP（開閉原則）等等都是他們的延伸和擴(kuò)展。在追溯的話這一些列都是為了軟件系統(tǒng)“高內(nèi)聚，低耦合”（可以簡敘述為：功能完備(高內(nèi)聚)的對象之間是靠接口(低耦合)通訊交互的），內(nèi)聚是描述的功能性完備程度，耦合是表述模塊間的依賴程度。這里插一句話某同事給我說依賴接口不是還有依賴嘛，我希望的是沒有耦合，我的回答是：計算機(jī)二八原則說明了這一切，既然事務(wù)出現(xiàn)在一起了，那絕不是偶然情況，所以他們之間必定存在依賴，在軟件設(shè)計中我們所能做的就是引入中間對象使其變?yōu)殚g接依賴，而減少他們之間的依賴，而我們希望這個中間對象是個相對穩(wěn)定的，設(shè)計中一切都是一個詞：間接，分層，mvc，mvp，soa，中間件等等都是體現(xiàn)直接依賴變?yōu)殚g接依賴。說這個話題的原因是引出我們“高內(nèi)聚，低耦合”行之有效的方法SOC（分離關(guān)注點），這不只是OO的任然對面向過程編程行之有效，他是在20年前 SP（結(jié)構(gòu)化編程）中提出來的。

如果你想對設(shè)計原則有更多的了解，可以參見這里面向設(shè)計原則理解和一些軟件設(shè)計的原則。

4：首先考慮可維護(hù)，延伸性，事后優(yōu)化

這里也是本文的起因，正如開篇所說，Donald Knuth 提到的：對軟件的過早地優(yōu)化是萬惡的根源。在開發(fā)的時候我們不需要進(jìn)行任何性能的優(yōu)化，即使你認(rèn)為這里可能存在性能的瓶頸，你需要考慮的更多的是設(shè)計的擴(kuò)展和延伸性，以后的繼續(xù)添加新功能和維護(hù)。對于用戶需話要的需求，性能優(yōu)化很多時候只是作為一個更好的體驗存在。只有當(dāng)真正出現(xiàn)性能瓶頸的時候，你才需要做性能的優(yōu)化。一個可延伸可擴(kuò)展，層次分明，代碼清晰的模塊，對于你的優(yōu)化也是件容易的事情，在對項目后期對于項目的總體需求明白下你也有得到更多的優(yōu)化方案。在重構(gòu)模式中同樣也提倡時候優(yōu)化。過早的優(yōu)化導(dǎo)致你的項目會越陷越深，到最后才知道用戶其實根本不需要這么高的需求，或者是用戶根本不常用的功能模塊。優(yōu)化也需要有標(biāo)準(zhǔn)，多少時間是用戶能忍受的，目前是多少時間。往往用戶對性能要求的只有那個少量常用的操作，而對于功能性需求的變更卻是無止境的，維護(hù)成本卻是高昂的。

最后說一句，經(jīng)常有人說反射性能低下，對我們必須承認(rèn)反射比其他方案性能是不好，但是我們有解決方案：緩存。在則說性能低下，是以什么什么標(biāo)準(zhǔn)？用戶的接受程度？反射我們可以有其替代方案Emit，Expression tree。從反射，Expression tree，Emit的選擇，其使用難度在提升，開發(fā)效率在增加，性能在改善。本人一般卻傾向于Expression tree，兩種劇中吧。

5：繼承是為了多態(tài)而不是重用

OOP中可以編寫一個類，然后我可以不斷的繼承重用去擴(kuò)展新需求。這是類的重用，是全部的重用？重用這個詞看上去也許更加的微妙。多態(tài)是面向?qū)ο蟮暮诵奶卣髦?，也不記不清那里聽到的：重用只是繼承的附帶功能。在我們的繼承體系中不宜龐大如果一個擁有4,5層的繼承體系，對你的理解也增加難度，而且集成體系必須是個干凈的繼承體系，滿足LSP（里氏替換原則）：在所有用到父類的地方都可以替換為子類，還能正常準(zhǔn)確工作。這就要求你繼承更多的是修改擴(kuò)展父類的行為，盡量避免狀態(tài)。繼承只是不要為了重用的為目的，在恰當(dāng)?shù)臅r機(jī)更好的辦法是實現(xiàn)一個完全的類來替換不能滿足現(xiàn)有需求的類。這也是oo原則第二原則吧，組合優(yōu)先于繼承。組合比如設(shè)計模式中的策略模式，你得到的是一個算法組合功能個數(shù)是一個笛卡爾積。但也是絕對的組合，只是優(yōu)先，不是取代，軟件和現(xiàn)實世界都是充滿了矛盾的，就如開篇第一條“軟件中唯一不變的就是變化”就是最大的矛盾，來自辯證唯物主義，你要做的是權(quán)衡。組合表述的是整體的替換，如策略模式模式的算法整體替換。繼承是部分的少量的擴(kuò)展修改行為，比如設(shè)計模式中的模版方案，在父類的流程控制下，部分步驟的修改，數(shù)據(jù)，事務(wù)的流轉(zhuǎn)控制權(quán)在父類。這條在最后說一句：設(shè)計模式不是萬能的，只是前人的優(yōu)秀經(jīng)驗，是依賴于場景存在的，了解設(shè)計模式我覺得更重要的是其使用場景，在遇見同類場景的時候知道可以有這種模式作為解決方案或許更好，僅作為供你選擇的解決問題方案。

6：用戶的一切輸入都是萬惡的

用戶的輸入是屬于我們系統(tǒng)之外的，是無法控制的，是不可羅列的。對于用戶來說軟件只是一個黑盒子，不需要，也沒必要了解具體內(nèi)在實現(xiàn)。對于汽車銷售人員不需要了解發(fā)動機(jī)螺栓是怎么上的一樣，他了解宣傳的是能有什么優(yōu)勢，能給用戶帶來那些方面的滿足，價格？性能？速度？豪華？….對于門戶網(wǎng)站來說你對應(yīng)的用戶不僅是可信任的用戶，可能還有競爭對手黑客攻擊行為。如果你的系統(tǒng)信任于用戶的輸入，早晚一天總會“紙包不住火的”，用戶有意無意的一次輸入就可能導(dǎo)致你系統(tǒng)的功能性的全盤崩潰，你不應(yīng)該限制用戶的操作，你是不能命令用戶該輸入什么不能輸入什么，比如某天某人使用用戶可能降工資了或者挨批了，心情不好，你也許會潛意思的對你的系統(tǒng)進(jìn)行挑戰(zhàn)。

說到這里隨便說一句，以前項目組有人層提過由于自動化測試服務(wù)器運行時間太長了，把部分驗證等邏輯移到單元測試中保證。對于我的理解來說自動化測試近似于集成測試吧，功能性測試，應(yīng)該是黑盒子。在單元測試中我們總是假設(shè)輸入是正確的，某個依賴也是正確的，驗證輸出的正確。而集成測試重點在于這一些都是層次的組合，貫通，不存在假設(shè)的正確性，只有來自測試人員的測試用例得到預(yù)期的輸出。

今天就寫到這里吧，還有很多但是一下想不起來，后續(xù)有機(jī)會的話對于重要的也會繼續(xù)補上。

現(xiàn)實是矛盾的，沒有完美的設(shè)計，也沒有絕對的簡單。生活也是如此就如：簡單就是幸福，快樂就是幸福。那么簡單的標(biāo)準(zhǔn)是什么？怎樣才是快樂？這在于你自己的抉擇，權(quán)衡。想起了某次面試和小公司面試官談話，面試官說ORM存在性能問題，而且一直在糾結(jié)的說反對DDD，反對模式。本人先說了如果存在了性能問題有什么解決方案，首先怎么做如果不能滿足再怎么做，從索引緩存到分表服務(wù)集群，再總結(jié)性的一句話：架構(gòu)如人生，總是要面臨得到取舍。

原文鏈接：http://www.cnblogs.com/whitewolf/archive/2012/06/02/2532244.html