前任程式設計師程式碼寫得爛，不要慌！做好這些，輕鬆接手

接手工作怎麼和前任交接

這垃圾程式碼是誰寫的啊？這麼傻X，竟然這麼寫！不考慮效能的嗎？不考慮擴充套件性的嗎？這讓我怎麼改啊！

相信作為程式設計師的你，一定遇到過我說的上述場景，前任程式設計師留下來的程式碼，現在讓你來維護，看不懂，寫的亂，邏輯複雜等等，這是何等的操蛋！還不如重新寫呢！

這個時候不要慌，問題不大！做好下面幾點，輕鬆處理好前任留下來的程式碼。

1、確保有完整的單元測試

想要確保我們寫的程式碼能夠按照預期的業務流程去工作，並且不會影響到其他的功能，唯一的方式就是用測試來檢測你的程式碼。這個時候拿可能會遇到兩種情況

前任給你留下了單元測試，你不必再去寫了，直接拿來看是否能跑得通就行了。

沒有單元測試，那你要負責建立測試，這種情況對你來說其實是比較好的，一方面你可以按照自己的寫法去寫單元測試，另一方面還能夠徹底的瞭解其業務流程

我們在修改前任留下來的程式碼時，要對更改的結果負責，因為無論如何改之前是好的，改完之後就不行了，那肯定是你改的問題了。所以我們要儘可能多地去寫測試以保證我們自己寫的程式碼不會有問題。

2、多與前任程式設計師/同事交流

俗話說“羊毛出在羊身上，解鈴還須繫鈴人”呀！誰寫的程式碼，誰心裡最清楚不過了，不管是對系統架構的把控還是對整體業務的理解，肯定是要比你熟悉的。一般接手別人工作的時候都會有交接文件，負責任的程式設計師都會把該有的業務流程，核心程式碼一一列出來，稍微不負責的，那你接手後只有自求多福了。

有效的和前任程式設計師溝通往往會達到事半功倍的效果，那麼在溝通時我們要明確目標，確定問題點在哪並且說出自己的解決手段讓別人給出意見，比如：

我想做一個某某需求，但是做的過程中發現有某個問題，我想這樣解決，但這樣對其他功能有沒有影響？我應該注意什麼？

我們始終要保持一個謙虛的態度，積極尋求原作者的想法和意見，這樣會避免走很多坑。

3、刪除所有警告和無用程式碼

心理學中有一個“破窗理論”，舉個例子說明一下：

假如一個建築物有幾扇窗戶的玻璃碎掉了，但是沒有人去修，那麼小孩子們可能更傾向於打破更多的玻璃，如果建築物沒有人居住，最終也可能會破門而入到裡面去玩耍；也可以考慮道路上的垃圾，如果路上有一小堆垃圾沒有被及時清理掉，你會發現不久之後就有有更多的垃圾。

這個理論告訴我們如果一個事物沒有人去關心，那麼往後我們都不會去管它了。這是人的本性，寫程式碼也是一樣的，

既然前一個人不在乎這些程式碼，那麼為什麼要在乎？

但是，既然我們接手了這份程式碼，就要對程式碼負責，如果不能使它們正常工作的話，我們就要擔責任。

推薦幾個簡單有效的方法：

刪除模組中的所有警告

刪除未使用，被註釋的程式碼

如果後面要找這些已經刪除的程式碼，透過原始碼管理器就能輕鬆找得到了，這個大可以放心，不會丟失的。

4、重構

重構是什麼？是對軟體的內部結構進行更改，使其更容易理解並且修改起來更方便，而不改變其可觀察的行為。通俗點講，就是我要重新寫，不管你之前寫得有多好或者有多爛，我一律不管了，我重新寫！

每個開發人員寫程式碼的方式和風格都有所不同，一些複雜的業務，差不多把整個模組都改了一遍的需求，倒不如重新寫來得快，如果你有遇到這種情況的話，這個方法可以考慮使用。

5、總結

人無完人，作為開發者也是一樣的，我們接手一個專案時，你就要為這個專案負責，對你寫的每句程式碼負責，所以，

請確保當你離開的時候，程式碼比你發現它的時候更好。

確保下一個接觸我們專案的人不再付出這麼多的代價，說不定將來的某一天，你也會感謝這麼認真負責的你。

歡迎小夥伴們留言評論自己接手專案時發生的趣事吧！