如何開發不可維護的軟體？

　　我從別人遺留的的技術性債務中獲得報酬。在我的日常工作中，我見到了很多難以維護的程式碼，並且我一次次地看到了很多相似的並可以避免的問題。

 

　　我專門從事除錯、修改、維護、擴充套件遺留軟體系統這類工作，我的典型客戶一般都有一個或多或少可以執行的網站或者軟體，但是其開發者都因為各種原因不再維護了，因為商業需求改變導致軟體無法跟上需求；或者我的客戶有一些“幾乎快要完成”的軟體，但是因為預算用光或者計劃有變與開發者分道揚鑣。通常這種軟體會缺少一系列的功能並有一坨bug。

　　我那些客戶通常被其他程式設計師告知，需要廢棄已有的所有程式碼從頭開始。大部分程式設計師不喜歡維護程式碼，尤其不喜歡維護別人開發的程式碼。當程式設計師寫程式碼時，當他們談論到可維護性時，程式設計師經常會問一些錯誤的問題——想了解這種情況是如何發生的，請參看Matt Duvall的文章《可維護性的神話 | The myth of maintainability》。

　　以下是一些你可以在你自己的軟體工程中做的“好”事，因為這些事可以幫我找到活幹。

　　不要用版本控制軟體

　　我經常很驚訝的發現，在過去的幾年裡編寫的大型軟體工程竟然不在原始碼版本控制中。如果你不使用版本控制，下一個承接你專案的程式設計師就沒法確定哪些檔案屬於你當前的系統，哪些是淘汰的以及哪些是備份檔案，他也無法從提交資訊或者修改日誌中獲得任何關於程式碼的歷史資訊。我在我的文章《面向卑鄙的程式設計介紹 | Introduction to Abject-Oriented Programming》中，介紹了“如何不使用版本控制”。

　　大量定製你自己的開發環境

　　千萬不要讓承接你專案的程式設計師輕易的開始工作。開發軟體時，一定要用特殊版本的程式語言、工具，確保它們與一起交付的作業系統有衝突。像瘋子似的定製你的Eclipse、VisualStudio或者vim環境，然後編寫只能在你定製的環境下才能工作的巨集或者指令碼。不要製作硬碟映象或者指令碼以複製你的開發環境，並且不要費勁巴拉寫任何說明文件——這太直觀啦。

　建立一個精心製作的構建和部署環境

　　把網站部署到一個測試或者產品伺服器上的方法，應該看起來像這樣：

svn up
git pull
hg pull

　　程式設計師可以與簡潔性和優雅作鬥爭，然後反過頭構建精心製作的巴洛克式的構建和部署環境。這是一項不受控制的事，程式設計師可以在不面對客戶的情況下，或者專案經理不審查或者不理解的情況下完成，所以很容易失控。當你把八種不同的工具用不同的指令碼語言連結起來時，記得不要寫文件。

　　不要設定測試/分段平臺

　　修改產品系統是很令人興奮地事。不要費勁巴拉的搭建測試/分段平臺，相反要保留祕密登入入口和後門URL，以測試新的特性。把測試資料和真正的資料混合起來放到資料庫中，

　　既然你不使用版本控制軟體，儲存軟體舊版本的副本，以防萬一。不要把日誌資訊插入到程式碼中。在測試過程中，不要禁止傳出電子郵件，信用卡授權資訊等等。

　　從頭編寫所有模組

　　不要費勁巴拉使用像Django、Rails或者CakePHP一樣很容易理解的框架，你可以自己寫一個更好的模板引擎，ORM，排序或者雜湊演算法。每當我看到程式碼中諸如”比已有字典演算法要快“或者”替換了PHP庫函式，因為那些函式引數順序太爛了“的註釋時，我都忍不住的想弄死自己。

　　增加對特殊版本的庫和資源的依賴

　　儘可能的加入第三方程式碼，在你需要時連結儘可能多的共享庫。我曾經見過依賴於很大的外部庫檔案只為了使用其中一個函式的程式碼。修改第三方庫檔案原始碼，這樣就可以保證在有新版本出現時，那些第三方庫就不會自動更新，但不要把你修改的版本置於版本控制中，我會用diff命令比對你的版本和最原始版本，並發現其中不同的。

　　……但是不要保護或者編寫依賴性說明文件

　　因為更新和升級錯誤給我打緊急電話的，是所有工作電話中最多的。一個看似無害的WordPress升級，Linux包更新，或者新的jQuery釋出將會引發一系列的錯誤。不要讓你的程式碼自動檢查特定版本或者你修改的外部資源副本或者第三方庫檔案，甚至不要新增註釋以提醒你自己。

　　使用一坨不同的程式語言，跟上潮流

　　每天HackerNews和Reddit都會對一些新又酷的程式語言唧唧歪歪，在你為客戶編寫軟體時就可以試用那些語言。任何牛逼的程式設計師都應該瞬間學會一門程式語言，所以如果繼續承接你程式碼的程式設計師是個菜鳥那不是你的問題。不同語言的邊界、不相容的API和資料格式、不同伺服器配置需要等，都是很有意思的挑戰，把這些貼到SackOverflow秀一下也是怪牛逼的。我確實看到過PHP網頁中嵌入Ruby程式碼，因為每個人都知道PHP爛透了而Ruby好太多。半生不熟的專案，中止的Rails和Node.js專案，尤其是NoSQL解決方案（這個伸縮性更強）都是我的菜。

　　程式設計建議：

　　你的程式碼是否是完美物件導向並閃閃發光的，這沒什麼鳥用。當程式設計師不得不維護一個遺留系統時，他們幾乎總是看到義大利麵條式的程式碼。我很擅長使用diff、grep和ctags等工具追蹤程式碼、重構、除錯，我終究會搞明白你的程式碼。如果不使用版本控制軟體、程式碼有太多依賴和定製、沒有測試/分層平臺，那些最漂亮優雅的程式碼依然非常難搞。這就像在滿是囤積物的房子裡，找一個裝飾漂亮、乾淨的房間一樣，就算找到了，有啥鳥意思？

　　原文連結： Greg Jorgensen   翻譯： 伯樂線上 - 乾龍