code review 很有必要，在code review時，要按既定的原則與目標進行，不炫技，不挑刺，找出**的缺陷和需求理解不到位的地方，相互學習**設計與思路。
要做到對每個人的每次提交都做嚴格的code review機制，這需要乙個強大的制度流程保證和團隊leader的主力推進。否則很難在實際工作中推行。
關於這點，我有乙個思路，在每週四下午，進行集中式的code review，抽檢範圍為上周四至本周四，對提交記錄中隨機挑選3條，先由對應提交者講解，然後大家針對本次提交，提出各自的觀點看法，具體可從以下幾個點來展開：
其他同事可對講解者的當前做法提意見，若沒什麼意見，老員工可就業務流程進行一些適當的延伸，不管是技術原理講解，還是業務規則梳理，都可以。整體時間控制在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就可以解決的，往往存在權衡和取捨。沒有完美的解決方案，只有針對當前場景最適合的解決方案。比如產品經理提出了乙個對使用者很有價值的事情，但是從技術角度上面去實現，會很複雜，這種情況下，如果技術人員不考慮實際使用者的需求，以實現複雜性或者影響框架等作為簡化需求的理由，就是典型的技術思維，而不是產品思維。技術人轉行做產品經理的，技術是他的優勢，如果擺脫不了技術性思維，那麼將會極大的制約產品的發展。
多向身邊各行各業的人學習，多接觸別的領域，很多時候在你沒接觸之前就貿然說自己不感興趣，來不了之類的話，那只是你在未你的懶惰找藉口而已，只有接觸過，親自嘗試才有資格說不感興趣。
在工作中，我隱約感覺到，如果是從領導者的視角出發，乙個聽話、可控的下屬比乙個厲害、總是做一些不可控事情的下屬更加可靠。老師喜歡聽話的乖孩子，醫生喜歡配合的病人等等，道理都是相同的。
因此，領導不要求下屬有多厲害，而是要求下屬在領導可控的範圍內，幹明確的、可控的事情。就像都是本領高強的人士，二郎神和孫悟空就代表了兩個極端。可控意味著結果可控，即使結果未如人意，領導也能夠承擔下來。最怕那些愣頭青，不清楚影響範圍的改動，會給其他人員帶來極大的心理負擔。
在平時的工作中，當遇到的問題時，自己要將嘗試的解決方法以及各種方法的解決結果，梳理清楚，如果一兩天還是無明顯進展，需要及時反饋上級，讓上級知道下屬當前走到的哪一步，碰到的哪些問題。作為上級，他能夠給予哪些幫助和指導，讓他有參與感進來，而不是讓下屬乙個人努力完成所有工作。
在職場中，做的多，並不一定意味著做的好，如何有效的匯報自己的成果，是需要反覆斟酌、思考的。要做到能力比薪水高一點點，就要事事超出老闆的期待一點點. 預知或者預設老闆的期望值，然後超越它，這就是向上管理中的重點。
在平時的工作中，除了完成自己本職工作外，也要善於發現現有專案、團隊中一些有待改進的地方，多觀察，多思考，多交流溝通。有一些工作可以先做一部分，初步整理形成可行方案，準備怎麼做，預計多長時間，影響的範圍有哪些，帶來的好處和壞處有哪些，把這些權衡點一一分析梳理清楚後，在合適的時機向領導提出，如果領導支援，可以申請資源來協助自己進一步改進完善，如果領導暫時不同意，那這個想法暫時按下不表，等待時機。
沒有總結和反思，經歷永遠不能成為經驗，看別人的總結反思像是在看電影，看的時候很爽，看完一抹黑，能記住的不多。很多坑，非要自己跳進去掙扎一番後，跳出坑後，這些總結反思才會深入骨髓，幫助自己以後不再犯類似的錯誤。
在任何工作中，要想成為專業人士，必須要掌握一套良好的做事方法和工作習慣，而這些做事方法和工作習慣，一方面通過自己在工作中不斷踩坑、反思、總結，來迭代成長，這樣獲得的經驗教訓，往往比較深刻。
還有一種是有乙個好的導師來帶你，時不時給你的工作上給與指導，指導肯定是有依據的，因此，如何提供這些依據，就顯得較為重要。這裡面有兩個細節：
第二個細節：在向上級匯報時，要主動將工作記錄給上級過目，同時，向上級提出要求，看自己在本次工作過程中哪些地方有改進的空間和地方。
開發小結 業務管理類
本篇文章關注於程式設計實踐中的相關流程設計內容，內容 自己過去的工作總結。越複雜流程，越容易出錯。為了減少出錯的情況，需要提取並且封裝通用邏輯，用乙個易於理解的名字來對外提供服務。在業務不同抽象層級上，幹各自職責對應的事情。前後臺互動的流程越多，需要維護的狀態就越多，出現問題的概率就越大，因此在不影...
管理類命令
管理類命令 hostname 顯示主機名稱 uname顯示系統資訊 top 顯示當前系統中耗費資源最多的程序 ps 顯示瞬間的程序狀態 du 顯示指定的檔案 目錄 已使用的磁碟空間的總量 df 顯示檔案系統磁碟空間的使用情況 free 顯示當前記憶體和交換空間的使用情況 ifconfig 顯示網路介...
管理類聯考
管理類聯考 數學 問題求解15題 條件充分性判斷10題，每題3分 共75分 高中 初中 小學數學知識的運用 邏輯推理 30題，每題2分 共60分 形式推理 論證推理 綜合推理 寫作論證有效性分析1題30分 論說文1題35分 共65分 論證有效性分析 較快地找出一段論證中的漏洞 論說文良好的議 寫作能...