程序員的三門課：技術精進、架構修煉、管理探祕

程序員不僅需要寫好代碼，還需要合理規劃自己的職業發展路徑。本書以作者多年的實踐經驗總結爲基礎，從程序員的技能、成長、學習、進階，到架構和管理等的成長週期做了深入分析，不僅講到如何寫出具有專業水準的代碼，還講到如何快速成長，以及如何轉型架構和技術管理。

今天很滿足，讀了兩本貨真價實的書!感謝作者的學識與寫作分享。 程序員不僅需要寫好代碼，還需要合理規劃自己的職業發展路徑。本書以作者多年的實踐經驗總結爲基礎，從程序員的技能、成長、學習、進階，到架構和管理等的成長週期做了深入分析，不僅講到如何寫出具有專業水準的代碼，還講到如何快速成長，以及如何轉型架構和技術管理。本書可以作爲初、中、高級程序員及架構師、技術管理者的參考用書，相信能夠讓讀者受益匪淺。

書名不錯，程序員的三層進階。也是很好的指引。 第一部分和第二部分還是比較偏重於術。無論你是同道程序員還是非同道，都可以快速閱讀，甚至瀏覽和跳讀，都不影響。它的層層遞進的整體觀思路值得學習和領悟，甚至從自己的工作中也找到這種遞進的上升邏輯。 第三部分，提到了一些管理中常見問題，也看得出作者在這方面有經歷有經驗，也非常注意業界的學習，而不只是強行昇華自己的經驗經歷。很佩服，文字中有很冷靜，開闊和樂觀。 這本書整體一般，可以雙休午後集中兩三個小時看完，再重回去審視自己的職業，其啓發之處可以再值得兩三個小時深思。

- 三大熱點問題大討論，想要討好三撥人 -技術人寫書還是太輕鬆了，把平時是博文和蒐集的資料理一理；技術書籍編輯的活也輕鬆，誰熱誰牌不錯就讓誰上桌

程序員成長是管理和技術的相交的正餘弦線，想在這條路上走得穩，走得快，要的永不放棄的心臟和大佬及書籍的指點迷津

我們學的很多技術實現都逃不脫基礎原理，不管是Java，還是其他語言，只要用TCP用的都是相同的原理，逃不出範圍，只要抓住原理，舉一反三，時間一長了，甚至還可以自己推導答案。 對於技術的基礎，我會把其它成四類： 程序語言：語言的原理，類庫的實現，編程技術（併發、異步等），編程範式，設計模式等。 系統原理：計算機系統，操作系統，網絡協議，數據庫原理等。 中間件：消息隊列，緩存系統，網關代理，調度系統 等。 理論知識：算法和數據結構，數據庫範式，網絡七屋模型，分佈式系統等。 有了這些基礎，學新的技術也就不會太難理解。

