世界上需要什麼樣的程序員

不想當工程師的程序員不是好民工。會編程不代表會工作，工程能力包含軟硬技能，面向的是實際應用。從程序員變爲工程師，得先「入門」然後纔是「上道」，從而成爲「工型人才」有人工作幾年還沒入門，只會簡單開發;有人開發技能嫺熟，卻找不到進步成長的路徑，陷入迷茫之中;更有不少人自詡爲IT精英，卻不瞭解行業格局、發展趨勢，很快就遇到職業發展瓶頸，蹉跎了歲月，虛度了青春。

在我看來，好的程序員應該是「工型人才」。所謂「工型」，是指從下到上的能力提升過程。具體來說，就是先要具備完成完整應用的能力，包括:線上運維，成爲熟手，這是下面的一橫；在某些領域足夠深入，成爲高手，這是中間的一豎;在達到更高的水平之後，兼通很多領域，比如業務、產品、項目管理、測試、運維、團隊組織，成爲驅動者和領導者，這是上面的一橫。

本書使用人羣

有很多程序員剛進入職場時自己的職業規劃幾乎爲零，一心想着怎樣儘快學習更多的技術和積累更多的業務經驗，但現實是每天都深陷永無止盡的業務需求開發中。

　　也有些程序員因爲長期埋沒於代碼世界的浩大分工體系中，無法看清從業務到系統架構的價值鏈條，無法清晰定義自己在分工體系中的位置，處理不好自身與技術、業務的關係。

　　更有些程序員在到了35歲之後，發現工作瓶頸已到，對未來的發展感到迷茫。

　　要是能有人幫他們規劃，他們可能進步得更快。

　　《程序員的三門課：技術精進、架構修煉、管理探祕》作者均有紮實的技術功底和十分豐富的工作閱歷，已經摸索出相對清晰的職業發展路徑。他們把自己的親身經驗總結和踩過的坑總結成這本書，以幫助和他們一樣致力於在IT道路上走得更遠的人。

作者簡介

本書內容分爲三大篇

第1篇介紹程序員的技能成長路徑，介紹如何通過學習來加速成長，並講解非常重要的業務分析和設計知識；

第1章 程序員技能與成長 2

1.1 如何學習新的編程語言 2

• 1.1.1 重點學什麼 3
• 1.1.2 學習方法 3

1.2 代碼規範與單元測試 6

• 1.2.1 編碼規範 6
• 1.2.2 單元測試 7
• 1.2.3 測試驅動設計 9

1.3 使用靜態代碼分析工具 18

• 1.3.1 什麼是靜態代碼分析 19
• 1.3.2 靜態代碼分析工具 19

1.4 代碼審查 24

• 1.4.1 什麼是代碼審查 24
• 1.4.2 代碼審查的好處 24
• 1.4.3 如何做代碼審查 25

1.5 清單和模板 29

• 1.5.1 清單實踐 29
• 1.5.2 產品需求文檔模板 31

1.6 程序員的工作法則 33

• 1.6.1 工具化法則 33
• 1.6.2 自動化法則 38
• 1.6.3 關於文檔的問題 40
• 1.6.4 關於YAGNI 40

1.7 程序員的工具箱 41

• 1.7.1 可幫我們提升工作效率的硬件 42
• 1.7.2 可幫我們提升工作效率的操作系統 43
• 1.7.3 可幫我們提升工作效率的軟件 43
• 1.7.4 在線工具 50

第2章 加速成長與學會學習 56

2.1 程序員如何加速成長 56

• 2.1.1 積極主動 56
• 2.1.2 空杯心態 57
• 2.1.3 選擇合適的平臺 57
• 2.1.4 別怕犯錯 58
• 2.1.5 注意細節 58
• 2.1.6 時間管理 58
• 2.1.7 打破邊界 61
• 2.1.8 寫業務代碼中的成長機會 61

2.2 學會學習 66

• 2.2.1 高效學習的方法 67
• 2.2.2 高效學習的途徑 69
• 2.2.3 舒適區與小步子原則 72
• 2.2.4 兩個著名的學習理論 72
• 2.2.5 終身成長 74

第3章 業務分析與設計 75

