《程序員修煉之道--從小工到專家》讀書筆記

前段時間看完了《程序員修煉之道–從小工到專家》這書。該書沒有涉及什麼很深奧的技術，或者有特別複雜的設計，都是一些來自經驗的總結。它涉及的內容比較廣，涵蓋了整個軟件開發過程中需要注意的地方，從需求分析，到程序編寫測試重構，再到項目管理都涉及。它提倡程序員應該擁有良好的素質，必須有正確的觀念，良好的習慣。

注重實效的哲學-讓你的用戶參與與權衡

作爲一個優秀的程序員，編寫出完美的產品是我們一生的追求。但是實際情況中，需要考慮很多不特定因素，如時間、技術、成本等，導致我們沒有辦法一步到位。而且用戶在向你提需求的時候，很多時候他們只有一個方向，也不清楚具體的細節，不知道自己真正所需要的產品的最終形態。如果你先給用戶一個不完美，存在瑕疵，但是可用的軟件，讓他們及早使用，他們會向你反饋他們真正的需求，能把你引向更好的最終解決方案。今天了不起的軟件比明天的完美軟件更加可取。
我現在所做的項目就很好的印章了這一點。這是一個線下售賣收銀系統，由於在項目搭建初期時間特別緊急，我們只能快速設計，快速編程，快速上線，然後不斷的迭代，不斷修復各種問題。雖然該項目上線後存在不少的問題，但是至少能夠滿足用戶的核心業務，能夠正常的售賣商品。而且在得到用戶的反饋後，產品在不斷的完善，到目前爲止產品已經基於穩定，已經無限接近用戶的真實需求了。以現在的角度來看，這也是一個成功的項目。

注重實效的途徑-可撤銷性

書中舉了個切換關係數據庫供應商的例子。大概意思就是如果講數據庫的概念抽象出來（抽象到數據庫知識把持久作爲服務提供出來的程度），你就會擁有“中流換馬”的靈活性，抽象能讓你的程序更加健壯。
但我想說的是，如果程序都是單一的解決方案，沒有可以替代的方案，那有時候對你的程序將是一個毀滅性的隱患。例如你的收銀系統只有建行一個供應商，正常情況下系統跑着不會出現什麼問題，但是但凡建行端出現任何問題就會導致你的收銀系統癱瘓，無法完成在線支付，這對業務來說絕對是一個毀滅性的消息。而且你還無能爲力，只能依賴你的供應商進行解決。所以這就要求我們在程序設計必須考慮可替代性、靈活性。

上圖將支付相關的所有操作都封裝到一個類裏面，這樣不但可讀性極差，而且不易擴展。如果我們仔細考慮下，其實支付、支付查詢、退款、退款查詢等的模式都是一致的，我們完全可以獎每個特定的動作抽象出來。改造後如下：

基本工具

工欲善其事，必先利其器，這個道理中國人都懂。作爲一個優秀的開發人員除了必須熟悉基本的開發工具完，還應該熟悉瞭解自己所在公司的工具。畢竟公司開發出來的工具就是爲了解決員工在實際工作中遇到的一些問題，能幫助員工快速的完成開發、快速定位生產問題等。作者就因爲對公司的工具不是特別的瞭解導致很多工作都很難往下開展，甚至還導致了bug的出現（痛苦的領悟）。

小結

當然除了以上內容，該書還有很多內容和細節值得我們細細的去品味，如正交性、按合約設計、需求之坑、無處不在的自動化等等。讀完這本書給我最大的感觸是，優秀的程序員必須注重實效，培養良好的素質，將正確的觀念當成習慣。以用戶需求爲基準，設計可配置的軟件，但不能過分設計。支持拔插式的軟件設計，能讓你的程序更加靈活，更容易應對各種不確定因素。

作者：張偉峯