带老弟做项目，凉了
總結程序員在團隊開發中常犯的問題，千萬注意！
大家好，我是魚皮，還記得我的老弟小阿巴么？
之前，我曝光了這個初學前端的孩子第一次寫后端代碼時出現的囧事：前端老弟第一次寫后端，崩了！
這篇文章發出來后，更多人認識了小阿巴，覺得他是個有趣的編程小辣雞。但小阿巴是一個孤傲有志向的孩子，不想一直在大家面前出笑話。于是，這貨不服氣，又來找我，想跟著我做新項目。
正好，要開發一個新功能，就拉小阿巴一起吧。而且這次，整個大功能交給他全權負責！
沒想到，小阿巴依然很快就完成了開發，興致沖沖地提交了代碼，拉著我來評審。
然而，當我看了他寫的代碼后，我發現，事情并不簡單。
小阿巴真是太牛逼了，一些編程新手在團隊開發中常犯的問題，這貨一個也沒避開，全都踩雷上了。
于是我決定再次曝光他，并且總結了他的問題，希望大家引以為戒。
💣 團隊開發雷區
格局小了
小阿巴寫的代碼中，有很多 “死” 值，比如有好幾個地方用到了同一個機器的 IP 地址：
// 文件 1 getConnectByIp("8.8.8.8");// 文件 2 getLinkByIp("8.8.8.8");// 文件 3 return {ip: "8.8.8.8" }我問他為啥這么寫，他的回答不出所料：就是圖省事兒~
這就跟我們復制粘貼一樣，把重復的代碼粘貼很多遍，寫的時候是挺爽，但萬一后面要修改了呢？要一個個地把所有粘貼的代碼都改掉？
如果都是一個人寫代碼還好，自己可能還記得有哪些重復的代碼，但如果是一個團隊呢？
假如同事 A 寫了一段代碼，同事 B 和同事 C 都復制了他的代碼：
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-kBoD0KcA-1624618795689)(https://qiniuyun.code-nav.cn/image-20210624131905963.png)]
但后來同事 A 發現自己的代碼有 Bug！于是就只修改了代碼 A，然而代碼 B 和代碼 C 依舊存在 Bug。
畢竟大家都喜歡復制代碼的，尤其是在大團隊中，你根本不知道自己的代碼究竟被多少人復制了！一個 Bug 永流傳啊。
所以無論是從可擴展性還是可維護性的角度，盡量少寫 “死” 代碼、少寫重復的代碼，可以將重復的值抽離成獨立的變量、常量或配置文件，將重復的代碼封裝成組件，并編寫文檔和注釋指引他人使用。一般代碼重復 3 次，就可以考慮抽象了，別偷懶，要不然以后更慘。
過于自我
小阿巴在實現 “計算指定日期和當前日期相差的天數” 功能時，新引入了一個依賴庫叫 Day.js 。
但事實上，項目已有日期處理庫 Moment.js ，完全可以輕松地實現上述功能，沒必要再去重復引入一個同類的日期處理庫。
我問小阿巴，為啥要再引入新庫，他的回答不出所料：俺用的熟！
大家可能覺得給項目引入重復依賴庫并沒有什么錯對吧，但是對于團隊項目來說，每個人如果都因為自己的習慣而引入重復庫，可能存在很多問題：
再舉個夸張的例子，三位不同技術棧的前端開發一起來做項目，結果出現了三大框架出現在同一項目的三足鼎立局面：
這種項目的維護難度可想而知。
所以在團隊中，架構師還是很重要的，最好事先給項目定下規矩：項目都給我用這個框架！日期處理都要用這個庫！日志都要用那個庫！
這就是技術選型的問題了，要綜合考慮業務適應性、團隊成員學習成本等。
但無論如何，謹慎給項目引入新依賴，不要一言不合就另辟蹊徑！最好先仔細掃一遍項目現在的依賴，如果已經有能滿足需求的，那直接用豈不美哉？實在要引入新依賴，也最好跟你的合作伙伴一起商量下，萬一出了什么沖突可就不好了~
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-WmFtUPU0-1624618795692)(https://qiniuyun.code-nav.cn/image-20210624152307515.png)]
急不可耐
我看了小阿巴寫的功能，驚訝地發現他根本就理解錯需求了啊！
我讓他擰個螺絲，這貨給我造了個汽車？
// 預期 luoSi = ningLuosi(); // 小阿巴 car = buildCar();連做什么都沒搞清楚，就迫不及待直接上手寫代碼了，這可是大忌，典型的出力不討好。
在企業中，我們作為開發，經常會和產品經理友好交流，要把需求徹底理解了，才能去設計方案，方案設計好才能去寫代碼，在整個過程中一定要和需求方反反復復確認清楚！
我打算再給小阿巴一個機會，這次過了好幾天他才提交了代碼，我一看，這貨真的是擰好螺絲了，只不過。。。
項目里已經有扳手給他擰螺絲，結果這貨自己造了個扳手？
function ningLuosi() {// 預期：一行代碼解決 useBanShou();// 小阿巴，省略 1000 行代碼const tool = buildBanShou();xxxxxxx }這也是新手常犯的問題，不看項目文檔就上手寫代碼，結果有現成的輪子、簡單的寫法不用，非要自己再去造輪子，費事費力。
盲目自信
我感覺小阿巴有一行代碼寫的有問題，于是就本地運行了一下，果然發現了一個 Bug，頁面直接崩潰了！
我把小阿巴叫過來問：你寫完代碼測試了不？你覺得功能有問題不？
他一臉自信地回答：沒測，這功能不就是增刪改查，能有啥問題？
于是我給他演示了一遍 Bug，他瞬間羞紅了臉，啞口無言。
大家想象中好像經驗豐富的程序員寫代碼更快，但事實上，經驗越豐富，他們越會小心謹慎，在寫完代碼后認認真真地測試，而不是盲目相信經驗和直覺。測試也千萬不要只是草草地自己點一遍沒問題就算了，而是要盡量覆蓋所有正常，尤其是 異常 的情況。畢竟用戶不聽話，你無法想象這些家伙能在你的系統中干出什么事！
制造屎山
小阿巴的代碼非常干凈清爽，一個文件千行代碼，一樣注釋都沒有，我把他叫過來給我講講自己的代碼，他竟然都支支吾吾說不出來！
一行注釋沒有也就罷了，代碼還寫的歪歪扭扭，不遵循代碼規范，如果人人都是小阿巴，巨型屎山指日可待。
public static void main( String[] args) {System.out.println("i" + "am" + "shuai");}過眼云煙
通讀一遍小阿巴的代碼，除了上面的問題外，我還發現了很多小的錯誤。
于是我問他：你寫完代碼后，自己會再通讀幾遍呢？
結果這貨竟然害羞極了，支支吾吾地說：沒。。。沒讀過。。。
天啊！還有多少朋友和小阿巴一樣，自己的代碼猶如過眼云煙，寫完就再也不看了呢？
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-gBRnpR0r-1624618795696)(https://qiniuyun.code-nav.cn/image-20210624152508136.png)]
自己寫過的代碼一定要多讀幾遍，就和考試做卷子一樣的，檢查一遍能發現很多問題。而且自學編程的時候，又沒人逼你交卷對吧，還是要花些時間養成好習慣。
我現在寫完代碼至少會讀三遍：寫完一個子功能讀一遍、測試前讀一遍、提交前讀一遍。即便如此，仍然出現過 Bug。
再說了，你自己寫過的代碼自己都不愿意看，還要別人審查的時候來看你的爛代碼，發現問題再給你打回去修改，這不是浪費別人的時間么？久而久之，誰愿意看你的代碼？誰愿意和你合作呢？
此外，即使有別人幫你審查代碼，但有些問題也很難發現，線上出了問題肯定還是你背大鍋。沒有人可以拯救你的 Bug，除了你自己。
敷衍了事
最后這點，就是我之前專門寫文章提到的大部分同學寫代碼的現狀：僅僅滿足于代碼可運行、功能可用，而不注重細節、不做優化。
比如小阿巴的這段代碼：
for(int i = 0; i < maxNum; i++) {doSomething1(); } for(int i = 0; i < maxNum; i++) {doSomething2(); }實際上是可以將兩個同樣的循環進行合并的：
for(int i = 0; i < maxNum; i++) {doSomething1();doSomething2(); }很多同學一直抱怨自己整天增刪改查，項目沒競爭力。但實際上，你在做每個項目的過程中，都有很多進步空間。要仔細挖掘，而不是敷衍了事。
關于這點，大家可以看看我的編程習慣：我寫代碼時的小倔強 。
怎么樣，這些雷你是否也踩過呢？團隊開發可千萬不能像自己寫代碼那樣隨意，希望大家把這些問題熟記于心，做一名優秀的程序員、可靠的隊友。
那么問題來了，后面還要不要帶小阿巴做項目呢？🐶
最后再送大家 幫助我拿到大廠 offer 的學習資源~
跑了，留下 6T 的資源！
我是如何從零開始自學編程，拿到騰訊、字節等大廠 offer 的，可以看這篇文章，不再迷茫！
我學計算機的四年，共勉！
原創不易，如果覺得文章不錯，希望 點贊 支持下 ??
總結
- 上一篇： 多环境设计
- 下一篇： 用RPC OVER HTTPS发布Exc