[轉]不要輕言升級

大致想了一下，從進入此行業開始到今天，聽得最多的也許就是“升級”這兩個字了。也參與或經歷了一些稀里糊涂的升級、明明白白的升級、有頭無尾的升級...... 在不斷的升級磨練中知道了一些事情，明白了一些道理。
小小的總結了一下：

1、若非必要，不要輕言升級
很多時候，我們是用一種復雜的心態去看待前任遺留的代碼的，有人自私的一面。我剛參加工作的時候，總以為別人的代碼是垃圾，自己寫出來的才算優美，通常是拿到代碼就重構，然后一通大改，然后用勤奮來應付流言，為此吃了不少的苦頭。當然得承認，經歷了這些之后，對別人的、自己的代碼都會有很深的認識，尤其是架構方面的。但極具諷刺意味的是，若干月或若干年之后，我重新對比閱讀當時的代碼，會發現自己的還不如別人的，尤其是涉及到業務方面的代碼。其實原因很簡單：其一是前任的代碼基本上都經過了運行檢驗的，出錯也只是BUG而已，不會涉及到業務邏輯方面的問題；其二是大部分重構的時間相對會比較緊，由不得你去列計劃，忙中出錯而導致業務邏輯重構不好的話，后果是嚴重的。而這對每個程序員來說都是一個必須經歷的過程，時間長短因人而異。我也在極力盡一個厚道人的本份，對新來的人講述自己的痛苦經歷，灌輸一個道理：不管前任的代碼如何垃圾－－事實上的垃圾也好，假想中的垃圾也罷，若非必要，不要輕言升級。通俗點講，只要湊合能用，就不要去招惹它。

2、升級？你準備好了嗎？
各種編譯器是為新軟件構架準備的，而不是為升級準備的。這是我的觀點。盡管這個觀點遭到很多人的反駁，我依然堅信。

為什么？很多人這么問過我，而且列出了一大堆的理由，最有力的就是：編譯器生產商就號稱向下兼容的哦。坦率的講，我也說不出所以然。的確他們是這樣說的，而且看起來確實也是這么做的。我們給客戶做項目，也動不動就說免費升級，而且作為必不可少的一條寫到了方案書、標書中去了，但實際上～～，好像我還沒有為此而給客戶升級過:-)
來回顧一下硬件歷史，從386到現在的超線程，每次我們“升級”電腦，有幾個能夠真正做到升級？到頭來還不是一換了事？

軟件系統也差不多，至少我經歷過的是差不多的。也許有朋友成功過－－徹底的成功過。可惜我很不幸，從來就沒有這個感覺～

當我把代碼從EVC3.0向4.0向.NET 遷移的時候，是多么的躊躇滿志，多么的意氣風發。全然不把前任的話當一回事：“你準備好了嗎？” 終于，在經歷了一次又一次的類型、地址錯誤之后，我發現，前任比我聰明；我發現，重寫比修改來得更簡單；我又發現，老板根本就沒有給我重寫的時間；我還發現，離我被趕出公司的時間不遠了；于是我開始恨微軟、恨比爾蓋茨、恨老板、恨客戶、恨我自己當初為什么選擇這一行......出來混的，哪能不挨刀，鍵盤鼠標一扔，睡覺去。第二天開始有人出來說，某某某整個一混子，做不出來東東，拉到，難道你說我行我就行，你說我不行我就不行啊，我自己清楚得很。工資是不指望漲了，留也好，走也罷，項目組有的是人，接手的人兒啊，“你準備好了嗎？”
后來接觸了其他公司的編譯器，同樣如此。

現在別人問我：VC6的工程升級到2003、2005怎么升？我會說：別升級，把VC6的改成動態庫，或者啥也不改，就是個EXE，直接調。需要新的功能模塊，再用新的編譯器去寫。去它的風格不統一、去它的邏輯不嚴謹，省時間省力氣的活不干，誰愛升級誰升去，我寧愿出去曬太陽。

3、寫代碼為升級作準備
難道不升級、難道就躲避？當然不行。客戶新需求、市場新動向，逼著我們必須正視這個問題。動態庫是一個好辦法，但有時候不夠用。所以才有程序架構考慮、才有代碼重用考慮。設計的時候，要盡量考慮擴充、升級的問題，有的人喜歡用組件，有的人喜歡用接口。不管怎樣，代碼重用是離程序員最近的，也是最現實的，什么封裝、繼承、耦合......這些專業名詞俺看不懂，我只是極力建議寫導出函數、公用函數、基礎類的，都應該遵循一個潛規則：系統參數，盡量采用局部獨立的原則，把你的函數整塊拷貝出去，換個類名；或者把你的類整個拷貝出去，改動的地方不超過5處就能用的，你YES，否則就NO。曾經見過一個牛人的框架，換了三個不同的系統改幾個定義都能套上去跑得很歡，真正的流水式產品，實在是高，受益匪淺啊。

其實我們平時稍微注意一下也可以做到的，只是沒有養成這樣的習慣而已。至于整體構架則是仁者見仁、智者見智了，這個需要不斷的學習和經驗積累，而且好壞也沒有統一的評判。就拿看得見的來說吧，我一直不喜歡代碼寫得N長的程序員，這是心病，一句就能搞定的，干嗎寫三句？說到這里，順便BS一下不寫注釋的，你以為人家都有時間去琢磨你的代碼和意圖啊。

4、升級項目就是新項目
別不同意。建議你按新項目來，風險、資源、進度、成本、文檔都理一理，做好規劃，該調配的調配，該安排的安排，該溝通的溝通，別到時候手忙腳亂的，又不是你一個人的項目，犯不著你一個人著急，要急也要大家一起急。做事情就不要這樣了，自己累點，把事情都考慮好，列出可能的風險和規避對策、把你手下的人員編號再對一遍，哪個最近在泡MM、那個最近比較躁、那個在鬧工資、哪個準備開溜...... 這些都直接關系到項目是否成功，還有老板的爸爸最近怎么樣，二奶秘書是不是精神旺盛......這些間接關系到項目是否成功，然后的然后，就再問一下自己：必須升級嗎？準備好了嗎？如果你發現原來的代碼50%都移植不成，奉勸你另外設計開發一個替代項目，別跟前任過不去，把他的東西改得亂七八糟的，好好保存就行了。重新開發一個，新項目哦，完成了，找老板，看看，前面的老系統也可以賣，新的你還可以賣得更貴一點，產品線也豐富了，用戶群也多了，這樣多好，給我加薪吧。