開發小結-團隊管理類

Code Review

Code Review 頗有必要，在Code Review時，要按既定的原則與目標進行，不炫技，不挑刺，找出代碼的缺陷和需求理解不到位的地方，相互學習代碼設計與思路。

要作到對每一個人的每次提交都作嚴格的code review機制，這須要一個強大的制度流程保證和團隊leader的主力推動。不然很難在實際工做中推行。

關於這點，我有一個思路，在每週四下午，進行集中式的code review，抽檢範圍爲上週四至本週四，對提交記錄中隨機挑選3條，先由對應提交者講解，而後你們針對本次提交，提出各自的觀點見解，具體可從如下幾個點來展開：

• 判斷提交類型，是Bug單、需求單仍是優化單？
  • 如果Bug單，則要理清Bug的產生鏈條，修改的思路和影響分析
  • 如果需求單，則須要講解本身對該需求的理解，完成需求的任務分解和基本解決方案。
  • 如果優化單，則要講解優化的動機、具體手法和影響範圍。

其餘同事可對講解者的當前作法提意見，若沒什麼意見，老員工可就業務流程進行一些適當的延伸，無論是技術原理講解，仍是業務規則梳理，均可以。總體時間控制在1小時左右，每一個commit平均分配20~30分鐘便可。

每兩週一次業務分享，能夠是新技術研討，也能夠是現有架構介紹：團隊按期進行新技術的研討，保持對新技術和新業務的敏感度，業務分享須要提早一週肯定分享主題。這個能夠和code review每週交替進行，一個月四周，兩次code review，兩次業務分享。

團隊協做

當使用他人提供的接口或者模塊時，若是現有功能不能知足本身的須要，即便能夠看到他人的具體流程（有源碼的狀況），也不能去貿然去修改，要將改動的動機以及本身的見解經過郵件或者QQ截圖傳達給原做者，讓他去評估是否作修改。回到本身的工做上，能夠本身組合接口基本功能，提供函數來知足本身的需求。

不是全部的Bug的最終走向，都以修復爲結束，對於那些暫時不予修復的Bug，須要和產品、測試溝通肯定後，將結果落在Bug單中，以備查驗。

接收其餘部門發來的設計文檔、接口文檔等原始文檔，必定要歸入本地的版本管理系統。歸入版本管理後，才能走下一步。
必定不能去改動原始文檔，由於一旦有修改，那麼該文檔的有效性就由其餘部門轉給你身上，之後由該文檔的錯誤致使的問題，也會歸責到你身上。若是以爲有必要將分散在各個文檔的零碎信息彙總到一塊兒，那麼，本身應該在本地創建彙總文檔，不要將自用的彙總文檔覆蓋原始的接口文檔。

跨部門的協做，若是別人經過羣發郵件來諮詢問題，當本身知道解決答案時準備回覆，須要羣發回復，讓每個接收者都知道該問題已經獲得解決，以防其餘人浪費精力解決已解決的問題。

在實現功能時，有一些細節地方，在需求文檔裏面沒有明確指示的，在A作法也行，B作法也行的時候，必定要向產品經理提出疑問，等待反饋後，將獲得的反饋到JIRA需求單例去，根據JIRA需求單來作,作到凡是修改要有記錄和可回溯性。

在團隊合做中，做爲基層員工，你只須要對你本身負責的模塊負責。在平時開發工做中發現其餘模塊的壞味道時，不要想着本身發現別人的問題，而後嘗試偷偷地去解決這些問題。這裏犯了大錯，錯在不通知他人的狀況下，擅自改動他人代碼。
本身的貿然改動，修好了，沒有人會知道你的勞動成果，修的很差，一旦發佈後出去問題，層層追責後定位到是此模塊的問題，這就會你帶來沒必要要的麻煩，即使出現的問題不是由於你的修改直接形成的，但因這其中有你的改動，就很差說清楚因果關係，本身曾經犯過這類錯誤，之後必須時刻謹記，謹記。不要自做聰明。好心辦壞事。

從開發者的角度來看待改動，除非改動的影響範圍極其有限，不然是沒法拍胸脯保準本身的修改不會帶來任何問題，就算是增長一行空行，也沒法確保。
對於測試人員來講，開發的任何修改對他們都是黑盒的存在，是不可信的，即便開發說本次改動隻影響某個模塊。在團隊做戰中，自測是對開發人員最爲基本的要求，除了自測以外，還要讓測試人員知道咱們所作的修改影響的模塊或者範圍，不能悶頭作事，本身提交代碼一時爽，測試人員兩行淚。

