我靠解決技術債務養家餬口。在我的工作中我看到許多難以維護的程式碼，並且一次又一次地看到很多相同的原本可以避免的問題。
我專長於除錯，修復，維護和擴充套件舊的軟體系統。我的典型的客戶擁有一個尚可執行的網站或內部應用，但是開發者已經不知所蹤。業務需求已經改變了但是軟體沒有跟上。抑或我的客戶有了些“快要完成”的東西但是由於預算和日程安排的關係失去了開發者。通常那包括一系列尚未完成的功能和bug。
我的客戶通常被別的開發者告知需要丟棄所有的東西從頭來過。大多數程式設計師不喜歡維護程式碼，尤其是維護別人的程式碼。當程式設計師寫程式碼的時候他們總是在可維護性上問錯誤的問題——關於這個話題詳見Matt DuVall的文章: The myth of maintainability
我在這裡為你的開發專案提供了一些建議以使我有活可以幹。
不要用版本控制
我總是能驚奇地發現在過去幾年寫的大專案不使用版本控制。如果你不使用版本控制，下一任開發者就要找出哪些檔案是現有系統的一部分以及哪些僅僅是備份。他沒有任何提交資訊和改動日誌來知悉程式碼的歷史。我在我的文章Introduction to Abject-Oriented Programming中講述瞭如何不使用版本控制。
自定義你的開發環境——越多越好
不要讓下一任開發者可以輕鬆地上手。要求特定的開發語言版本和工具，並且確保他們和作業系統自帶的版本有衝突。瘋狂自定義你的Eclipse或VisualStudio或vim，然後寫一些只能在那個配置下執行的巨集和指令碼。不要建立一個磁碟映像或者指令碼來重現你的開發環境，並且不要寫任何文件——那給了太多提示。
建立一個詳細的構建和展開環境
把一個網站投入到正式伺服器應該以下面的形式進行：
|
1 2 3 |
svn up git pull hg pull |
程式設計師可以討論程式碼是否簡潔和優雅，然後他們轉過身去建立最為詳盡和複雜的展開系統。這是他們悄悄乾的，不經過產品經理和客戶的審查，也無法被理解的行為之一，所以它會輕易地失控。當你用不同的指令碼語言把八個工具連線起來時，記得留下文件。
不要建立測試／登入平臺
改變一個產品系統讓人激動。不用麻煩去搭建測試或登入平臺了。取而代之的，用祕密的登入方法或者用些後門URL來測試新特性。把測試資料和真實資料混合在你的資料庫裡。因為你沒有使用版本控制，儲存幾份原先版本的拷貝以防萬一。不要在程式碼里加入登入。不要在測試中關閉郵件傳送，信用卡驗證，等等。
將所有的東西從頭寫過
千萬別用一個像Django, Rails, 或者CakePHP那樣大家都能理解的框架。你可以寫一個更好的引擎，ORM，排序或者雜湊演算法。當我看到一些例如“比原有字典更快的方法”或者“改變了PHP的庫函式因為引數順序爛透了”的註釋時，我就要重置我的大腦。
為特殊的庫和資源加上從屬關係
儘可能多的加入第三方程式碼。連線你需要連線的庫。我見過用了大量的外接庫只為呼叫某個方法的程式碼。改變第三方庫的原始碼這樣它們就無法自動更新，但是千萬不要用版本控制。這樣我就能發現不同的地方從而還原出原來的版本。
但是千萬不要保護這些關係或者為此寫文件
我接到最多的緊急電話和更新出錯有關。一個看上去無害的wordpress升級，Linux更新包，或者新的jQuery版本會造成一系列實效。不要把你的程式碼放到特殊的或者不用的第三方庫版本下檢測。甚至不要加上註釋。
用不同的程式語言並且緊跟潮流
每一天HackerNews和Reddit上湧現出新的酷的語言。在你的客戶的東西上試試它們。任何合格的程式設計師可以在瞬間學會一種新語言，所以你的程式碼的繼任者對其毫不瞭解也不是你的錯。語言的邊界，不相容的API和資料格式，不同的伺服器配置都是有趣的挑戰並且值得在StackOverFlow上貼出來。我真的見過有人把Ruby嵌入PHP網站因為所有人都知道PHP很爛而Ruby更好。半吊子的caching, 流產的Rails和Node.js專案，特別是那些NoSQL方案都是我的好生意。
程式設計建議在哪裡？
你的程式碼是否完美地物件導向，光鮮亮麗都無關緊要——程式設計師在面對舊的系統時總是一團漿糊。我擅長用diff，grep和Ctag, 追蹤程式碼，重構和除錯。我會搞清楚所有的東西。最美麗，優雅的程式碼如果缺少了版本控制，加上太多從屬關係和自定義，並且沒有測試系統的話仍然是很難維護的。這就像在一群強迫性囤積症患者中找到一間乾淨整潔的屋子。