說實話丟失原始碼之說不太可信,程式碼庫的管理早就版本化中心化了。
我個人看法是這樣的:
1.確定客戶端版本:最簡單的一步。
2.根據客戶端版本確定服務端版本。這一步就很難了,如果公司內部流程在十四五年前不夠完善的話,那麼其實很難知道這個客戶端版本對應的準確服務端版本。國服代理的時候,很大可能在服務端和客戶端也有本地化的修改,中間涉及了轉運營商,而且是在下一個大版本轉的,老的大版本的本地改動記錄和部署關係是否還能追溯存疑。
3.服務端版本依賴的部署環境是否還可用:例如當年是否依賴特定的快取,資料庫,這些依賴的快取資料庫現在還是否可用。是否依賴特定硬體,依賴的硬體還能否正常商業化購買等。上一步的確認考驗十幾年前的上線流程控制和記錄,這一步要確認就充滿了技術上的繁瑣測試了。很多十幾年前是常識的東西現在可能已經廢棄了。
4.安全補丁和架構的對接。這十幾年肯定有發現和修復重大安全問題,賬號架構也遷移到網易戰網而非簡單的使用者名稱密碼加安全卡。這些功能是屬於要從後來的新版本上抽取出來對接到老版本上的。這是完全的架構修改,需要大量開發測試。
所以找到了程式碼給按照十幾年前的方式部署一遍可能不難,但是程式碼裡面的安全問題要修復,程式碼裡面一個大模組要重構,這就是軟體工程上的大問題了。
說實話丟失原始碼之說不太可信,程式碼庫的管理早就版本化中心化了。
我個人看法是這樣的:
1.確定客戶端版本:最簡單的一步。
2.根據客戶端版本確定服務端版本。這一步就很難了,如果公司內部流程在十四五年前不夠完善的話,那麼其實很難知道這個客戶端版本對應的準確服務端版本。國服代理的時候,很大可能在服務端和客戶端也有本地化的修改,中間涉及了轉運營商,而且是在下一個大版本轉的,老的大版本的本地改動記錄和部署關係是否還能追溯存疑。
3.服務端版本依賴的部署環境是否還可用:例如當年是否依賴特定的快取,資料庫,這些依賴的快取資料庫現在還是否可用。是否依賴特定硬體,依賴的硬體還能否正常商業化購買等。上一步的確認考驗十幾年前的上線流程控制和記錄,這一步要確認就充滿了技術上的繁瑣測試了。很多十幾年前是常識的東西現在可能已經廢棄了。
4.安全補丁和架構的對接。這十幾年肯定有發現和修復重大安全問題,賬號架構也遷移到網易戰網而非簡單的使用者名稱密碼加安全卡。這些功能是屬於要從後來的新版本上抽取出來對接到老版本上的。這是完全的架構修改,需要大量開發測試。
所以找到了程式碼給按照十幾年前的方式部署一遍可能不難,但是程式碼裡面的安全問題要修復,程式碼裡面一個大模組要重構,這就是軟體工程上的大問題了。