程序員小豬隊友行爲大賞

---

Z隊友上線了

最近和搞開發的同窗一塊兒閒聊，正好前段時間你們都經歷過遠程辦公和團隊協做的場景，好像你們都不免有點想吐槽的事情。

所以本篇準備跟你們來分享一下，咱們工做以來所遇到過的一些程序員Z隊友的有趣經歷，固然分享的也是一個本身從Z隊友變成X隊友的成長經歷。

Z隊友哪哪都有，因此說一個好的團隊真的很是重要。

固然說是這麼說，僅僅也是但願在調侃之餘來反思一下本身，由於每一個人都同樣，須要一些好的激勵源和技術氛圍來幫助咱們變得更好，畢竟誰也不是天生就會寫一手好代碼。

---

豬豬1：愛寫爛代碼

有些人會有疑問，做爲一個初學者，就是寫不出好的代碼咋整呢？

其實寫優秀代碼很難嗎？

優秀的代碼，其實不須要複雜！也不須要炫技！更不須要濫用語法糖！

代碼清晰、明瞭、可閱讀、可維護既是第一步，也是最最重要的一步。畢竟代碼是寫給人看的，順便給計算機執行的，你說呢？

那Z隊友常見的爛代碼通常怎麼寫呢？好比：

一、關鍵代碼不加註釋。好像生怕別人看懂了他寫的代碼，而後偷學了他的核心技術似的。程序員原本都這麼艱難了，有必要這樣嘛，是吧。

二、代碼一大坨。一個方法裏巴不得寫幾百行，把接手和維護代碼的人看得死去活來，很是難以維護，這可能就是傳說中的「shi山」吧。

三、喜歡炫技、濫用語法糖、喜歡寫複雜的複合表達式，這一樣也會讓接手者和後來的維護人每天懷疑人生。

四、垃圾命名。要麼命名無心義、不規範、規則混用、有歧義；要麼挖坑式命名，好比命名時用了現有代碼或者庫中已有的名字，可能致使調用者引用出錯。

工做幾年下來我發現，有些人真的特別喜歡延續他上一個項目的代碼風格，也特別喜歡從他曾經作的老項目裏去拷代碼用，並且特別固執，因此那些不太好的風格幾乎一直伴隨着他全部的項目。

雖然說這也能理解，畢竟每一個人的工做背景不同，可是必需要說的是有個好的團隊和項目真的炒雞重要，尤爲是在剛參加工做時。

---

豬豬2：亂改別人的代碼

公司作項目畢竟是團隊協做，共同完成。有時候你們一塊兒寫代碼，功能上不免有重疊，代碼上也不免會有交叉。

比方說，某一個基礎功能的代碼多是你寫的，但Z隊友那邊也會去調用。這時候假如Z隊友那邊有一個需求須要改，或者說要加一個新功能，這時候Z隊友頗有可能會毫無訊息，很是猥瑣地跑來把你寫的基礎代碼給改了，來試圖知足他的需求（而不是去想一些更有擴展性的寫法），並且改了還不跟你說，並且改了還不加註釋，並且進去就是一頓if/else這種sao操做。

這種狀況能夠說很是頭痛，由於假如真出了問題，鍋實際上是別人引入的，最後卻有可能要由你來背！畢竟領導並不知道這些細節問題。

---

豬豬3：挖坑式代碼提交

能夠說這種狀況簡直是巨坑隊友了…

那就是Z隊友在提交代碼時直接把你寫的代碼給抹掉了。

由於公司裏寫代碼必然是團隊協做，代碼你們一塊兒寫，各自去提交。好比如今不少公司用git來管理代碼。

Z隊友最坑的是，他在提交代碼時發現代碼有衝突，這時候他本身可能不會解決，結果一頓sao操做，把本身修改的幾個文件確實提交上去了，可是其餘人以前的修改和提交被他回滾了。

還有一個就是，git有一個很可怕的特性，就是-f參數強制推送，Z隊友愛用這個東西，它會強行用本地倉庫去覆蓋遠端倉庫。致使的後果就是，文件頗有可能被老的內容給覆蓋掉，倉庫的歷史提交記錄丟失等等。

代碼提交時，正常的流程就是先更新，有衝突必定要想辦法解決衝突，再提交，切不可投機倒把哇！

---

豬豬4：亂甩鍋

就像上面第2種狀況說的，好比有些基礎代碼是你寫的，結果被Z隊友給改了，結果改的還有問題，這時候假如真出了問題，你說誰來背鍋呢？

---

豬豬5：團隊協做？

工做幾年下來我發現，其實大部分隊友仍是很友好的，但不免也存在一些團隊協做意識差的隊友。好比我就遇到過那種很是難以交流，或者學東西很是閉塞的人。

學習工做這麼多年，你別說，身邊牛人還真碰到過很多，從碩士讀研待實驗室到校招找工做進入工做崗位，遇到過不少技術很好的人。我廣泛發現真正的技術大牛廣泛有的特色就是：謙虛低調、虛懷若谷、而且交流很輕鬆，因此那些每天不可一世，交流都費勁的隊友抱着一個什麼樣的心態，我其實至今也是不太理解的。

---

共勉

好啦，吐了這麼多，其實想說的就是，咱們每一個人做爲公司和團隊中的個體成員，不少優秀的習慣須要共同去營造和維護。

別人咱們管不了，咱們只能從我的觀念出發，讓本身變得更好！