代碼之外的功夫：程序員精進之路

程序員和其他人一樣關心人類利益；只不過，他們很難將其作爲生活重點，因爲每天大部分時間都被花在查找缺失的分號、閱讀沒有文檔的庫的源代碼，或是盯着某些可能因Unicode轉換錯誤而損壞的二進制轉儲文件發呆。如果能夠與粗糙、低級、繁瑣的現有工具作鬥爭，逐漸用與工作成果更貼近的工具取代它們，那麼行業的關注點就能果斷地、永久地由以技術爲中心轉變爲以人爲本。 爲了全面看待這一問題，可以想象一下在過去代碼由彙編語言編寫、數據需要存儲在手動打包的二進制大對象裏的那種環境下，該怎樣解決現在的編程問題。在數字和邏輯約束的海洋裏，很容易將整個軟件開發問題看作純數學問題。 這種抽象空間不太容易理解。因此，勤懇的程序員不願被吹毛求疵，尤其是當他們覺得自己的工作很高端時更是如此。 現在就行動起來，你將會有一個值得驕傲的明天。對於我們每個人來說，問題的答案不盡相同，但考慮這個問題是很有必要的，因爲未來需要每個人參與創造、互相幫助、貢獻力量。

十二月份讀完的第九本書，週日兩個小時消化掉，實話說動物書裏很少有看到這麼淺顯易懂的書。主要分享了一些作者在做軟件項目的一些管理方法，實踐性比較強，可以直接套來用。

功夫在詩外，需要多年的工作經驗和思考的積累沉澱，不然就一直會是個底層的程序猿，藍領知識工人。

作者幽默風趣，以故事的講述方式，代碼之外的功夫，其實程序員在工作中，有一大部分時間並不是在寫代碼，而是如何有效應對開發中的各種問題，如何改進和提高自己，如何跟團隊成員溝通協作，如何理解客戶的需求，並快速實現他們的所需等，用以人爲本的方式思考代碼。讓我們從這些小故事中，獲得自己的思考和成長。

IT佬的書再分享一下😮 本書與寫代碼並沒有太大關聯，也不是講如何設計代碼，不像「設計模式」那些教授代碼結構的書籍；這本書更多的是寫出程序員應具備甚麼質素和思想，畢竟有很強的篇程能力，但沒有良好的心理質素和想法，程序員亦很難昇華上另一個層次。本書認為，程序員自身要認清程序員的本質，要認清這個崗位原意是甚麼，本書算是比較玄和虛，是關於程序員哲學的書。

雖然只有短短的幾百頁，讀來卻身臨其境。作者提到的一些場景很常見，是實際工作中會用到的一些場景。讀完這本書之後,收穫還是不少的。有幾點尤爲使我印象深刻： 1.學習並善於利用流程圖，原型圖，UML 類圖等工具和項目相關人員多溝通反饋，在編碼之前儘可能快速確定一些設計方案和流程。 2.謹慎引入第三方服務或者庫，記得實時關注服務變更信息。 3.注意自底向上和自頂向下這倆種設計方式的優劣和使用場景。正確合理的使用他們可以使我們的工作高效簡潔。 4.修復bug時注意先退回穩定版本，控制事態。進一步確定影響範圍，討論制定合理的修改方案。而不是一上來就急忙去做。 5.做增量或者擴展時注意做好服務的拆分隔離。不要讓增加擴展的部分影響到原有服務功能。

公司一位很牛的產品經理給我推薦的書，算是囫圇吞棗地看完了（畢竟我真的不愛看小說，對一些故事敘述類的書基本沒有好感... 不過，這本書的某些觀點還是讓我耳目一新的。程序員要關注的不僅僅只是編碼技術，代碼只是用來解決問題的工具，在着手解決問題前的需求分析、問題拆解、風險評估、經濟因素考慮...等等過程，都應該積累成爲程序員的經驗沉澱。 萬一哪天程序員不再是程序員，積累下來的軟實力也都是通用的吧kkk..

花不大的時間代價翻完，還是值得看的。

與其他動物書不一樣的是，這本書不是在教我們如何做一個寫出優雅代碼的程序員，而是在教我們如何務實地做出和維護一個商業產品，代碼從來只是工具，不是產品本身，產品也只是爲人服務，因而從設計 開發 迭代到維護 支持，首要考慮的不是如何寫代碼，而是關注於人的訴求。

Title和內容明顯不符，案例非常膚淺。當然部分評論經驗有點道理。翻譯的太差，看着彆扭的中文我都知道英文應該本來是什麼樣的。