對團隊規範和技術的幾點總結

theme: channing-cyan

這兩天團隊要做專案總結，所以個人就淺薄的作了幾點總結，當然，是從團隊研發人員的角度去出發，因為團隊的研發人員是基石，是鑄造專案和產品的核心，產品的質量完全由研發人員來決定的，而市場唯一認可的是產品。

可維護，可插拔，可伸縮的程式碼是個人以及團隊可持續良性發展的基石，一個不注重技術，不注重規範的團隊終將被現實狠狠打臉。

避免破窗效應

不做破窗的第一人，在軟體開發過程中，我們一定不要去做破窗的第一人，在一些專案中，由於團隊開發人員迭代了幾批，加上工期緊，所以程式碼可以說不是那麼美觀，導致這個問題的根本原因是從功能的初期就沒有做好規約，團隊成員沒有按照那個規範去執行，後面隨著程式碼的堆積，已經無法重構，程式碼極度耦合，後面的同學想去重構發現工作量很大，風險很大，想要去適配，發現效率又不高，最終，他也只能妥協，在盤根錯節的程式碼中繼續加判斷，所以最後程式碼就變得像印度的電網。

如果團隊成員都嚴格律己，加上相互提醒，監控，沒有人去做破窗的第一人，那麼我們的專案交付時間，專案維護成本等將會縮短很多。

規範許可權管理

一個許可權不規範的團隊暴雷是早晚的事，即使不暴雷，那麼途中一定會遇到大大小小的問題，許可權包括伺服器許可權，資料庫許可權，各種文件許可權和各種中介軟體的訪問許可權等等。應該根據開發人員的職責給他劃分許可權，而不是不管是誰，直接給你root上去，開發，測試，生產伺服器隨便等，資料庫隨便登，這樣是不專業，也是風險很大的操作。

比如資料庫，根據業務來，只給開發人員分配那幾張表的增刪改查等許可權，而不要全部開發，這樣就會避免很多誤操作帶來的損失，再比如各種種中介軟體的許可權，如果管理不到位，那麼會造成嚴重的損失，之前我們就因為nacos的管理不到位而導致配置檔案被刪除，導致服務全不可用，這些都是血淚的教訓。

技術氛圍

特別對於交付型專案來說，說工匠精神可能會比較扯，因為團隊成員水平參差不齊，有熱愛技術的，也有純屬為了生活的，當然，我們每個人都是為了生活，但是我覺得編碼應該有思考，而並非堆上去，實現功能，換句話說，我更願意說，“從繁瑣的生活中刨解出一點理想主義”，寫出美觀，健壯的程式碼是一個過程，這個過程需要不斷學習，不斷總結，而一個人是需要成長的，而在團隊中，我們就要注重技術氛圍，多討論，對成員的程式碼作點評，這樣，不僅讓程式碼整理比較健康，另一方面也培養了成員，對後續的開發打下基礎，另外，一個團隊的技術氛圍會在很在程度上決定這個團隊的穩定性。

上面就列舉了幾個部分來說，也是在團隊中總結出來的，當然，還有很多影響團隊的發展和專案的交付的因素，後續再進行一些總結，當然，因為我的經驗不是很足，在團隊裡面只是一顆螺絲釘，但是我覺得無論是誰，在團隊中都是十分重要的，都應該將自己的能力毫不保留的發揮出來。

今天的分享就到這裡，感謝你的觀看，我們下期見，如果你有什麼想法和點子，我真切的希望你能和我分享，我們一起學習，一起成長！