3.1 黃金圈法則 75

3.2 UML建模工具 77

• 3.2.1 用例圖 78
• 3.2.2 類圖 79
• 3.2.3 對象圖 80
• 3.2.4 狀態圖 80
• 3.2.5 活動圖 81
• 3.2.6 序列圖 82
• 3.2.7 協作圖 82
• 3.2.8 構件圖 83
• 3.2.9 部署圖 84

3.3 業務分析與設計的方法 85

3.4 系統分析與設計的三個發展階段 87

• 3.4.1 面向數據驅動分析與設計 87
• 3.4.2 面向對象和服務分析與設計 88
• 3.4.3 面向問題域分析與設計 89

3.5 面向對象分析與設計 90

• 3.5.1 什麼是面向對象 90
• 3.5.2 面向對象的特徵 91
• 3.5.3 面向對象設計的原則 91

3.6 面向服務分析與設計 93

• 3.6.1 Web Service模式 93
• 3.6.2 ESB模式 94
• 3.6.3 微服務架構 95

3.7 領域驅動設計 97

3.8 領域模型實踐 102

• 3.8.1 什麼是領域模型 102
• 3.8.2 領域模型的作用 102
• 3.8.3 如何進行領域建模 104

第2篇詳細介紹了架構修煉中的必備架構思維模式、架構設計過程，還通過真實案例剖析了架構設計的核心要素及關注點，以及如何通過架構設計來把控質量和風險;

第4章 架構思維 110

4.1 分解 110

• 4.1.1 分解的作用 111
• 4.1.2 分解的原則 111
• 4.1.3 分解的時機 112

4.2 集成 112

• 4.2.1 常見的集成方式 112
• 4.2.2 集成的難點 115

4.3 動靜分離 120

4.4 複用 121

• 4.4.1 系統複用的分類 122
• 4.4.2 可複用性和可維護性的關係 123
• 4.4.3 可維護性地複用的設計原則 123

4.5 分層 126

4.6 模式 127

• 4.6.1 分層模式 128
• 4.6.2 客戶端-服務器模式 131
• 4.6.3 主從設備模式 132
• 4.6.4 管道-過濾器模式 133
• 4.6.5 代理模式 133
• 4.6.6 P2P模式 134
• 4.6.7 事件總線模式 135
• 4.6.8 MVC模式 136
• 4.6.9 黑板模式 137
• 4.6.10 解釋器模式 138

4.7 抽象 139

4.8 結構化 139

• 4.8.1 結構化的原則 140
• 4.8.2 結構化分析工具 140
• 4.8.3 結構化思維的7個環節 141

4.9 迭代 141

4.10 勿做過度設計 141

注意：需要免費領取的朋友，幫忙一鍵三連，文末掃碼即可~

第5章 架構設計 143

5.1 架構設計概要 143

• 5.1.1 業務架構 143
• 5.1.2 應用架構 145
• 5.1.3 技術架構 147
• 5.1.4 數據架構 149

5.2 架構設計的流程 151

5.3 架構設計的核心要素 153

• 5.3.1 性能 153
• 5.3.2 可用性 153
• 5.3.3 伸縮性 154
• 5.3.4 擴展性 154
• 5.3.5 安全性 154

5.4 高性能設計 154

• 5.4.1 主要的性能測試指標 155
• 5.4.2 性能測試方法 156
• 5.4.3 性能優化策略 157

5.5 高可用設計 159

• 5.5.1 高可用性的度量與考覈 159
• 5.5.2 高可用的架構 160
• 5.5.3 高可用質量保證 164
• 5.5.4 系統運行監控 165

5.6 可伸縮設計 166

• 5.6.1 架構的伸縮性設計 166
• 5.6.2 應用服務的伸縮性設計 167
• 5.6.3 分佈式緩存的伸縮性設計 169
• 5.6.4 數據存儲的伸縮性設計 169

5.7 可擴展性設計 169

• 5.7.1 通過消息降低系統的耦合性 170
• 5.7.2 通過分佈式服務提供可複用的業務 170
• 5.7.3 建立開放平臺 170

5.8 架構設計的典型案例——訂單系統 171

