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

　   英文原文： Greg Jorgensen

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

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

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

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

　　不要用版本控制軟件

　　我經常很驚訝的發現，在過去的幾年里編寫的大型軟件工程竟然不在源代碼版本控制中。如果你不使用版本控制，下一個承接你項目的程序員就沒法確定哪些文件屬于你當前的系統，哪些是淘汰的以及哪些是備份文件，他也無法從提交信息或者修改日志中獲得任何關于代碼的歷史信息。我在我的文章《面向卑鄙的編程介紹 Introduction to Abject-Oriented Programming》中，介紹了“如何不使用版本控制”。

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

　　千萬不要讓承接你項目的程序員輕易的開始工作。開發軟件時，一定要用特殊版本的編程語言、工具，確保它們與一起交付的操作系統有沖突。像瘋子似的定制你的 Eclipse、VisualStudio 或者 vim 環境，然后編寫只能在你定制的環境下才能工作的宏或者腳本。不要制作硬盤鏡像或者腳本以復制你的開發環境，并且不要費勁巴拉寫任何說明文檔——這太直觀啦。

　　創建一個精心制作的構建和部署環境

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

　　程序員可以與簡潔性和優雅作斗爭，然后反過頭構建精心制作的巴洛克式的構建和部署環境。這是一項不受控制的事，程序員可以在不面對客戶的情況下，或者項目經理不審查或者不理解的情況下完成，所以很容易失控。當你把八種不同的工具用不同的腳本語言鏈接起來時，記得不要寫文檔。

　　不要設置測試/分段平臺

　　修改產品系統是很令人興奮地事。不要費勁巴拉的搭建測試/分段平臺，相反要保留秘密登錄入口和后門 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 等工具追蹤代碼、重構、調試，我終究會搞明白你的代碼。如果不使用版本控制軟件、代碼有太多依賴和定制、沒有測試/分層平臺，那些最漂亮優雅的代碼依然非常難搞。這就像在滿是囤積物的房子里，找一個裝飾漂亮、干凈的房間一樣，就算找到了，有啥鳥意思？

　　翻譯： 伯樂在線 - 乾龍   譯文鏈接： http://blog.jobbole.com/50168/