講道理，許多做過代碼屆「接盤俠」的程序員們，某種程度上可能十分理解電影中執着於毀滅世界的反派：「與其在現有基礎上修改，還不如直接把這堆祖傳代碼毀滅再重建！」
祖傳代碼，從字面意思來看，就是一代代老程序員們留下來的「寶藏」代碼——這些長年累月的代碼中存有很多隱患，後來的「接盤俠」們要麼無從下手，要麼一改就崩，幾乎可以說是程序員們的「終極噩夢」，因此也被稱作「屎山代碼」。
這不，最近又有一個「倒霉蛋」火上了 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
《新程序員001-004》全面上市，對話世界級大師，報道中國IT行業創新創造！
留言列表