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就可以解決的，往往存在權衡和取舍。沒有完美的解決方案，只有針對當前場景最適合的解決方案。比如產品經理提出了一個對用戶很有價值的事情，但是從技術角度上面去實現，會很復雜，這種情況下，如果技術人員不考慮實際用戶的需求，以實現復雜性或者影響框架等作為簡化需求的理由，就是典型的技術思維，而不是產品思維。技術人轉行做產品經理的，技術是他的優勢，如果擺脫不了技術性思維，那麽將會極大的制約產品的發展。

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

管理者視角的期望

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

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

在平時的工作中，當遇到的問題時，自己要將嘗試的解決方法以及各種方法的解決結果，梳理清楚，如果一兩天還是無明顯進展，需要及時反饋上級，讓上級知道下屬當前走到的哪一步，碰到的哪些問題。作為上級，他能夠給予哪些幫助和指導，讓他有參與感進來，而不是讓下屬一個人努力完成所有工作。

在職場中，做的多，並不一定意味著做的好，如何有效的匯報自己的成果，是需要反復斟酌、思考的。要做到能力比薪水高一點點，就要事事超出老板的期待一點點. 預知或者預設老板的期望值，然後超越它，這就是向上管理中的重點。

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

反思

沒有總結和反思，經歷永遠不能成為經驗，看別人的總結反思像是在看電影，看的時候很爽，看完一抹黑，能記住的不多。很多坑，非要自己跳進去掙紮一番後，跳出坑後，這些總結反思才會深入骨髓，幫助自己以後不再犯類似的錯誤。

在任何工作中，要想成為專業人士，必須要掌握一套良好的做事方法和工作習慣，而這些做事方法和工作習慣，一方面通過自己在工作中不斷踩坑、反思、總結，來叠代成長，這樣獲得的經驗教訓，往往比較深刻。

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

第一個細節：自己在完成一項任務時，要記錄自己在完成這項任務時遇到的問題，自己嘗試的解決方法以及最後采取的解決方法，將這些工作過程有條理的匯總記錄，作為導師給與指導的依據。

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

開發小結-團隊管理類