第1章 善用設計原型，探索項目創意 1
1.1 從理解項目背後的需求入手 2
1.2 利用綫框圖錶達功能需求 3
1.3 編程之初立即搭建測試係統 4
1.4 全麵探討不足，改善追求實效 6
1.5 早問多問，驗證設想 8
1.6 力求縮小自己的工作範圍 8
1.7 謹記原型並非生産係統 12
1.8 巧妙設計特性，輕鬆收集反饋 13
第2章 觀察增量變更，發掘隱藏依賴 19
2.1 不存在所謂的“獨立特性” 19
2.2 兩特性同屏必相互依賴 21
2.3 避免不必要的實時數據同步 23
2.4 復用舊代碼，尋找新問題 25
第3章 準確識彆痛點，高效集成服務 29
3.1 麵對小眾需求，切記未雨綢繆 30
3.2 謹記外部服務並不可靠 31
3.3 服務一旦有變，查找過期的模擬對象 34
3.4 遭遇爛代碼，維護必頭疼 35
3.5 不存在純粹的內部問題 37
第4章 設計嚴密方案，逐步解決問題 39
4.1 收集事實，清晰描述 40
4.2 寫代碼之前手動解決部分問題 42
4.3 核實輸入數據，隨後進行處理 44
4.4 善用演繹推理，檢驗工作質量 46
4.5 欲解復雜問題，先知簡單情況 47
第5章 謹記自底嚮上，優化軟件設計 55
5.1 找齣關鍵詞，認清問題 56
5.2 從實現最小化功能入手 57
5.3 避免對象間不必要的時間耦閤 60
5.4 逐步提取可復用的組件與協議 63
5.5 進行大量實驗，發掘隱藏抽象 66
5.6 瞭解自底嚮上方法的局限 67
第6章 認清現實瑕疵，改善數據建模 71
6.1 分清概念建模和物理建模 71
6.2 明確設計模型，追蹤數據變化 74
6.3 理解康威定律，實踐數據管理 78
6.4 謹記工作流設計與數據建模密不可分 81
第7章 逐漸改善流程，閤理安排時間 85
7.1 敏捷、安全地應對意外故障 86
7.2 識彆並分析操作瓶頸 88
7.3 注意權衡工作的經濟效益 89
7.4 限製積壓工作，力求減少浪費 92
7.5 力求整體大於部分之和 95
第8章 認清行業未來，再議軟件開發 101
作者介紹 110
封麵介紹 110
· · · · · · (收起)
具體描述
本書雖然麵嚮程序員，卻不包含代碼。在作者看來，90%的程序設計工作都不需要寫代碼；程序員不隻是編程專傢，其核心競爭力是利用代碼這一工具解決人類社會的常見問題。以此作為齣發點，作者精心構思瞭8個故事，以情景代入的方式邀請讀者思考代碼之外的關鍵問題：軟件開發工作如何從以技術為中心轉為以人為本？透過故事主人公的視角，讀者能比較自己與書中角色的差異，發現決策過程的瑕疵，提升解決問題的綜閤能力。
書中的故事涵蓋程序員的整個軟件開發生涯，但經過瞭濃縮，可供所有軟件開發人員快速閱讀。
用戶評價
##很好，角度不錯
評分##如何高效忽悠産品經理
評分##翻譯太垃圾瞭 後麵幾章讀下來感覺就是字都認識，拼一起不知道這話什麼意思瞭
評分##簡而言之，啥玩意兒啊…
評分"程序員不隻是編程專傢，其核心競爭力是利用代碼這一工具解決人類社會的常見問題。" 認識到這件事尤其重要， 很多公司拿程序員月産代碼行數 來作為生産力的衡量指標 就讓很多年輕的程序員被誤導到 認為這就是生産力 一年前一個月提交超過1萬行代碼 perf還拿瞭差評 現在一個月提交1行代碼 1個CL 上至總監VP 各個看到我那一行代碼眼睛都睜圓瞭 紛紛加自己進抄送列錶 這就是區彆 BTW 提交那1行代碼就是上個月的事 (+ +)
評分##一堆廢話，讀瞭跟沒讀一樣
評分##簡而言之，啥玩意兒啊…
評分##模擬瞭一些工作場景中的生産問題，並說明瞭解決該問題的方法，但是遠不及實際工業生産的復雜和睏難，新人可以翻閱一二。
評分##程序員和其他人一樣關心人類利益；隻不過，他們很難將其作為生活重點，因為每天大部分時間都被花在查找缺失的分號、閱讀沒有文檔的庫的源代碼，或是盯著某些可能因Unicode轉換錯誤而損壞的二進製轉儲文件發呆。如果能夠與粗糙、低級、繁瑣的現有工具作鬥爭，逐漸用與工作成果更貼近的工具取代它們，那麼行業的關注點就能果斷地、永久地由以技術為中心轉變為以人為本。 現在就行動起來，你將會有一個值得驕傲的明天。對於我們每個人來說，問題的答案不盡相同，但考慮這個問題是很有必要的，因為未來需要每個人參與創造、互相幫助、貢獻力量。
相關圖書
本站所有內容均為互聯網搜尋引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2026 windowsfront.com All Rights Reserved. 靜流書站 版權所有