• 5.8.1 訂單的基本概念 172
• 5.8.2 訂單流程 174
• 5.8.3 訂單系統設計中的挑戰和實踐 178
• 5.8.4 數據庫優化 182
• 5.8.5 小結 185

第6章 架構的保障：質量與風險 186

6.1 內建質量體系 186

6.2 從黑天鵝事件到墨菲定律 189

• 6.2.1 黑天鵝事件 189
• 6.2.2 蝴蝶效應 191
• 6.2.3 墨菲定律 191

6.3 軟件質量穩定性之殤 192

• 6.3.1 業務高速發展帶來的變化 193
• 6.3.2 問題域的複雜性 193
• 6.3.3 系統的複雜性 194
• 6.3.4 技術債問題 194
• 6.3.5 人、流程、文檔的博弈 195
• 6.3.6 採用不能掌控的工具和框架 196
• 6.3.7 質量意識 196

6.4 從康威定律和技術債看研發之痛 197

• 6.4.1 康威定律 197
• 6.4.2 通過3個案例來看研發之痛 197
• 6.4.3 架構方案和業務形態息息相關 204

6.5 求解質量熵 206

• 6.5.1 運用敏捷思想 207
• 6.5.2 運用系統化思想 208
• 6.5.3 技術債償還計劃 209
• 6.5.4 抓住合適的時機做架構升級 209
• 6.5.5 內建質量 210
• 6.5.6 不迷信，不唯新、不唯上，實踐是檢驗真理的標準 210
• 6.5.7 複雜的問題域：專項突破 210
• 6.5.8 領導者的意識 211
• 6.5.9 創新解決方案 211

6.6 踩過的坑和經驗總結 212

• 6.6.1 簡單的數字改動導致電商網站搜索功能失靈 212
• 6.6.2 應用竟然被外部系統拖垮了 212
• 6.6.3 HashMap與併發 213

6.7 故障覆盤流程及模板 215

• 6.7.1 什麼是故障覆盤 215
• 6.7.2 爲什麼要做故障覆盤 215
• 6.7.3 如何做故障覆盤 216
• 6.7.4 故障覆盤模板 219

6.8 監控與告警 221

• 6.8.1 監控的重要性 221
• 6.8.2 監控哪些內容 221
• 6.8.3 告警 224
• 6.8.4 監控的架構 224

6.9 應急處置 226

第3篇總結了做技術管理的訣竅，揭祕如何從準備做技術管理到實現自我管理再到實現團隊管理。

第7章 爲成爲技術主管做準備 232

7.1 構建自我階段性目標 232

7.2 體驗自己的目標身份 234

7.3 勇於抓住機會 235

第8章 從自我管理轉爲管理團隊 236

8.1 什麼是領導力 236

8.2 如何構建領導力 237

• 8.2.1 維度1：提供清晰的領導力風格，並以信任感作爲基石 238
• 8.2.2 維度2：瞭解業務，並帶領團隊達到高績效 240
• 8.2.3 維度3：發展自己和團隊成員 240
• 8.2.4 維度4：塑造未來 241

8.3 讓自己成爲T型人才 242

8.4 高效時間管理 243

• 8.4.1 確定該做的事情符合自己的目標 244
• 8.4.2 隨時應用80/20法則 246
• 8.4.3 創造大塊時間 247

8.5 遇到「不服管」的員工怎麼辦 249

• 8.5.1 每個人都是不錯的 250
• 8.5.2 建立親和與信任感 251
• 8.5.3 從績效評估到建設性反饋 255

8.6 如何處理衝突 261

• 8.6.1 瞭解產生衝突的原因 261
• 8.6.2 正確看待衝突 262
• 8.6.3 處理衝突 263

8.7 引導員工主動工作 264

8.8 如何從帶10個人到帶100個人 266

• 8.8.1 在管理上面對的挑戰 267
• 8.8.2 從管理1.0到管理2.0 269

8.9 如何對上管理 276

• 8.9.1 做好對上的預期管理 277
• 8.9.2 及時彙報 277

寫在最後

以上就是程序員必修的三門課程，需要朋友，幫忙一鍵三連，掃碼即可~