整理 | 鄭麗媛
講道理，許多做過程式碼屆「接盤俠」的程式設計師們，某種程度上可能十分理解電影中執著於毀滅世界的反派：「與其在現有基礎上修改，還不如直接把這堆祖傳程式碼毀滅再重建！」
祖傳程式碼，從字面意思來看，就是一代代老程式設計師們留下來的「寶藏」程式碼——這些長年累月的程式碼中存有很多隱患，後來的「接盤俠」們要麼無從下手，要麼一改就崩，幾乎可以說是程式設計師們的「終極噩夢」，因此也被稱作「屎山程式碼」。
這不，最近又有一個「倒楣蛋」火上了 HN 熱榜：「我繼承了我見過的最差的程式碼和技術團隊，該怎麼辦？」
擁有 12 年曆史、沒有版本控制的「祖傳程式碼」
從這位「接盤俠」 @whattodochange 闡述的現狀來看，他這次繼承的程式碼歷史長達 12 年，是沒有版本控制的 PHP 程式碼，居然每年還能產生超過 2000 萬美元（約 1.4 億元）的收入：
這些程式碼每年能產生超過 2000 萬美元的收入。
運行在 PHP 上。
已經在生產環境直接開發了 12 年，沒有源程式碼控制（都是像 index-new_2021-test-john_v2.php 這種）。
沒有使用 composer 或任何依賴管理，都是 require_once。
沒使用任何框架。
路由管理完全是在 NGInX 中重寫的（NGInX 的配置大約是 10000 行）。
這些年只在不斷往上堆程式碼，沒刪除任何程式碼（我推測這是因為程式碼是直接在生產環境開發的，刪東西太危險了）。
資料庫結構也是一片混亂，沒有遷移等等。要添加一個列時，由於資料量大，他們一般會建一個新表，然後用 join。
JS 和 CSS 也是如此。jQuery 的不同版本互相打架，具體取決於你在哪個頁面，有時甚至同一個頁面也會有。
當然沒有 MVC 模式或其他模式什麼的，沒有模板庫。這是 PHP 2003 的樣式。
在很多地方，我看到像是 Controller 一樣的檔案，向它自己的 rest API 發出 curl 請求（通過域名而非 localhost）進行 oauth 授權等…然後只是為了獲取菜單項或產品列表。
沒有快取（但有 memcached ，但只用於 Session…)。
團隊只有 3 個很年輕的人，一個後端，一個前端，一個 iOS/android ，他們對程式碼變革非常牴觸。
生產力很差，這可以理解——亂七八糟的東西實在是太多了，根本沒辦法做新東西。
以上就是 @whattodochange 目前所接盤的程式碼和團隊現狀，他頭疼道：「我必須要找到一個策略來修復這個開發團隊。」
面對這個「爛攤子」，@whattodochange 想到的解決辦法是完全重寫，但由於公司管理層和總部對這些阻礙因素並沒有真正了解，業務部門對這個項目有非常積極的規劃路線，且疫情之下公司的預算很緊張，導致 @whattodochange 根本無法推進。
因此，@whattodochange 發帖求助：「我知道完全重寫是必要的，但要如何平衡？」
逐一改動 or 擺爛跑路？
對於 @whattodochange 的遭遇，不少有經驗的程式設計師深有同感，也提出了一些應對「祖傳程式碼」的具體建議。
「完全重寫不是必需的，甚至可能是最糟糕的方法。可以一次做一件事，最終你會重寫所有程式碼，但永遠不會陷入‘完全重寫’的陷阱中。
不過在重寫一行程式碼之前，記得要做大量的測試。如果有端到端測試，這些測試運行在客戶群當前使用的每個功能中，那麼您就有一個基線來安全地進行更改。只要測試通過，就可以刪除程式碼。
不要想著去推動變革，嘗試擁抱這個每年賺 2000 萬美元的可怕程式碼庫，和團隊討論討論如何在能力範圍內改進即可。」
作為這個開發團隊的經理，你的任務是要得到高管支持來逐漸解決這個爛攤子。你沒必要告訴高管或團隊具體要如何修復，只要有時間和空間上的支持就好。
有一種辦法是每週五集合團隊一起來測試，但可能會經常被緊急任務擠掉；另一種辦法是讓每個更新的發佈速度稍慢一些，這樣就有時間最佳化每次更新所涉及到的其他程式碼。例如，業務要求添加功能 X，那麼你就給相關的現有功能 Y 添加一個測試，可以對團隊說最佳化 Y 是為了讓添加 X 更為方便。」
不過，也有部分程式設計師在了解 @whattodochange 的現狀後，認為「擺爛跑路」是最優解：
「你應該考慮辭職。雖然你知道這程式碼很爛，但它確實能帶來每年 2000 萬美元的收入，所以你的團隊不想變革，業務人員也不會關心程式碼質量。他們會認為：反正 2003 年樣式的 PHP 程式碼就可以實現這個收入，那不挺好，幹嘛要浪費財力和精力去重寫？
最後，你很難說服你的開發團隊和業務部門同意重寫這個決定，甚至還會招來仇視，而你自己也會討厭這樣的工作氛圍。」
「為了避免自己受傷，我勸你擺脫這種混亂的處境。我之前也一直處於類似的情況，花了快五年的時間試圖解決，但最後還是心累地放棄了。」
血淚教訓：「人跟程式碼有一個能跑就行了」
其實在現實中，幾乎所有軟體開發公司都有各種老大難的「祖傳程式碼」，像 @whattodochange 遇到這種 12 年曆史的都還算年輕的了——一般越大規模越厲害的公司，「屎山」程式碼的情況越嚴重。
《GTA 5》聯機版中循環 19.8 億次的 if 語句，被許多人稱作遊戲開發史上最大的「屎山」程式碼，存在了 7 年 R 星（遊戲開發商 RockStar）的程式設計師無人敢動。最終，還是一位駭客大哥看不下去給出了解決方案，R 星這才官宣要修復 bug，並給這位駭客獎勵了 1 萬美元。
一位亞馬遜工程師也曾形容他們公司的程式碼為：「一座很大的屎山，一座你見過的最大的山，每次你想修正一個 bug，都得爬到屎山的正中央去。」
類似地，國內也有許多程式設計師分享過他們遇到的各種「骨灰級」祖傳程式碼：
「公司程式碼已經 40 年了，最早寫程式碼的人不知道是否活著，要命的是文件沒留下，項目程式碼堆在一起能有 90 多 G。」
「我要升級的那批程式碼寫於 2000 年前，最早的部分可能寫於 1980 年代貝爾實驗室。第一批維護升級做需求的人早就退休了，第二批也退休了，每一行程式碼動起來都膽戰心驚。」
「曾經在 Visa 工作過，感覺什麼 10 年 20 年的程式碼簡直 naive，你見過 1965 年的程式碼嗎？第一次看到簡直驚呆了，這半個世紀的程式碼現在還在用還跑的好好的？」
可能對於很多剛工作的萌新程式設計師來說，看見這些各處都埋著「地雷」的程式碼第一反應就是「推倒重來」，但大多都得到了血淚教訓：「有的時候，程式碼能運行就不要嘗試去改，哪怕是遇到屎山一樣的程式碼」，可能還會對新人建議道：「人跟程式碼有一個能跑就行了。」
那麼，你是否在工作中遇見過令人髮指的「祖傳程式碼」，最長擁有多少年曆史？你是選擇逐一改動還是放任不管？
參考連結：
https://news.ycombinator.com/item?id=32883596
https://www.zhihu.com/question/272065178
