之所以存在軟體噩夢，是因為軟體需要改進和維護，這是軟體生命週期的一部分，正如人類的生老病死一樣，即使你不喜歡，但是他依然會來臨，它不會因為你不喜歡或者抗拒而不來。你所能做的，正如當下流行的一種說法，如果你無法反抗，就學會享受。
這正如我在團隊中所倡導的一樣，很多問題，之所以不能解決或者是不能很好的解決，是因為從一開始我們就沒有承認這個問題。那麼解決問題的第一步就是先承認問題的存在，存在即合理雖然大家都會說，但是很少有人會仔細的去思考，尤其是在工程專案之中。我常常聽到的一句話就是「這不可能」。還有往往也有那樣的抱怨「使用者老變」，「這是人的問題」等等這些抱怨，這些抱怨的背後都存在乙個問題，即問題解決者對於問題的否定，也就是說他們承認了一部分問題而對另一部分問題的不承認。比如「使用者老變」這種抱怨，首先最嚴重的問題在於，他們從來不承認使用者變化這種情況，所以不能很好的去追求問題本源，不能去提前制定預案，所以當問題出現的時候，就會出現那種抱怨。
還有一種非常常見的情況就是「這是人的問題」的這種抱怨。尤其是當問題出現的時候，開發人員通常會說這是使用者操作的問題。當開發人員因為粗心而呼叫
api錯誤的時候，這時候大家也都會覺得是呼叫者的問題（其實很多時候是
api開發者沒有做好介面的「使用者互動」），尤其是很多技術人員這樣去思考。這種普遍的情況使得技術和人被本末倒置了。這種情況我遇到最多的有兩處，一處是使用者介面，一處是介面呼叫
,也就是前面所舉的兩個例子。
既然軟體存在問題，那麼如何面對這種問題？是面對還是逃避。有時候你可以逃避，但更多的時候你必須去面對他。這又得重申一下我的理念了，對於任何問題，你只有承認它的存在，才能解決它。
既然軟體存在問題了，那麼做改進還是不改進，你肯定會說，必須做改進啊。錯了，在真正的遇到的問題的時候，很多人不做改進。一般情況下當事人會覺得改進的影響和成本都高於修修補補。所以問題就這樣被不斷的放縱下去，終有一天無法修補了或者運氣好點沒有到這一天軟體就已經廢棄了。當然了，也不是說遇到問題了二話不說就去做改進，這種做法也不提倡。
對於是否要做大的改進，應該從幾個方面來判斷。
1、是否和設計相關，如果出現問題了，發現修補不能從根本上解決問題，那麼看看是不是設計方面的問題，如果是設計上面的問題，那麼就需要考慮去改進。採用鴕鳥演算法
(參考文獻
[19])
來逃避只會給以後帶來更大的麻煩。
2、是否是核心，發現的問題是核心方面的問題，這個核心方面不管是業務還是技術，如果這塊存在問題，那麼一定是要改進的，因為核心是一直存在的，一時的搪塞只不過是給自己埋地雷而已。
3、是否是以後擴充套件的瓶頸，這個很明顯，如果問題處於敏感地帶，有非常大的可能性是以後擴充套件的阻礙，那麼就毫不猶豫的去改進和重構。當然了是不是以後擴充套件的瓶頸這個不是很容易能看出來，對系統熟悉或者有了一定經驗之後還是不難看出來的。重要的地方在於要有這個意識，這樣不久之後就有這個能力了。
4、是否有敢於承擔改進的人，這一條看似廢話的標準其實不是廢話，真正在考慮是重構還是修補一下就完事的時候，往往會有各種利益方和不同人員之間的
pk和協調，畢竟人都有自己的想法，有想混到下班完事的，有技術狂熱到不考慮產品利益後果的，所以是否需要改進還得有乙個冷靜並且勇於拍板的人。
部落格位址
軟開心法十五 軟體內功
什麼是內功？內功和招式有什麼區別？我覺得這個區別我不用多說了，估計沒有人不知道武功的內功和具體招式之間的差距，哪個是需要終極修煉的一目了然。軟體的內功又是什麼東西呢？那麼招式又是什麼東西呢？一句話 具體的實現技術是招式，心中的實現思想是內功。最明顯的招式屬於各種語言，內功屬於使用語言實現的想法和步驟...
軟考又見軟考
我這地兒 報名截止時間都快到了，3月4日，我才知道開始報名了。大三了，課程少了些。一直想考這個證來著，無奈時間太緊要不就是專業課還沒學。現在已經定下要考本專業研了，方向嘛 唉也說不准，大家都知道這個證是其次的搞技術的話還是能力問題，我的想法考這個是為了梳理專業知識，以備研究生專業課的考試 以後很可能...
軟考 軟考之路
面對軟考你是怎樣的心境呢？從最開始我拿到軟考書開始，感覺好厚呀，還有三門自考，這是要把自己置於何地了呢？但是翻開書本，看到那熟悉的知識，很多都是自考中的知識，這個時候是不是該悔恨當初沒有好好學習自考了呢？一 三遍讀書法 一本書從開始讀，到每一遍的不斷閱讀將書本讀薄，將知識理解，每一遍都是不可缺少的一...