做爲一個測試，前面兩篇沒有閱讀，大概瀏覽技術精進一篇前面的部分（如何學習新的編程語言），我認爲前兩篇應該也是不錯的。 直接看第三篇管理探祕，以下是一些收穫。 如何構建領導力 管理的核心，就是利用組織的資源把事幹好，從而達到組織的目標。 我的理解，就是組織、上級有什麼目標，給我這邊什麼資源，我指定更加具體的實施計劃，實現這個目標。 技術領導力4D框架 維度1：提供清晰的領導力風格，並以信任感作爲基石 說實話，讀了兩遍書中這部分內容，還是不大明白書中說的提供清晰的領導力風格是什麼到底是意思？ 清晰的領導力風格的判斷標準是什麼？ 管理者在向員工佈置任務時，會把任務“重複”5遍： 管理者：我有一個任務要交給你，任務是這樣的……（第1遍進行詳細的任務說明） 員工：好的，我知道了。 管理者：稍等，你能重複一遍這個任務嗎？ 員工：好的，您交給我的任務是這樣的……（第2遍重複任務是什麼） 管理者：你有想過我爲什麼會佈置這個任務嗎？ 員工：我理解，您佈置這個任務的原因是……（第3遍談論任務的目的） 管理者：在這個任務的進行過程中，你覺得會出現什麼意外情況？遇到什麼情況你會向我彙報？遇到什麼情況你能自己決定？ 員工：我理解，在這個任務中，可能會遇到的意外情況有……（第4遍明確風險和彙報標準） 管理者：如果這個任務讓你自己做，你會有什麼更好的建議和想法嗎？ 員工：如果這個任務讓我自己做，我會……（第5遍讓員工發揮主觀能動性） 維度2：瞭解業務，並帶領團隊達到高績效 在技術管理者帶領團隊確定戰略方向，制定技術和組織實施的過程中，技術管理者本身也在進行角色從“演員”到“導演”的轉換和突破。在沒有做技術管理者之前，技術專家在遇到問題時往往都衝在最前面，就像舞臺聚光燈下的演員。管理者則需要對整臺戲進行策劃，尋找最合適的演員，然後給每個演員都分配明確的角色，讓演員們在舞臺上都有最出色的表現，自己卻可能不上臺。因此，從技術到管理的一個非常重要的突破就是從臺前的“演員”變爲幕後的“導演”。因此，“瞭解業務，帶領團隊高績效”其實也是管理者本身升級和突破的過程。 維度3：發展自己和團隊成員 對於剛從技術專家轉換角色的領導者，首先需要實現的突破就是忍住“我自己做”的衝動，轉爲發掘和培養一個最合適的人，然後選擇最適合他的工作，把事做到最好。 維度4：塑造未來 對一個技術領導者而言，領導力中非常重要的一環就是：和團隊一起確立共同的願景，帶領追隨者實現夢想，同時協助他人實現自我和超越自我。 這個自己現在暫時還達不到。 高效時間管理 確定在做的事情符合自己的目標 在談論高效時間管理之前，我們必須十分清楚自己的目標是什麼，並且在行動及時間安排上始終瞄準自己的既定目標。 第1步：確定自己究竟想要什麼 利用面向未來的場景進行一次思考：假如在什麼時間，需要對你過去的經歷和成就進行總結，請思考，在這樣一份總結中，你希望得到什麼樣的總結？ 第2步：把自己的目標寫下來 心理學研究證明，如果只把一個目標停留在腦海中，沒有以書面形式記錄下來，那麼它就始終是一個空想，毫無生命力可言。相反，如果把自己腦海中的目標用白紙黑字寫下來，這些目標就會變得更清晰、更具體，也會幫助自己創造一個看得見、摸得着的行動藍圖。 第3步：爲自己的目標設定一個最後期限，並讓大家都知道 在爲自己的目標設定一個最後期限，並且讓大家都知道（這非常重要）之後，出於心理學上“承諾和一致性”的壓力，你就會在不知不覺中避免拖延，事情會完成得更快，工作效率也會提高。 第4步：將實現目標需要做的最重要的事情列出來 根據優先級從高到低只列出實現目標所需要做的最重要的三件事。 在最重要的三件事都完成之後，如果暫時沒有達到目標，就再重複分解剩下需要做的最重要的三件事，如此反覆，直到目標達成。 第5步：每天都做一些接近自己目標的事情 當我們開始腳踏實地、一件一件地做關係到目標完成的事情，並且能夠看到成效的時候，我們就會感到滿足、愉悅和信心滿滿，從而投入更多的精力和時間在其中。在執行一段時間之後，就會發現事情一件接一件地完成了！ 隨時應用80/20法則 要把80/20法則應用在時間管理中，我們就需要隨時問自己這些問題： ◎ 這個工作是屬於20%高價值的部分呢？還是屬於80%低價值的部分？ ◎ 對自己需要做的工作，我是否抵禦住了先易（低價值的工作）後難（高價值的工作）的誘惑？ ◎ 自己是否應該做一些減法？把目前工作中屬於80%低價值的部分減少一些，從而增加做另外20%高價值工作的時間？ 創造大塊時間 固定時間法 每天固定時間做固定的事情，養成氣場 減少被打斷 主動通知其他人不要打擾，例如在即時通信工具中設置狀態爲“正忙”；或者切斷干擾源，例如把手機設置爲靜音狀態，從而不間斷地充分利用大塊時間進行高效工作。 每日時間分區法 需要先摸索找到自己的區間：記錄-統計-執行 遇到“不服管”的員工怎麼辦 運用技術領導力4D框架，來應對“不服管”的團隊成員。 團隊管理者內心堅持“每個人都是不錯的”信念 運用教練思維 建立親和與信任感 需要在解決具體的“高難度”的“事”之前，從最重要的“人”出發，建立親和與信任感！ 建立親和與信任感的管理工具1：工作之外的背景介紹。 心理學研究表明，在影響信任感建立的因素中，相互之間的瞭解是很重要的。信任感建立在一定的相互瞭解基礎之上。團隊領導者和團隊成員之間信任感的建立，也必須在一定的瞭解之後纔會開始。而促進相互瞭解最重要的手段，就是對雙方工作之外的個人背景進行了解。 團隊領導者和團隊成員就工作之外的個人背景進行一些介紹和互動，例如自己的家鄉、畢業的學校和專業、第一份工作、之前工作過的公司、愛好、家庭情況、個人的有趣經歷等。 建立親和與信任感的管理工具2：勇於展示個人的不足 在第一次和新團隊成員進行一對一談話時討論這個話題：“你能介紹你的三個優點和三個還可以做得更好的地方嗎？我之後也會和你分享我自己的答案。” 我們已經通過相互分享工作之外的經歷，瞭解了對方的一些背景信息，我想，我們第一次發現了彼此很多之前都沒有想到的內容，比如我們發現學的是一樣的專業。那麼接下來是否可以進行一個更有趣的“冒險”，嘗試向對方分享我們願意分享的兩個強項和兩個弱點。 建立親和與信任感的管理工具3：從績效評估到建設性反饋 1．用“成長式思維”設定成長目標 核心思路一：面向解決方案。 核心思路二：充分利用“有力的問題”引發人的改變。 團隊領導者和團隊成員的溝通方式從陳述句（下達指令）變爲疑問句（通過發問激發團隊思考）。 一般來說，“有力的問題”往往有如下特徵。 （1）簡短，直接，切中要害。 （2）能鼓勵被提問者打開話匣。“有力的問題”是開放式的問題（例如5W1H問題：What、When、Where、Who、Why和How），因而能夠讓被提問者有空間更好地展開回答，從而有更多的機會獲取更多的信息，以及激發更多的創意和思路。 （3）能促使被提問者深入思考。一個出其不意的好問題往往會讓被提問者一時語塞、沉默思考。 2．用建設性反饋助力快速成長 對於一位團隊管理者來說，提供反饋的過程就是依據對事實的觀察，將團隊成員行爲的影響或者效果以客觀的方式提供給團隊成員，以期對員工的行爲產生影響（保持有效的行爲或者改變無效的行爲），從而達到改進績效的目標。 在實踐中提供“建設性反饋”可以遵循下面的五步“公式”進行： 建設性反饋 = 明確目標（“我希望和你討論____”）+觀察（“我觀察到____”）+ 影響（“這麼做的影響是_____”）+要求（“我期望今後你能_____”）+ 討論（“你覺得呢？______”） 第1步：明確此次“建設性反饋”的目標 開門見山、言簡意賅的“建設性反饋”的主題。 第2步：具體描述觀察到的事實 建設性反饋最重要的基石在於具體的事實，所以在描述事實時應該儘量清晰地指出時間、地點，以及發生了什麼。更重要的是，一定要使用第一手的觀察，儘量少使用從其他人那裏獲得的觀察，從而避免反饋和事實出現偏差。 第3步：闡述行爲所產生的影響 所說的影響既包括行爲所帶來的可觀察到的結果，還包括行爲所影響的人的反應。 特別需要注意的是，這裏的影響是一箇中性詞，既包括正面的影響，也包括負面的影響。 第4步：清晰描述期望的行爲 從面向未來的角度清晰描述自己的期望，並提供切實可行的改進行爲以達到目標的建議。 第5步：給對方機會闡述他的想法 如何處理衝突 瞭解產生衝突的原因 1）目標理解不統一 2）多種技術方案選型 3）多項目並行引起資源衝突 4）項目進度衝突 5）團隊成員的情感因素 ◎ 個性不同：大家的溝通方式、方法差異導致溝通不愉快而發生衝突。 ◎ 團員間的偏見：表現爲對他人的觀點不贊同，甚至一言一行都看不慣，這樣勢必發生衝突。 ◎ 價值觀不一致：表現爲因經歷不同、背景不同、觀念差異而產生衝突。 正確看待衝突 在大多時候，大家都認爲衝突只會產生不好的結果，但是世間事都有兩面性，衝突同樣有積極的意義。例如，上述“多種技術方案選型衝突”就可以通過技術討論拓寬視野，彌補衝突各方的認知盲區。我們將衝突產生的積極意義歸納如下。 ◎ 暴露問題，及時熔斷。 ◎ 促進了解，加快團隊磨合。 ◎ 彌補不足，拓寬視野。 ◎ 產生競爭，培養主動思考能力。 ◎ 信息流動，引導創新。 ◎ 團隊涅槃，完善管理。 處理衝突 管理者處理各種衝突的基本原則就是客觀和公正。 1）強調目標和項目的意義，建立共贏意識 2）擱置衝突，冷處理 3）管理協調，雙方妥協 4）建立制度，法治管理。 清晰定義了邊界 5）職務介入，強制執行 利用經理權 如何對上管理 做好對上的預期管理 1.徹底理解需求 心態上，不要畏懼上級，要徹底弄明白上級想要什麼。 2.學會站在老闆的角度理解KPI，求同存異 老闆說的不一定正確，基於KPI思考老闆提出的要求是否合理。如果不合理，是不是最好不要當衆指出老闆的不是，可以私下討論。 及時彙報 1.認真聆聽。因爲彙報也是一個溝通的過程，所以一定要認仔細聆聽且理解領導的意思。 2.簡單扼要地表達。在彙報前羅列好彙報清單，可以運用結構化彙報方法。 先總後分，結構化表述，彙報前自己先打草稿，彙報不記得我覺得可以翻看一下筆記也沒問題。 3.客觀描述，不要避重就輕。 把真實存在的問題反饋出來，紙是包不住火的，提早拋出問題，上級還可能有時間想其他辦法，到最後時間才爆出問題，就無法挽回了。