重構時必定要有邊界，作什麼，在哪裏提交，分幾回提交，在哪裏記錄，在哪裏反饋等等，在這裏，不談具體重構手法，而談談重構的一些注意事項。

當本身發現其餘人代碼（亦或是本身的代碼）中一些壞味道、腐朽的跡象時，內心動了重構的念頭，此時，有三種心態：

心態一：本着多一事不如少一事的原則，發現這些壞味道，只要不影響本身負責的模塊，就不提出。但在本地有記錄，此處能夠如何如何改進，等之後告知相關模塊負責人。

心態二：本着精益求精的原則，也能夠說是程序員潔癖，看到一些不合時宜的代碼，則要對外拋出，主動給本身或其餘人找事作。

心態三：本着投入產出比來講，要看狀況拋出。好比，重構這塊代碼可以帶來顯著的效果，而且本身已有一套重構方案，那就能夠提出，若是這塊代碼不痛不癢，而當前有更重要的工做要去作，那就視而不見。

這三種心態，沒有絕對的對錯，不一樣人有不一樣的見解，執行不一樣的選擇吧了。

這裏面拋出的意思時，把準備要改動的範圍提出，改動帶來的好處和可能的影響也一併提出，至於具體要不要完成，不是重構實施者來決定，而是有團隊小集體來決定。

本身的體會，寫代碼是創造，改代碼是修補，讀代碼是吸取。咱們的大部分時間都花在了讀代碼和改代碼上。產品人員提需求，開發人員提重構，測試人員提Bug。

當發現現有軟件的Bug時，整理清楚問題復現的路徑和環境，告知測試人員，讓他們推送Bug的產生。若是發現問題出如今本身負責的模塊，那麼理所應當要修復它們，這裏不是指的立刻修復，而是將可復現的路徑告知測試，提Bug單後，照單修復。作到在SVN上的每一次提交，都有對應的Bug單、需求單或者重構優化單，這些單纔是開發對接產品、測試和運維的依據。

針對關鍵組件，能夠由老帶新，以結對編程的方式，傳承經驗。

對於重要的修改，能夠用patch的方式先作作code review，確認無誤後再提交。

每一個具體模塊都要有模塊責任人，每一個人對本身的模塊負責，當其餘模塊出問題時，直接告知對應責任人便可。可將每一個人與負責的模塊彙總成表格，給測試或者是其餘團隊成員來查看，方便測試人員快速對接問題的開發人員。

週報管理

在每週的工做總結，不只僅要寫已完成的工做內容，哪些未完成的工做，遇到棘手問題的工做內容更加有記錄價值的。本身針對該問題和哪些人有討論，分析遇到的問題，這是對本身工做的總結。

一項任務進度的描述，不能只有未開始和已完成兩種狀態，在彙報任務進度時，先要將任務分解爲若干子任務，目前已經完成了哪些子任務，還剩下哪些子任務待完成。

在指定年度工做計劃時，我的工做目標須要和團隊（或者說是部門）的目標一致。
好比說，部門目標是註冊用戶量過20W，天天交易量要保證是5億，那麼對於負責交易模塊的同事，要圍繞上述目標來設計。工做內容職責範圍均以此爲依據，對於其餘技能的提升，也要結合當前工做職責來描述，爲了更高效地完成工做任務而學習，不要脫離工做職責範圍而去胡亂學習，切記寫些我的愛好學習之類與工做不相關的內容，這會讓審閱者認爲你在遊手好閒。記住，公司不是請你來學習的，而是要你來解決問題的。

在梳理工做小結時，須要有邏輯條理，不能一上來就寫你完成了什麼功能，還有那些功能沒有完成，讓別人一會兒進入太具體的工做細節描述，很容易繞暈的，很差從更高層次看清你目前工做的全貌。能夠按照總分總的邏輯順序來整理工做內容和工做完成狀況。

放權問題

合理放權是很重要的。通常來講，一我的可在直接高效管理6我的，對每一個團隊成員可以很好管控。隨着團隊規模擴大到12我的，事必躬親就略顯吃力，各個員工管理起來開始困難，當規模快接近20人時，若是管理者還想着天天和20我的都有技術和項目的交流，幾乎是不可能的。因此，管理者要善於發現下屬中是否有職業規劃走技術管理、項目管理的員工，有的話，注意及時給與機會成長，這樣一來，既能夠創建層級梯度團隊，又能夠留下優秀員工，同公司一同成長。

