嘗試create tech team

自從上一家公司以後，我不多有機會去帶一些新人（公司通常都招一些技術獨立性的工程師），特別是經驗不是特別多的新小夥伴。在現在管理扁平化的公司，我正逐漸搭建本身的小team，並試圖讓團隊成員快速融入併成長。整理了一下最近實踐的經驗，我採用的方式以下：

1.文檔化

其實說這個文檔化，至關一部分人是反感或者不屑的，每一個人對這個項目或者一系列接口都是但願有詳盡的文檔，而當須要本身去寫的時候就顯得十分抗拒。可是當項目成員逐漸增長，當項目代碼量和業務複雜度規模逐漸壯大，若是仍是沒有一份靠譜的文檔來支撐，我想新來的研發人員應該會看着龐然大物通常的代碼而笑容逐漸消失。

文檔的好處，沒必要說能更快讓成員有依據的瞭解代碼邏輯，也是對寫文檔的人一次概括總結的提高。固然文檔也不侷限於項目整理或者業務邏輯整理，也能夠是一些工做流、代碼規範相關的約束性的文檔，這對整個項目的規範化和工做協同的一致性有着很是重要的影響。文檔的形式也不只侷限於文字，也能夠是圖表，甚至視頻。

我開始的時候仍是採用儘量文檔化來讓新成員更快了解現有項目，儘可能作到能夠經過文檔獨立（脫離人工引導）去熟悉項目的代碼結構，敲黑板，劃重點，而且留出一些預留的指望任務。對於不一樣的人能夠從同一份文檔理解不一樣層次的要求。對本身無要求或者要求不高的，我只能要求他能順利fix bug，不會由於改動而影響到相關的功能或者代碼塊。對於一些有想法和能力的，我會提一些新的要求，好比去提早熟悉一些功能，試着去優化原有邏輯，甚至改造底層框架。

不一樣的人，不一樣的性格，應該用不一樣的方式去溝通，給予的預設指望也是不一樣的。不以物喜不以己悲，淡然地面對不一樣的人來人往。

我以爲最好看出一我的是否對代碼嚴謹並有編碼能力，就是從現有項目中發現不足且提出本身的想法。例如，我讓w同窗在熟悉項目後，試着去增長中間件支持到框架流程中（以前老項目缺失對中間件良好導入的支持）。也許有人會說，我平時根本就用不着去關心已經搭建好的框架，我只須要每天curd，每天copy paste以前的業務再改改，每天能跑通就得了。這可能就是有的人工做了三年仍是用一年的經驗去作事的緣由吧。

2.代碼規範

其實對於一些非靜態類的自由度高的編程語言，好比:javascript、php等，因爲語言自己的自由度和開發人員的水平不一樣，代碼量和協同開發人數一增長，代碼風格就很難統一，各類各樣的寫法會逐步蔓延到整個項目代碼邏輯中。初期無論，可能只是辣眼睛，後期無論可能拖垮整個相關功能甚至項目。因此在早期的時候就要儘可能規範代碼，一塊兒協商出一個通用性的代碼規範，統一全部人的代碼風格。

代碼規範大體分紅兩大部分，第一部分是代碼格式，第二部分是編程規範。代碼格式php方面有code sniffer，nodejs則能夠用eslint去作強制規範。至於編程規範能夠根據項目以前的風格和一些通用性的規則來約束，好比變量名，函數名的可讀性，通用功能的封裝，面向對象的規範等等。

所謂：沒有規矩，不成方圓。統一的好處在於工程師們能更好地理解代碼，提升工做效率，減小沒必要要的誤解。

 

3.規範工做習慣

 

這個內容認真講起來幾乎和「怎麼成爲一個優秀的工程師」同樣寬泛，我這裏主要是講的解決問題和處理問題方式。好比咱們每每在開發的過程當中會遇到一些讓人長時間阻塞的bug或者業務邏輯，咱們是否老是選擇死磕到底，耗盡deadline也沒有找到確切的解決方案？

我我的的建議是給本身解決一個問題設置一個deadline，能夠是30分鐘，也能夠是一個小時，由本身來定。一旦超過了這個期限，那麼就必須果斷去尋求幫助。有至關一部分工程師會以爲向他人尋求幫助是很羞恥的一件事，然而這一般只是face的問題，尋求外部資源和幫助是一個很是高效的解決途徑。

 

3.屬於本身的團隊反饋

 

作產品或者運營的人是最能理解反饋的重要，一樣的團隊建設裏面隊員們的反饋也是不斷改進的源頭。我採用的是不按期地溝通，隨時跟進各個小夥伴的進度，遇到怎樣的問題，是否須要外部的支持。也會相互作一些頭腦風暴，或者結對編程來解決一些單人侷限思惟的問題。在每週五也會有小組範圍的review會，用來對本週或近階段來總結反思。

人和代碼同樣，若是不定時地去review，也會在不知不覺地滋生一些bad smell。好比某小夥伴狀態不太up，是不是給他/她分配的任務過於繁雜，是不是技術方面有倦怠感。在能力和資源所及的範圍內儘量讓每一個人找到本身所喜歡的事物，能在繁重的工做之餘，也能有一些成長和收穫。

 

目前我還在作更多的嘗試，利用敏捷開發的一些原理，慢慢讓本身和小組一塊兒成長，變得更優秀。