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

語言: CN / TW / HK

theme: channing-cyan

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

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

避免破窗效應

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

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

規範許可權管理

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

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

技術氛圍

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

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

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