架構部分大👍🏻 ◆ 1.2 代碼規範與單元測試 >> 我們團隊在項目實際操作過程中沒有嚴格遵循測試驅動設計的步驟，但是遵循了同步編寫開發代碼和測試代碼的思路。 ◆ 4.2 集成 >> 如果某個系統提供一個高併發、低延遲的共享用戶會話方案（Shared Session Storage），則Redis可能是一個非常理想的選擇；如果實現一個產品目錄，涉及大量不確定結構的商品數據及屬性的建模管理，則系統可能會採用模式靈活、有動態Schema的MongoDB作爲數據庫解決方案；如果系統希望支持非常強大的全文搜索能力，則可以採用Elasticsearch。 ◆ 5.1 架構設計概要 >> 應用架構的設計原則如下。 （1）穩定 ◎ 一切以穩定爲中心。 ◎ 架構儘可能簡單、清晰，追求小而美，不要大而全。 ◎ 不過度設計。 （2）解耦 ◎ 將穩定部分與易變部分分離。 ◎ 將核心業務與非核心業務分離。 ◎ 將電商主流程和輔助流程分離。 ◎ 將應用與數據分離。 ◎ 將服務和實現細節分離。 （3）抽象 ◎ 應用抽象化：應用只依賴服務抽象，不依賴服務實現的細節和位置。 ◎ 數據庫抽象化：應用只依賴邏輯數據庫，不需要關心物理庫的位置和分片。 ◎ 服務抽象化：應用虛擬化部署，不需要關心實體機的配置，動態調配資源。 （4）松耦合 ◎ 跨域調用異步化：在不同的業務域之間儘量異步解耦。 ◎ 非核心業務儘量異步化：在覈心業務和非核心業務之間儘量異步化。 ◎ 在必須同步調用時，需要設置超時時間和任務隊列的長度。 （5）容錯設計 ◎ 服務自治：服務能彼此獨立修改、部署、發佈和管理，避免引發連鎖反應。 ◎ 集羣容錯：應用系統集羣部署，避免單點服務。 ◎ 多機房容災：多機房部署、多活。 >> （1）無狀態，即儘量不要把狀態數據保存在本機上。 （2）可複用。 ◎ 複用粒度是有業務邏輯的抽象服務，不是服務的實現細節。 ◎ 服務引用只依賴服務抽象。 （3）松耦合 ◎ 跨業務域調用，儘可能異步解耦。 ◎ 在同步調用時設置超時時間和隊列大小。 ◎ 將相對穩定的基礎服務與易變流程服務分離。 （4）可治理 ◎ 服務可降級。 ◎ 服務可限流。 ◎ 服務可開關。 ◎ 服務可監控。 ◎ 白名單機制。 ◎ 制定服務契約。 （5）基礎服務 ◎ 基礎服務下沉、可複用，例如時效、庫存和價格計算。 ◎ 基礎服務自治、相對獨立。 ◎ 對基礎服務的實現要精簡，並可水平擴展。 ◎ 對基礎服務的實現要進行物理隔離，包括基礎服務相關的數據。 >> 數據架構的設計原則如下。 （1）統一數據視圖，即保證數據的及時性、一致性、準確性和完整性。 （2）數據和應用分離。 ◎ 應用系統只依賴邏輯數據庫。 ◎ 應用系統不直接訪問其他應用的數據庫，只能通過接口訪問。 （3）數據異構，即在源數據和目標數據內容相同時做索引異構，在商品庫不同維度的內容不同時（如訂單數據中的買家庫和賣家庫）做數據庫異構。 （4）數據庫讀寫分離。 ◎ 將訪問量大的數據庫做讀寫分離，例如訂單庫。 ◎ 將數據量大的數據庫做分庫分表。 ◎ 將不同業務域的數據庫做分區隔離。 ◎ 對重要的數據配置備庫。 （5）採用關係數據庫。除成本因素外，MySQL的數據庫擴展性和高併發支持能力較強，也比較容易招聘到相關的研發人員和運維人員。 （6）合理利用NoSQL數據庫。在數據庫有能力支撐時，儘量不要引入緩存。另外，要合理利用緩存做容災。 ◆ 5.3 架構設計的核心要素 >> 軟件架構需要關注性能、可用性、伸縮性、擴展性和安全性這5個要素，下面分別對這5個要素進行講解 >> 網站可擴展架構的主要手段是事件驅動架構和分佈式服務 ◆ 5.4 高性能設計 >> 從開發者的視角來看，性能的重點在於應用服務器的性能，包括響應延遲、系統吞吐量、併發處理、系統穩定性等，主要的優化手段是利用緩存加速數據讀取，使用集羣提高吞吐量，使用異步加快請求響應，優化代碼改善程序，等等。 從運維人員的視角來看，性能相當於一些基礎設施的性能和利用率。 ◆ 5.6 可伸縮設計 是not only sql >> 非關係數據庫設計模式 >> 非關係數據庫設計模式 ◆ 5.7 可擴展性設計 >> 負載均衡、失效轉移、高效的遠程通信、整合異構系統、對應用最小入侵、版本管理和實時監控。 ◆ 第6章 架構的保障：質量與風險 >> 不接受不良品，不設計或製造不良品，不流出不良品 >> （1）P（Plan）：指仔細分析現狀，並將現狀與目標進行對比，看看缺口在哪裏，然後詳細規劃改善的步驟。可以分幾個步驟：一是將問題和目標定義清楚；二是利用各種工具，例如作業流程圖、魚骨圖等，將問題相關的流程和因素梳理出來，定下優先順序；三是進一步拆解流程，仔細分析各個步驟，看看問題可能出在哪裏。 （2）D（Do）：指根據計劃動手改進。需要事先想好退出計劃，在動手時應從小處切入，謹防破壞現有流程，造成系統癱瘓。如果解決方案不止一個，就應該設計一個實驗，評估各方案的優劣。 （3）C（Check）：指監控改進過程。需要確認測量工具和方法維持不變，否則可能誤判。在結果數據出來後，需要仔細分析，看看哪種方案比較有效，而且對原來流程的變更幅度最小。 （4）A（Act）：指確認改善的確有效，在不良和缺陷已經消除後，導入及固化流程，改寫規範。若改善無效，則檢討原因、修改計劃，重新啓動一輪PDCA循環。 ◆ 6.2 從黑天鵝事件到墨菲定律 >> 黑天鵝寓意不可預測的重大稀有事件，它在意料之外，卻又改變着一切 >> 黑天鵝事件通常具備如下三個特點： （1）稀缺、史無前例（Rarity）； （2）影響很極端（Extreme Impact）； （3）具有意外性，但人的本性促使我們在事後爲它的發生編造理由，並且或多或少認爲它是可解釋和可預測的 >> 亞馬孫雨林中的一隻蝴蝶偶爾振動翅膀，也許會引起兩週後美國得克薩斯州的一場龍捲風。” >> 如果有兩種或兩種以上的方式去做某件事情，而其中一種選擇方式將導致災難，則必定有人做出這種選擇。 >> 墨菲定律（Murphy's Law）的主要內容如下： ◎ 任何事都沒有表面看起來那麼簡單； ◎ 做所有的事花費的時間都會比你預期的時間長； ◎ 會出錯的事總會出錯； ◎ 如果你擔心某種情況會發生，它就更有可能發生 ◆ 6.3 軟件質量穩定性之殤 >> 黑天鵝事件告訴我們要走出經驗主義，不要將自己知道的東西太當回事，我們不知道的事比我們知道的事更有意義。蝴蝶效應告訴我們要及時感知問題，止損和熔斷，避免問題範圍擴大甚至傳染到其他相關領域。墨菲定律告訴我們，我們知道的但是忽略的地方終究會出問題 >> 無意的：由於經驗的缺乏導致初級開發者編寫了質量低劣的代碼。 ◎ 有意的：團隊根據當前而非未來進行了設計選型，這種方式可能很快解決了當前的問題，但很拙劣。 >> 隨着技術團隊人員的能力提升，無意的技術債務可能會越來越少。但是在很多時候，我們欠下的技術債務往往是有意的，隨着業務的高速發展，還會帶來很多變化 >> 臨時方案的可怕之處，不僅僅在於其不全面，更在於如果不對其及時處理，可能就永遠“臨時”下去了。隨着團隊成員的不斷更替，慢慢地就沒人記得這個臨時方案了。一個說好只支撐兩個月的臨時代碼，可能兩年後還在線上機器裏運行着。 >> ◎ 通過人員培訓、代碼審查等方式杜絕無意的技術債。 ◎ 要儘量避免有意的技術債。 ◎ 如果一定要引入技術債，則一定不要引入不計後果的技術債。 ◎ 要記錄所有欠下的技術債，並且有償還計劃。 >> 但是不得不說，有很多線上故障都是由於開發者對所使用的新技術不瞭解導致的。 >> 經過分析，80%的線上問題並不那麼難以解決，其本質是未遵循規定的動作。 ◆ 6.4 從康威定律和技術債看研發之痛 >> 康威定律由Conway在1967提出，其主要觀點是：設計系統的架構受制於產生這些設計的組織的溝通結構。 >> 軟件開發領域有一個流行的原則：DRY（Don't Repeat Yourself），我們一般將其翻譯爲：不要重複造輪子 >> 架構是演進出來的，而不是設計出來的。筆者比較贊同這種說法 >> 架構方案和業務形態息息相關。 ◎ 架構是演進的、發展的，沒有最好，只有適合。 ◎ 技術債要做清償計劃。 ◎ 不要在下雨天補屋頂 ◆ 6.5 求解質量熵 >> 黑天鵝告訴我們，要走出經驗主義，就不要將自己知道的太當回事，我們不知道的事比我們知道的事更有意義；蝴蝶效應告訴我們，要及時感知問題、止損和熔斷，避免問題範圍擴大甚至影響到其他相關領域；墨菲定律告訴我們，你知道卻忽略的問題終會爆發！ >> 我們可以建立如下價值觀： ◎ 個體和互動優於流程和工具。 ◎ 能工作的軟件優於詳盡的文檔。 ◎ 客戶合作優於合同談判。 ◎ 響應變化優於遵循計劃 >> ，當我們適應了原有狀態卻需要面對改變時，我們會經歷抵抗、混亂、改變主意、重新上路等過程，最後適應新的狀態。 >> 技術人員水平不行、意識不夠，代碼越寫越亂。 ◎ 開發者都有一顆積極向上的心，但不知道如何做纔好。 ◎ 上行下效，沒有靠譜的Leader、架構師，大家便都是懶惰的，不想去還債。 ◎ 業務壓力太大，趕着交付，沒有時間清償技術債 >> 這裏總結了幾個有效應對思路。 ◎ 構建質量保障體系，讓開發人員有勇氣動手改造。比如進行接口測試、單元測試，通過持續集成進行反饋，這樣開發人員在做重構的時候就有一些基本保障。 ◎ 不要動遺留系統中沒有出問題的地方，對於遺留系統中出問題的地方，修復並補充測試代碼，更進一步地，對高危功能和模塊做定向增強。 ◎ 招募優秀的工程師，使好的工作作風和習慣影響整個團隊。 ◎ 抓住痛點大做文章。比如，平時說持續集成，可能團隊成員沒有感受到其好處，那麼出Bug了再討論討論； >> 通過ATDD、引流對比、串講反串講、評審、錄製回放驗證、接口迴歸測試等手段可以驗證從需求到設計再到實現是否發生了變形。 >> 一旦以某種高耦合方式引入某種技術，調整或者去除該技術的成本就會呈幾何級數形式。 >> 除了需要構建功能迴歸測試環境，還需要構建性能迴歸測試環境，以保障每次發佈的產品性能是沒有降低的 ◆ 6.6 踩過的坑和經驗總結 >> 這個默認設置當初是一個“臨時方案”，但是一直沒被改過。這就是技術債的問題 >> 在上線前未經過代碼審查。這就是人、流程與文檔之間的博弈問題。 >> 也恰巧印證了墨菲定律：未經過測試的功能往往存在問題。 >> 主要還是由於技術債導致的。由於在方案設計初期沒有考慮到業務發展可能帶來的變化，在無意中引入了“臨時方案”，就欠下了技術債，進而導致故障的發生。 ◆ 6.7 故障覆盤流程及模板 >> 故障覆盤的最終目的其實是通過對已經產生的故障的反思，進行總結及優化。 筆者認爲，故障覆盤主要有如下目的。 ◎ 對已發生的故障進行總結，避免再次出現同樣和類似的問題。 ◎ 找出團隊的強弱項，優化人員分工和辦事流程。 ◎ 嘗試找到更好的問題解決辦法。 ◎ 進行經驗總結，分享沉澱，引起大家的廣泛重視。 >> 故障覆盤主要有如下目的。 ◎ 對已發生的故障進行總結，避免再次出現同樣和類似的問題。 ◎ 找出團隊的強弱項，優化人員分工和辦事流程。 ◎ 嘗試找到更好的問題解決辦法。 ◎ 進行經驗總結，分享沉澱，引起大家的廣泛重視 >> 故障發生時間、故障描述、影響範圍、主要模塊、相關責任人、故障處理人員、故障處理時效、故障的當前狀態、故障解決時間、故障解決方案、故障原因、故障定級等。 >> 故障定級根據不同的業務有着不同的指標，通常可以參考的指標有：影響用戶數、故障恢復時間、用戶投訴數、資金損失數、模塊重要性等。 >> 在定性和定責時需要明確出哪些個人（團隊）對本次故障承擔主要責任，哪些個人（團隊）對本次故障承擔次要責任，定責過程要公平、公正、公開，做到權責一致、邊界清晰 >> 制定的行動點都需要滿足如下條件。 ◎ 必須是明確的項，要有明確的行動點，不能是大而空的規劃。 ◎ 必須可落地，能夠切實改善既有問題。 ◎ 必須可驗收，有明確的驗收標準。 ◎ 必須承諾驗收時間，並且要在原則上按照承諾的時間完成。 ◆ 6.8 監控與告警 >> 監控是每個公司都必不可少的重要風險防控手段。 >> JMX框架提供了關於JVM的大部分核心信息，應用系統可以通過接入JMX框架來實時讀取JVM的CPU、內存等信息。 >> 警信息需要包含時間、機器IP、告警原因、告警描述和錯誤日誌等重要信息，以便於開發人員快速排查問題，如圖6.22所示 ◆ 6.9 應急處置 >> 系統最近是否上過線？ ◎ 依賴的基礎平臺是否升過級？ ◎ 依賴的系統是否上過線？ ◎ 是否有線上營銷活動？ ◎ 網絡是否穩定？ ◎ 業務量是否有變化？ 對系統層一般監控如下指標。 ◎ 系統的CPU使用率。 ◎ 平均負載（Load Average）。 ◎ 內存（Memory）。 ◎ 網絡與磁盤I/O。 ◎ SWAP使用情況。 ◎ 線程數。 ◎ 文件描述符（File Description）等。 ◆ 7.1 構建自我階段性目標 >> 滿意的工作從兩件事開始，一是有明確的目標，二是有實現這一目標的可操作性步驟。 ◆ 8.1 什麼是領導力 >> 管理的核心，就是利用組織的資源把事幹好，從而達到組織的目標。 >> 管理的核心在於事，領導力的核心在於人。 ◆ 8.3 讓自己成爲T型人才 >> 我們也可以將T型人才簡單理解爲“一專多能”, T字的橫軸表示跨專業領域的思考能力，T字的紝軸表示精深的專業能力 >> 需要做充分的準備。 ◎ 離開舒適區，學會挑戰自己，讓自己所掌握的技能變得更爲精深；與同行保持交流，從中掌握不同的設計方案和不同的思考方式。 ◎ 堅持閱讀及與不同領域的人交流，以接納更多的信息和觀點。 ◎ 創造需求，及時應用和實踐自己掌握的知識，這也是讓知識變得更有價值的好方法，而不僅僅是讓知識成爲一種可閱讀的信息流。 ◎ 嘗試訓練自己從多個角度分析問題，或用不同的思維思考問題。 ◎ 給學習和應用設定目標和里程碏，讓自己一步步地成爲T型人才。 ◆ 8.5 遇到“不服管”的員工怎麼辦 >> 典型的技術思路：找出“不服管”的原因所在，針對原因找出解決方案，實施方案

三門功課好像都說了，但是好像又都沒有說透。作者既然是中國人，是頭部互聯網的人，爲什麼書裏還有哪些老掉牙的外國公司的事兒？就不能把實際工作過程中遇到的問題，如何解決的詳細說說？想一本書把三門課都講好，看完覺得好像什麼都沒有講出來。後面管理的內容更是，企業文化誰都會講，怎麼在實際工作中有產出？最終還是唯OKR。

做技術多年，隨着年齡漸長，很多程序員都會有這些疑惑，我也經常被別人諮詢過這些問題： 做了很多年的程序員到底要不要轉管理，轉做管理有前途嗎？ 轉做管理後到底怎麼帶團隊？ 這些困惑都因爲——年齡是職場生存的一條重要法則。 程序員薪水雖高，但光鮮的外表下，背後的苦衷只有自己知道。三十多歲本該是一個人事業的黃金期，但技術變化日新月異，行業競爭異常殘酷，對一個企業來說，永遠有更年輕、勞動成本更低的人可以選擇，這讓程序員的中年危機提前到來。 其實不管是否轉型還是要練好三板斧：技術、架構、管理。 關注我一起交流程序員那些事。