作領導要合理放權，也要用於承擔責任。

在此分享一篇好文章：IT小團隊管理者的突圍之道

技術思惟

技術思惟是總從技術的角度去考慮事情，凡事必追求肯定性，容不得半點含糊，一是一，二是二。而真實世界的事情不是if-else或者 switch-case就能夠解決的，每每存在權衡和取捨。沒有完美的解決方案，只有針對當前場景最適合的解決方案。好比產品經理提出了一個對用戶頗有價值的事情，可是從技術角度上面去實現，會很複雜，這種狀況下，若是技術人員不考慮實際用戶的需求，以實現複雜性或者影響框架等做爲簡化需求的理由，就是典型的技術思惟，而不是產品思惟。技術人轉行作產品經理的，技術是他的優點，若是擺脫不了技術性思惟，那麼將會極大的制約產品的發展。

多向身邊各行各業的人學習，多接觸別的領域，不少時候在你沒接觸以前就貿然說本身不感興趣，來不了之類的話，那只是你在未你的懶惰找藉口而已，只有接觸過，親自嘗試纔有資格說不感興趣。

管理者視角的指望

在工做中，我隱約感受到，若是是從領導者的視角出發，一個聽話、可控的下屬比一個厲害、老是作一些不可控事情的下屬更加可靠。老師喜歡聽話的乖孩子，醫生喜歡配合的病人等等，道理都是相同的。

所以，領導不要求下屬有多厲害，而是要求下屬在領導可控的範圍內，幹明確的、可控的事情。就像都是本領高強的人士，二郎神和孫悟空就表明了兩個極端。可控意味着結果可控，即便結果未如人意，領導也可以承擔下來。最怕那些愣頭青，不清楚影響範圍的改動，會給其餘人員帶來極大的心理負擔。

在平時的工做中，當遇到的問題時，本身要將嘗試的解決方法以及各類方法的解決結果，梳理清楚，若是一兩天仍是無明顯進展，須要及時反饋上級，讓上級知道下屬當前走到的哪一步，碰到的哪些問題。做爲上級，他可以給予哪些幫助和指導，讓他有參與感進來，而不是讓下屬一我的努力完成全部工做。

在職場中，作的多，並不必定意味着作的好，如何有效的彙報本身的成果，是須要反覆斟酌、思考的。要作到能力比薪水高一點點，就要事事超出老闆的期待一點點. 預知或者預設老闆的指望值，而後超越它，這就是向上管理中的重點。

在平時的工做中，除了完成本身本職工做外，也要善於發現現有項目、團隊中一些有待改進的地方，多觀察，多思考，多交流溝通。有一些工做能夠先作一部分，初步整理造成可行方案，準備怎麼作，預計多長時間，影響的範圍有哪些，帶來的好處和壞處有哪些，把這些權衡點一一分析梳理清楚後，在合適的時機向領導提出，若是領導支持，能夠申請資源來協助本身進一步改進完善，若是領導暫時不一樣意，那這個想法暫時按下不表，等待時機。

反思

沒有總結和反思，經歷永遠不能成爲經驗，看別人的總結反思像是在看電影，看的時候很爽，看完一抹黑，能記住的很少。不少坑，非要本身跳進去掙扎一番後，跳出坑後，這些總結反思纔會深刻骨髓，幫助本身之後再也不犯相似的錯誤。

在任何工做中，要想成爲專業人士，必需要掌握一套良好的作事方法和工做習慣，而這些作事方法和工做習慣，一方面經過本身在工做中不斷踩坑、反思、總結，來迭代成長，這樣得到的經驗教訓，每每比較深入。

還有一種是有一個好的導師來帶你，時不時給你的工做上給與指導，指導確定是有依據的，所以，如何提供這些依據，就顯得較爲重要。這裏面有兩個細節：

第一個細節：本身在完成一項任務時，要記錄本身在完成這項任務時遇到的問題，本身嘗試的解決方法以及最後採起的解決方法，將這些工做過程有條理的彙總記錄，做爲導師給與指導的依據。

第二個細節：在向上級彙報時，要主動將工做記錄給上級過目，同時，向上級提出要求，看本身在本次工做過程當中哪些地方有改進的空間和地方。