基本介紹
- 書名：0bug-C/C++商用工程之道
- 類別：程式語言
- 頁數：584頁
- 開本：16
內容簡介,圖書目錄,序言/前言,
內容簡介
本書可以幫助你擺脫“Training”式編程開發思維與方法，培養“商用”和“產品”標準的工程開發技能。
圖書目錄
第1章 商用工程開發思路 1
1.1 系統分析初步 2
1.1.1 需求理解和溝通 2
1.1.2 “上家”和“下家” 3
1.1.3 角色“定名” 3
1.1.4 初步的拓撲圖 4
1.1.5 後續的模組級設計 4
1.1.6 商用設計思維 5
1.2 商用程式設計師對開發的理解 5
1.2.1 資源和成本 5
1.2.2 盈利導向 6
1.2.3 客觀 7
1.2.4 平衡 9
1.2.5 服務 11
1.3 基本開發思路 15
1.3.1 邊界 15
1.3.2 “細分”的分析方法 16
1.3.3 靈活，逆向思維 17
1.3.4 小核心，大外延，工程庫思維 18
1.3.5 單筆交易失敗不算失敗 19
1.4 數據傳輸各個角色的開發思路 20
1.4.1 伺服器的設計原則 20
1.4.2 PC客戶端的開發思路 21
1.4.3 嵌入式設備的開發思路 22
1.4.4 跨平台軟體模組的開發思路 23
第2章 基礎知識 25
2.1 記憶體的理解 26
2.1.1 32位作業系統的記憶體分配 26
2.1.2 C/C++語言對記憶體的使用 27
2.1.3 記憶體——bug之源 30
2.2 並行運算 31
2.2.1 時間片 31
2.2.2 進程和執行緒 32
2.2.3 同步和異步 33
2.2.4 禮貌地釋放時間片資源 35
2.2.5 跨執行緒通信 36
2.2.6 跨進程通信 39
2.2.7 網路，並行運算的世界 40
2.3 “鎖”的使用 41
2.3.1 為什麼要使用鎖 41
2.3.2 使用鎖容易犯什麼錯誤 42
2.3.3 “行為鎖”和“資源鎖” 46
2.3.4 單寫多讀鎖 48
2.3.5 不可重入鎖 49
2.3.6 用鎖的最高境界——不用 50
2.4 “池”的深刻含義 51
2.4.1 “池”的由來 51
2.4.2 “池”的使用 53
2.5 跨平台、跨語言開發基礎 54
2.5.1 C/C++跨平台開發基礎 54
2.5.2 dll和so 55
2.5.3 API和NPI 55
2.5.4 服務無處不在 56
2.6 debug的重要性 57
2.6.1 在數據傳輸領域，你親眼看到的都不是真的 57
2.6.2 如何看到——萬事從debug開始 60
2.6.3 debug的原則 60
2.6.4 如何分析數據 61
2.7 性能統計的重要性 62
2.7.1 需要統計哪些信息 62
2.7.2 基本的統計方法 63
2.7.3 隨機數的產生 65
2.8 佇列無處不在 65
2.8.1 數據結構在數據傳輸中的套用分析 65
2.8.2 需要哪幾種佇列形式 66
2.9 不要求全責備 66
第3章 C/C++無錯化程式設計 69
3.1 “無錯化程式設計”簡介 71
3.1.1 無錯化程式設計思路 71
3.1.2 C/C++無錯化設計的解決方案 72
3.1.3 使用後的效果 73
3.2 電腦程式的真諦 74
3.2.1 程式就是“搬數” 74
3.2.2 程式就是“寫文章” 75
3.2.3 程式就是“複製” 77
3.2.4 筆者看程式設計 78
3.3 定名 79
3.3.1 匈牙利命名法 79
3.3.2 函式命名原則 80
3.3.3 變數命名原則 81
3.3.4 其他命名規則 83
3.3.5 定名的折中 86
3.4 無錯化程式的基本書寫原則 87
3.4.1 寫簡單易懂的程式 88
3.4.2 嚴禁變數轉義 90
3.4.3 嚴禁一語多義 91
3.4.4 函式只能有一個出口 92
3.4.5 變數如不使用，保持初值 95
3.4.6 常量必須定名 97
3.4.7 太大數組不要用靜態方式 98
3.4.8 儘量避免使用遞歸 99
3.4.9 解決方案一套就夠 99
3.5 基本程式設計原則 100
3.5.1 函式的設計 100
3.5.2 類的設計 102
3.5.3 其他要點 116
3.6 基本語句的約定 122
3.6.1 判斷語句，常量永遠在左邊 122
3.6.2 for (i = 0; i < n; i + +) 124
3.6.3 while(1) 125
3.6.4 不要使用do...while( ) 125
3.6.5 i++和++i問題 126
3.6.6 請不要使用“?(...) :(...)”結構 127
3.6.7 善用大括弧{ }縮小作用域 127
3.7 請使用goto語句 130
3.7.1 函式只有一個出口的原則需要goto 131
3.7.2 誰分配、誰釋放的原則需要goto 131
3.7.3 商用工程要求goto 133
3.7.4 程式的易讀性要求goto 135
3.7.5 break為什麼不能亂用 136
3.7.6 goto的常規使用手法 138
3.8 指針的使用原則 139
3.8.1 商用數據傳輸常見的指針類型 139
3.8.2 不要使用兩個以上的*號 141
3.8.3 指針不能參與四則運算 141
3.9 使用結構體的技巧 143
3.9.1 結構體傳參的必要性 143
3.9.2 預防多重指針的隱患 145
3.9.3 32位到64位移植 145
3.9.4 彈性記憶體使用需要結構體傳參 146
3.9.5 網路傳輸協定，需要結構體傳參 148
3.10 使用宏的建議 150
3.10.1 宏的幾大作用 150
3.10.2 C+ +的建議 151
3.10.3 編譯宏——跨平台開發 152
3.11 回調函式設計方法 152
3.11.1 回調模型設計者 153
3.11.2 回調模型使用者 155
3.11.3 參數傳遞的常規手法 158
3.11.4 事件模型和回調模型 160
3.12 C語言字元串的深入研究 161
3.12.1 字元串拷貝 161
3.12.2 字元串構造 164
3.12.3 關於字元串處理的結論 166
3.13 C/C+ +語言無錯化程式設計小結 166
第4章 設計自己的工程庫 168
4.1 數據傳輸庫中到底需要哪些模組 170
4.1.1 跨平台定義 170
4.1.2 鎖與安全模組 170
4.1.3 記憶體池 171
4.1.4 資源管理池 171
4.1.5 執行緒池與任務池 171
4.1.6 佇列管理 172
4.1.7 其他工具 172
4.2 工程庫基礎——跨平台定義 172
4.2.1 鎖定義 172
4.2.2 執行緒控制相關定義 174
4.2.3 Socket傳輸相關定義 175
4.2.4 include系統頭檔案 178
第5章 debug工具 180
5.1 變參函式的設計 182
5.2 文本輸出 183
5.2.1 獲得時間戳 184
5.2.2 同時輸出到檔案和螢幕 184
5.2.3 文本輸出的原則 187
5.3 二進制輸出的debug函式 188
5.4 核心debug和日誌系統的區別 190
5.5 統計模組 191
5.5.1 累加器 192
5.5.2 計算模組 192
5.5.3 平均值計算 194
5.5.4 統計平均值計算 196
5.5.5 輔助功能函式 198
5.6 CLowDebug工具類 200
5.6.1 需求分析 201
5.6.2 數據邊界聲明 201
5.6.3 類聲明 202
5.6.4 類工具函式 204
5.6.5 業務函式 207
5.7 基本debug工具小結 210
第6章 鎖 211
6.1 二元動作理論 213
6.1.1 二元動作在C語言中的書寫特性 213
6.1.2 面向對象和面向過程的本質差異 216
6.1.3 二元動作在C++語言中的特殊要求 218
6.1.4 二元動作開發關注要點 219
6.2 鎖對象 225
6.3 多執行緒安全的變數 226
6.3.1 CMint和CMbool試驗 226
6.3.2 多執行緒安全的變數模板 230
6.4 單寫多讀鎖 241
6.4.1 單寫多讀鎖的來源 241
6.4.2 單寫多讀鎖C語言實現 243
6.4.3 單寫多讀鎖的C++實現 251
6.4.4 TonyXiaoMinSleep 252
6.4.5 單寫多讀鎖安全變數 253
6.4.6 單寫多讀鎖的真實意義 256
6.5 不可重入鎖 258
6.5.1 需求分析 258
6.5.2 類實現 259
6.5.3 使用樣例 260
6.6 執行緒控制鎖 261
6.6.1 執行緒控制鎖的實現 263
6.6.2 執行緒控制鎖的使用 264
6.7 儘量不用鎖 265
第7章 記憶體與資源管理 267
7.1 記憶體管理的基本要求 268
7.1.1 不泄露 268
7.1.2 不產生碎片 268
7.1.3 可以自動報警 269
7.2 記憶體池的核心邏輯——記憶體棧 270
7.2.1 記憶體管理的數學模型 270
7.2.2 管理模型的最佳化 272
7.2.3 關於鍊表管理的思考 273
7.2.4 記憶體塊元素 276
7.2.5 記憶體棧 286
7.3 記憶體指針註冊管理模組 292
7.3.1 記憶體註冊模組原理介紹 293
7.3.2 模組設計及類聲明 293
7.3.3 構造函式和析構函式 296
7.3.4 Add函式 298
7.3.5 Del函式 299
7.3.6 Modeify函式 300
7.3.7 PrintInfo函式 301
7.3.8 記憶體註冊模組的深入使用 301
7.4 Socket註冊管理模組 302
7.4.1 類聲明 303
7.4.2 構造函式和析構函式 304
7.4.3 Add函式 306
7.4.4 Del函式 307
7.4.5 PrintInfo函式 308
7.5 記憶體池類 308
7.5.1 類聲明 309
7.5.2 構造函式和析構函式 310
7.5.3 記憶體棧公有方法 312
7.5.4 指針管理方法 313
7.5.5 Socket管理方法 314
7.5.6 PrintfInfo方法 315
7.6 記憶體管理的深層次含義 315
7.6.1 資源重用的理念 316
7.6.2 註冊和反註冊機制 316
7.6.3 靜態資源的管理思路 316
7.7 被動池的常見組織形式 317
7.7.1 被動池的數據特性及需求分析 317
7.7.2 動態與靜態被動池的差異性 318
7.7.3 靜態被動池實施原理 318
7.7.4 被動池的常見組織形式 320
第8章 佇列 322
8.1 為什麼單說佇列 323
8.1.1 網路同步的需求 323
8.1.2 協定信令排序的需求 323
8.1.3 存儲轉發的需求 324
8.1.4 異步轉同步需要佇列 325
8.1.5 負載均衡需要佇列 325
8.1.6 等停需要佇列 326
8.1.7 特例：實時轉發不需要佇列 326
8.2 幾種常見的佇列介紹 326
8.2.1 不是佇列的佇列CBuffer 327
8.2.2 靜態佇列PopBuffer 327
8.2.3 動態佇列MenQueue 328
8.3 動態Buffer類 328
8.3.1 編程思想的轉變 328
8.3.2 Buffer類的需求分析 332
8.3.3 Buffer類聲明 333
8.3.4 構造和析構函式 335
8.3.5 緩衝區大小設定函式 335
8.3.6 二進制拷貝函式 341
8.3.7 數值轉換函式 342
8.3.8 二進制數據處理函式 344
8.3.9 文本字元串處理函式 345
8.3.10 數據比較函式 346
8.3.11 小結 347
8.4 靜態Buffer類 348
8.4.1 類聲明 348
8.4.2 構造函式和析構函式 350
8.4.3 緩衝區設定函式 351
8.4.4 二進制拷貝函式 354
8.4.5 數值轉換函式 356
8.4.6 二進制數據處理函式 357
8.4.7 文本字元串處理函式 358
8.4.8 數據比較函式 359
8.4.9 小結 359
8.5 PopBuffer 360
8.5.1 PopBuffer基本需求分析 360
8.5.2 基本數據結構介紹 361
8.5.3 基本類模型 363
8.5.4 構造函式和析構函式 365
8.5.5 工具服務函式 366
8.5.6 業務查詢函式 368
8.5.7 添加AddLast 370
8.5.8 提取GetAndDeleteFirst 372
8.5.9 MoveAllData 376
8.5.10 PopBuffer小結 378
8.5.11 PopBuffer的不足 380
8.6 MemQueue 381
8.6.1 動態佇列的管理原則 381
8.6.2 基本數據結構介紹以及最佳化考慮 382
8.6.3 基本功能類聲明 384
8.6.4 構造函式和析構函式 386
8.6.5 輔助工具函式 388
8.6.6 追加AddLast 391
8.6.7 提取GetAndDeleteFirst 395
8.6.8 PopBuffer相關操作 398
8.6.9 檔案保存相關操作 403
8.6.10 執行緒安全鎖封裝類 407
8.7 小結 413
第9章 時間片管理 415
9.1 多執行緒與單執行緒開發的差異 416
9.1.1 單任務作業系統運行程式的特點 416
9.1.2 任天堂遊戲機中斷機制 417
9.1.3 利用中斷實現多任務 419
9.1.4 多任務作業系統運行程式的特點 422
9.1.5 多任務作業系統運行程式的機制 424
9.1.6 多任務運行環境的世界觀 426
9.2 多任務作業系統常見執行緒操作 429
9.2.1 執行緒相關變數 429
9.2.2 執行緒函式聲明 431
9.2.3 執行緒函式啟動 433
9.2.4 MIN_SLEEP 433
9.2.5 執行緒操作總結 434
9.3 執行緒池 436
9.3.1 執行緒池的來源和需求分析 437
9.3.2 執行緒池的設計原理 440
9.3.3 執行緒池的基本數據結構 445
9.3.4 執行緒池的類設計說明 448
9.3.5 構造函式和析構函式 451
9.3.6 管理者執行緒 453
9.3.7 服務者執行緒 457
9.3.8 註冊函式 460
9.3.9 執行緒池小結 463
9.4 任務池 466
9.4.1 任務池的原理分析 467
9.4.2 任務池的需求和設計 475
9.4.3 任務池的基本定義說明 478
9.4.4 任務池的類聲明 480
9.4.5 構造函式和析構函式 482
9.4.6 管理者執行緒 484
9.4.7 服務者執行緒 485
9.4.8 任務註冊接口 488
9.4.9 任務池的小結及實現示例 488
9.5 任務池的運行體 489
9.5.1 簡化運行態 490
9.5.2 任務描述工具類 490
9.5.3 任務池運行體的設計原理 497
9.5.4 任務池運行體的類聲明 499
9.5.5 StartTask 501
9.5.6 StopAll和PrintInfo 503
9.5.7 任務執行執行緒回調 503
9.5.8 任務池運行體小結及調用示例 505
9.6 時間片小結 507
第10章 Log日誌管理系統 509
10.1 日誌管理系統需求分析 511
10.2 設計原理和邊界定義 511
10.3 類聲明 512
10.4 構造函式和析構函式 514
10.4.1 構造函式 514
10.4.2 析構函式 517
10.5 檔案名稱控制邏輯 517
10.6 業務輸出方法函式 521
10.7 Log日誌系統小結 525
第11章 聚合工具類 527
11.1 聚合工具類的類聲明 529
11.2 聚合工具類函式說明 532
11.3 額外的話題：Linux服務程式怎么寫 538
11.3.1 伺服器的開發習慣 538
11.3.2 Linux的開發習慣 542
11.3.3 Linux下開發服務程式的基本需求 543
11.3.4 基本設計原理 543
11.3.5 程式實戰演示 546
11.3.6 程式使用說明 555
第12章 細節決定成敗（代結束語） 556
12.1 工程實踐注重細節 557
12.2 究竟怎樣才能學好C和C++語言開發 558
12.3 如何做一名成功的軟體工程師 559
12.4 關於網路數據傳輸 560
12.5 結束語 560
序言/前言
0.1 為什麼要寫本書
在本書定名的時候，筆者做了很多思考。本書究竟想說什麼？關注的重點在哪裡？看起來，本書所講述的知識、經驗和技巧，在很多書上都有講，那么，我們的差別在哪裡呢？
筆者看到過無數的年輕學子，興高采烈地從學校出來，走向職場，但是，通常立即會遇到兩個問題：
（1）他們雖然在學校中學到了很好的知識，但是到了企業中，卻沒有辦法投入實用，甚至找不到工作。是他們學習的書不對？還是他們的老師沒有教對？很多人陷入迷茫之中。
（2）另外即使一個學子，順利進入了企業，成為一名程式設計師，但無窮無盡的加班和做不完的項目任務，使生活充滿了壓力，也充滿了苦悶。即使能賺取高薪，但生活毫無樂趣可言。這又是為什麼呢？
筆者在IT研發領域工作了十幾年，在這裡有一點心得。
首先，筆者認為，學生即使學會了基本的程式開發技能，但還不能算作一個標準的商用程式設計師，其工作習慣、做事的思路和方法，特別是在具體程式工作中所秉持的設計思想，系統性思維，與企業需求相差甚遠，這導致了就業上的困難，因此需要學習和調整。
其次，筆者認為程式設計師生活壓力大，很多時候並不是任務量的壓力，做過一些程式設計工作的朋友大概都有印象，“程式好寫，bug難追”。真正導致我們大量加班的，往往不是程式的設計和書寫過程，更多的，是debug。而企業中開發商用程式，由於對bug有著幾乎為0的容忍度，這導致了商用程式設計師壓力很大。
筆者一直在企業中做事，自己也深有體會，筆者曾經在2000年左右做過一個統計，發現工作中對bug的查找，占據了自己60%～80%的工作量。當時筆者就思考，如果能有一種方法，使程式一寫出來就沒有bug，那該是多么美妙的一件事情。
由於筆者一直從事C和C+ +語言方面的開發工作，於是筆者就著這個熟悉的領域，開始了一點探索和研究工作，其間也參考了很多大師寫的書籍。慢慢地，自己形成了一套程式書寫原則和方式，筆者將其定名為“C/C+ +無錯化程式設計方法”。經過實際工程試用，發現效果不錯，很多程式出來之後bug很少，成熟度很高，得到了一些好評。
但是，隨之發現了另外一個問題：商用工程，是為客戶需求服務的，一段程式，如果不能滿足客戶需求，即使寫得再正確也毫無意義；同時，一個系統的設計，如果脫離了需求分析，即使採用再精妙的算法，再優秀的設計，也是毫無意義的。
這使筆者不得不思考一個更深層次的問題，商用軟體工程，其實已經不僅僅涵蓋程式設計的領域，僅僅就程式談程式，其實並無意義。一名商用程式設計師，不僅僅要是程式設計的專家，也必須是商務溝通的專家、客戶需求理解的專家。這大大擴展了“程式設計師”這個職業的內涵和外延。
筆者發現目前市面上有很多關於程式設計的書籍，也有很多職業訓練方面的書籍，但是，卻從來沒有人（也許是筆者孤陋寡聞），以程式開發的角度，講述程式設計師進入企業後應該學習的商業開發思維和設計思想。
因此，筆者希望能根據自己的經驗，寫一本書，幫助大家快速掌握一些工程化的開發技巧，並和自己過去所學的相結合，快速成長為企業合用的人才。
0.2 本書包括哪些內容
本書主要針對C/C+ +語言在商用工程開發中的程式實戰進行論述。
本書無意重複無數書籍已經寫過的一些C和C+ +語言的基礎知識，而是試圖從另外一個角度，從需求出發，從商用解決方案的角度，去理解C和C+ +語言的程式設計技巧。
因此，本書更多的以一種實用主義的態度，從需求出發去挑選需要的技術，並針對需求做出相應的最佳化，最終形成合用的商用開發方案。
本書可以說是一本教科書，因為裡面有大量的經驗和技巧，更有筆者多年積累的解決方案思路。但本書也可以說不是教科書，如果出於一種系統全面學習知識的角度來看本書，可能會有一點點失望，因為本書的知識已經打亂，完全在為需求服務。
本書是一本C和C+ +語言的開發類書籍，裡面講述了大量開發的技巧，比如如何實現無錯化的程式設計，使程式在寫出來的時候就已經具有較高的魯棒性，接近0 bug的地步。
本書也是一本實踐類書籍，內附大量的工程代碼，其中就包括筆者歷經差不多10年時間總結出來的一套工程庫，這套庫代碼已經在多個商用工程中獲得檢驗，穩定可靠，並取得了可觀的經濟效益。本書附有的所有原始碼，均執行BSD License，即大家可以免費使用，開源或者閉源發布產品，唯一的要求是，請大家保留筆者的原作者信息。
筆者近年來主要從事數據傳輸、分散式資料庫以及伺服器集群方面的研發工作，因此本書中舉出的很多具體實例與這類套用開發有關，但筆者認為，這並不重要。貫穿於本書始終的商用化開發思維、以需求為導向的開發思路、實用主義的開發態度，才是最重要的。
筆者希望通過本書給大家傳遞一個信息：商用開發和學校內的程式設計，根本就是兩個概念，大家可能使用同一種工具，同一個平台，但是，好比一個修理腳踏車的個體戶老闆，和汽車4S店的維護工人比較，二者有著本質的“度”的差別。提供的服務品質是完全不一樣的。
從這個意義上說，不僅僅是C和C+ +的程式設計師，其他領域的程式設計師，也可以看看本書，從自己的專業領域出發，理解一下商用工程開發的魅力所在。
0.3 商用工程開發和軟體編程的區別
首先，我們要討論一下何謂商用。
在學校中，大家是學生，第一任務是學習更多的先進知識，因此，求知是第一要務，對於一個問題，要求不厭其煩、精益求精，知其然，還要知其所以然。
而在企業中，大家是公司的一分子，要不斷為企業賺取利潤，同時賺取自己的薪水。因此，對於工作，一方面要能做到，另一方面還要以儘可能低的成本實現，才能賺取更多的利潤。這其實已經說明了二者最大的差異性：“嚴格的成本意識和質量意識”，在商用程式設計師眼中，沒有程式，只有產品。
既然是產品，就要嚴格地控制產品的質量，將bug率降到接近0的地步，還要嚴格地控制成本，商用程式設計師深刻理解自己工作的價值，能用一天完成的工作，絕對不用兩天，萬事從需求出發，滿足需求即可，既不會不求甚解，也不會過猶不及，商用程式設計師善於把握平衡。
商用程式設計師，工作的目的是為產品質量負責，更是為產品的市場表現負責，但最終目的，還是為公司賺取的利潤負責。因此，貫穿於商用程式設計師思維的核心，應該是最大限度地滿足客戶需求，創造企業價值，至於具體使用什麼技術，技術是否很高深，是否很能顯示自己的水平，其實商用程式設計師並不關心。
就筆者個人理解，這也是目前很多企業倡導的：“研發工作，市場為主導，不要搞科研”，的真實含義。
體現在實際的工作中，傳統的程式設計師，往往以自我為中心，評判產品正確與否的標準，是自己的程式是否有bug，會不會掛死，只要自己的程式OK，就視為已經完成任務了。
而擁有商用程式開發思維的程式設計師，會更加關心工程項目的中心思想，核心的客戶需求，隨時隨地判斷自己所做的工作，對整個項目的實現是否起到正面的作用，一切的最佳化方向，是否貼合需求所需要的業務數據類型以及使用方向。
商用程式設計師不會僅僅關心自己的程式是否OK，而更加關心整體系統的品質、性能能否滿足客戶需求，同時，自己的開發工作消耗了公司多少人力和時間成本，在同等品質的條件下有沒有更快、更廉價的解決方案，等等。
最終，商用數據傳輸程式設計師的這些思考，將直接導致工程項目能否為公司賺取利潤。說句俗一點的話：一般程式設計師，關心技術；商用程式設計師，關心成本，關心利潤，關心“錢”。
0.4 商用程式設計師的核心思想
軟體編程是一項技術性很強的工作。同時，軟體開發發展這么多年，產業結構也逐漸細分，一個人的精力，不太可能面面俱到，精通所有的技術。
傳統思維的程式設計師，更多的是站在技術的角度上思考問題，遇到問題，首先想到的是利用自己熟悉的技術來實現方案。
而商用程式設計師，更多的是站在客觀的立場，理智地分析客戶需求實現方案，需要用到哪些技術，或者說哪些技術更加合適，成本更低。
同時，商用程式設計師也不迷信最新的技術、最前沿的技術，事實上，很多時候，商用程式設計師偏保守，因為他知道尊重商用工程最為核心的需求：穩定！
舉個例子，一個普通的Windows程式設計師，在接到一個C/S類型的工程項目後，往往會首先思考如何利用Windows搭建伺服器和客戶端，迅速實現。一個普通的Linux程式設計師，可能也是如此，僅僅是作業系統換成Linux而已。
而實際中，大家都知道，客戶端開發大多數是Windows平台，因為這個作業系統市場占有率最高，而伺服器平台最好使用Linux，因為不花錢，可以有效降低公司的運營成本。
一個商用程式設計師，不管自己精通的是Windows開發還是Linux開發，首先就會針對上述市場上的具體情況做出分析，提出合適的解決方案。
另外，即使這個商用程式設計師是C或者C+ +的高手，但在Server端的方案設計時，除了特殊的一些保證效率的需求，大多數需求會建議放到Apache上，利用PHP或者JavaScript之類的腳本語言完成。因為眾所周知，C和C+ +語言是底層語言，其開發和測試成本遠高於PHP之類的腳本語言。
0.5 本書適合哪些讀者看
關於本書適合給哪些人看，其實前面已經有過一些描述，但這裡還是具體細述一下：
很多軟體專業的學生，初次進入職場，需要迅速掌握企業商業化開發的思路和技巧，建議看一看本書。
C和C+ +的學習者和愛好者，建議看一看本書。可以掌握很多實際的技巧，並獲得一個現成可用的工程庫。
商業公司的程式設計師，建議看一看本書。可能您已經掌握了很多商用開發的思維和技巧，但也許本書能給您一點新的提示。
網路遊戲公司的開發人員，建議看一看本書。本書的多任務工程庫可能會對您很有幫助。
各種商用伺服器的開發人員，建議看一看本書，本書中很多技巧，實際上是利用C如何實現7×24小時穩定性的伺服器的技巧，很有幫助。
嵌入式的開發人員，建議看一看本書。本書中嚴格的代碼規範和數據邊界意識，對嵌入式之類資源較少，且有長期運行要求的設備開發，很有幫助。並且，如果使用開發伺服器的技巧開發嵌入式產品，產品的穩定性會非常高。
其他語言的程式設計師，有可能的話，建議也看一看本書。本書中很多基本模組的實現，如記憶體池、執行緒池等，對Java等程式設計師理解自己平台的相同模組，很有幫助，並且，本書提出的商用開發思想是跨語言跨平台的，也很有參考價值。
各個公司的產品經理、項目經理、架構師，有可能的話，建議也看一看本書。本書中提出的很多商用系統工程的設計理念，是筆者多年開發的經驗結晶，對於系統的設計、商用項目的風險管控，有很好的參考作用。
0.6 本書中一些名詞的解釋
API：Application Programming Interface，應用程式編程接口。作為現代商用工程最重要的協同開發和模組劃分手段，API幾乎無處不在。商用程式設計師或多或少都接觸過各種API，如Win32 API，socket API等，甚至已經有程式設計師自己開始建立API意識，主動設定API來與其他模組接口。API一般為C的函式定義形式，以及一些關鍵數據結構的定義。能被C、C+ +、Java、PHP等大多數語言所識別並使用。
NPI：Network Programming Interface，網路編程接口。這是筆者在工作中自己總結出來的一個概念，API作為接口標準，受到各個模組工程師的尊重，但API畢竟是本機訪問，大多數時候也限於C語言一種，在複雜的網路協同環境中不能滿足需求，筆者提出NPI的概念，就是在網路界面層，提出一種接口概念，不同平台，不同語言開發的模組，可以藉由這個接口層互相聯繫、發生互動，進而完成業務。NPI除了包括API所有信息外，也包括網路信令，IP位址及連線埠描述等信息。
Loading：這是一個舶來詞了，筆者也是向台灣的同事學習到的。原意指網路伺服器的頻寬占用，由於頻寬通常需要向運營商花錢購買，因此，這個詞就有了成本的含義。一個系統使用的Loading越高，運營成本就越高。不過推而廣之，大家後來漸漸習慣用這個詞代指一切需要花錢購買的資源，如CPU Loading過高，就是需要占用很大的CPU計算資源。記憶體loading過高，就是記憶體占用太多，等等。本書會常常用到這個辭彙。
Log：商用工程，由於一般都有7×24小時長期運行的需求，因此一般都有自己的日誌系統，用以記錄運行期間的重大事件、關鍵報文的流轉、一些可能導致崩潰的重大錯誤等，用以事後分析。這類日誌系統，一般也稱為Log系統。
Server/Client：網路通信中的伺服器和客戶端角色。通常說來，客戶端是網路動作的發起者，伺服器是被動的接收和執行者。但請注意，網路情況千變萬化，角色經常會發生變化，一個Server，可能是另外一個Server的Client。
UI：User Interface，用戶界面。相關的還有GUI，圖形用戶界面；CUI，文本控制台用戶界面（就是類似DOS和Linux的文本界面，依靠用戶輸入文字執行命令。Windows下也有文本控制台視窗）。
