職業化程式設計原則：從 QQ 閒聊看工程師思維進階

一次早晨的 QQ 技術答疑，意外記錄下資深工程師「肖舸」對初學者的幾輪引導。對話雖短，卻濃縮了從「寫出能跑的代碼」到「寫出可維護、可賺錢的產品代碼」的核心心法。本文整理對話精華，提煉五大職業化設計原則。

場景回顧：兩個核心問題

1. 延遲初始化：網友想在 malloc() 首次調用時才初始化 std::vector<Block*> blocks，而非建構函數。
2. 動態類工廠：網友想用字串鍵值在運行期動態實例化任意類，類似反射/插件機制。

原則一：顯式控制物件生命週期，拒絕隱式建構陷阱

肖舸：我們對於類嵌套的成員對象，一般都是用指標，然後顯式在函數中去 new。實做中幾乎不會聲明成員對象實體，因為會引發非常多的額外問題。我們習慣於自己控制一切，很少使用 C++ 默認的建構和析構動作。

深度解析

• 建構順序不確定性：全域/靜態物件跨編譯單元時，建構順序由鏈接器決定，若 A 依賴 B 卻先建構 A → 崩潰，且極難複現 (VC++ 典型症狀)。
• 指標 + 顯式 new/delete：將控制權收回程式碼可見範圍，消除「看不見的建構函數」風險。
• 現代替代：C++11 起優先使用 std::unique_ptr/std::shared_ptr + std::make_unique，兼具顯式控制與异常安全。

原則二：API 設計遵循「最小驚訝原則」，符合領域常識

肖舸：定義 API 名稱時，應盡可能符合「常識」。MemFree(&p) 要求傳指標的指標雖能置 NULL，但違背 free(p) 慣例，極易誤用。

對照表

原則三：技術選型以「商業價值」為錨，拒絕過度工程

肖舸：根據現代分布式計算理論，動態類查詢在實際中會有很多辦法規避掉……建議不要鑽這個牛角尖，費力氣很大，對於賺錢沒幫助。

決策框架

1. **業務必要性**：是否為核心域剛需？還是「覺得很酷」？
2. **替代方案成本**：配置檔 + 工廠模式 / gRPC 微服務 / Lua 腳本熱載，是否更低成本解決？
3. **長期維護債**：動態反射帶來的除錯難度、編譯時類型安全缺失、團隊認知門檻。

對話中提到的「字串實例化」需求，最終被導向「配置驅動 + 靜態工廠映射表」或「微服務註冊發現」，而非 C++ 模板元程式重造輪子。

原則四：可讀性 > 微優化，腦力比記憶體貴

肖舸：情願多浪費電腦資源，不要浪費程式員的腦力。你絞盡腦汁節約了 3~4 個中間變量，大約節約了 12~16 Bytes。現在的電腦，記憶體起步就是 2G，有意義嗎？反而，如果中間有一個隱蔽的 bug，查錯誤可能要半個月，你半個月的工資能再買台電腦了。

具體實踐

• **展開循環** → **拆分函數**：單一職責、易單元測試、易 Profile 熱點。
• **避免鏈式操作**：devices.[has(child)?this:void]?.[*.contains(module)?void:module] 這類「一行寫兩層循環」的語法糖，除錯時幾乎無法打斷點、無法觀察中間值。
• **中間變量即文檔**：bool cpu_ok = (usage < 85); if (cpu_ok) ... 比 if (usage < 85) ... 更能表達業務意圖。

原則五：不信編譯器魔法，手動拆解才能看見優化點

肖舸：永遠不要相信編譯器，它不知道你的需求。把動作拆細，你就會發現很多優化要點。……如果集合夠大，比如幾萬個，你這麼寫，怎麼知道編譯器內部使用什麼演算法來實現查找？如果我來控制，我可以配搭兩個 Hash，一步到位實現高速檢索。

案例對比

// 網友版：隱式雙層循環，演算法不透明
devices.filter(...).map(...)

// 肖舸版：顯式雙 Hash，O(1) 查找
unordered_map by_id;
unordered_map> by_module;
// 精確控制資料結構與存取路徑

總結：從「酷代碼」到「賺錢代碼」的心智轉型

對話結尾，網友說：「在技術上，在賺錢上，都好好消化消化。」這或許是從「碼農」走向「工程師」的關鍵一步。

來源：肖舸的 blog