《程序員修煉之道:通向務實的最高境界》讀書筆記

入了程序員的行，勢必就要做好終身學習的準備，而且要根據新技術的發展不斷更新迭代自己的知識體系。自我迭代，是推進小白走向大白的必經之路。學習新知識新技術的同時，我們也需要重視經典的方法論，比如算法、數據結構、軟件工程、設計模式等以及程序員修煉之道。

下面是在讀這本書時的一些筆記：

1.?人生是你的

你有權選擇：?人生是自己的，把握住人生，讓它如你所愿。

2.?我的源碼被貓吃了

提供選擇，別找借口：提供選擇而不是去找理由，不要只說做不到，解釋一下都能做些什么。

3.?軟件的熵

不要放任破窗：只要看到不好的設計、錯誤的決策、糟糕的代碼就趕緊去糾正。

4.?石頭做的湯和煮熟的青蛙

做推動變革的催化劑：?你無法強迫人們去改變但可以展示美好未來，并幫助他們參與創造。

牢記全景：不要過度沉漫于細枝末節，以免察覺不到周圍正在發生的事情。

5.?夠好即可的軟件

將質量要求視為需求問題：讓用戶參與對項目真實質量需求的確定。

6.?知識組合

對知識組合做定期投資：養成學習的習慣

批判性地分析你讀到和聽到的東西：不要受供應商、媒體炒作或教條的影響，根據自身和項目的實際情況來分析信息。

7.?交流！

英語就是另一門編程語言：將英語視作一門編程語言。寫文檔和編程一樣要遵循DRY原則、ETC、自動化等。

說什么和怎么說同樣重要：如果無法有效交流，任何偉大的想法都是沒有意義的。

把文檔嵌進去，而不要栓在表面：與代碼隔離的文檔很難保持正確并及時更新。

8.?優秀設計的精髓

優秀的設計比糟糕的設計更容易變更：適合使用者的事物，都已經過良好設計。對代碼來說這意味著必須適應變化。

9.?DRY邪惡的重復

DRY不要重復你自己：系統中的每一條知識都必須有單一且無歧義的權威陳述。

讓復用變得更容易：只要復用方便，人們就會去做。創建一個支持復用的環境。

10.?正交性

消除不相關事物之間的影響：設計的組件，需要自成一體、獨立自主，有單一的清晰定義的意圖。

11.?可逆性

不設最終決定：不要把決定刻在石頭上，而要將其視為寫在沙灘上的東西，時刻準備應變。

要有替代方案、放棄追逐時尚：尼爾福特說過: “昨日之最佳實踐即明日之反模式。” 要基于基本原則去選擇架構，而不盲從于流行。

12.?曳光彈

使用曳光彈找到目標：通過不斷嘗試并看清著彈點，曳光彈可確保你最終擊中目標。

13.?原型與便簽

用原型學習：制作原型旨在學習經驗其價值不在于過程中產生的代碼，而在于得到的教訓。

14.?領域語

靠近問題域編程：用問題領域的語言來做設計和編程。

15.?估算

通過估算來避免意外：開始之前做估算，能提前發現潛在問題

16.?純文本的威力

將知識用純文本保存：純文本不會過時，它能夠讓你的工作事半功倍，并能簡化調試和測試工作。

17.Shell 游戲

發揮 Shell 的威力：當圖形化界面無法勝任時

18.加強編輯能力

游刃有余地使用編輯器：既然編輯器是至關重要的工具，不妨了解一下如何用它更快更準確地實現需求。

19.版本控制

永遠使用版本控制：版本控制為你的工作創造了一個時間機器，可以用它重返過去。

20.調試

去解決問題，而不是責備:?Bug 到底來自你的失誤還是別人的失誤真的不重要，它終究是你的問題，需要你來修復。

不要恐慌

修改代碼前先讓代碼在測試中失效

讀一下那些該死的出錯信息

“select”沒出問題

不要假設，要證明

21.文本處理

學習一門文本處理語言：既然每天都要花大量的時間與文本打交道，何不讓計算機幫你分擔一二？

22 .工程日記

你無法寫出完美的軟件:軟件不可能是完美的，對于在所難免的錯誤，要保護代碼和用戶免受其影響。

23.契約式設計

通過契約進行設計：代碼是否不多不少剛好完成它宣稱要做的事情，可以使用契約加以校驗和文檔化。

24.死掉的程序不會說謊

盡早崩潰：徹底死掉的程序通常比有缺陷的程序造成的損害要小。

25.斷言式編程

使用斷言去預防不可能的事情:如果一件事情不可能發生，那么就用斷言來確保其的確不會發生。斷言在校驗你的假設，要使用斷言在不確定的世界中將你的代碼保護起來。

26.如何保持資源的平衡

有始有終:?只要有可能，對資源進行分配的函數或對象就有責任去釋放該資源

27.不要沖出前燈范圍

小步前進由始至終: 永遠小步前進，不斷檢查反饋，并且在推進前先做調整。

28.解耦

解耦代碼讓改變更容易：耦合使事物緊緊綁定在一起，以至于很難只改變其中之一

29.在現實世界中拋球雜要

30.變換式編程

編程講的是代碼，而程序談的是數據，所有的程序都在變換數據

31.繼承稅

不要付繼承稅：考慮一下能更好滿足需求的替代方案，比如接口、委托或 mixin

32.配置

使用外部配置參數化應用程序：如果代碼對一些在應用程序發布后還有可能改變的值有所依賴，那么就在應用外部維護這些值。

33.打破時域耦合

通過分析工作流來提高并發性

34.共字狀態是不正確的狀態

共享狀態會帶來無窮的麻煩，而且往往只有重啟才能解決

35.角色與進程

使用角色來管理并發狀態，可以避免顯式的同步

36.黑板

使用黑板來協調工作流：使用黑板來協調不相關的事實和代理人，能同時保持參與者之間的獨立性和孤立性。

37.聽從蜥賜腦

聽你內心的蜥蜴：當編程舉步維艱時，其實是潛意識在告訴你有什么地方不對。

38.巧合式編程

不要依賴巧合編程：只能依賴可靠的事物。注意偶然事件的復雜性，不要混淆快樂的巧合與有目的的計劃。

39.算法速度

評估算法的級別：在開始編程前，對這件事情大概會花多長時間要有概念

對估算做測試

40.重構

盡早重構，經常重構：像除草和翻整花園那樣，只要有需要就對代碼進行重新編寫、修訂和架構，以便找到問題的根源并加以修復。

41.為編碼測試

測試與找Bug無關

測試是代碼的第一個用戶

42.基于特性測試

使用基于特性的測試來校驗假設

43.出門在外注意安全

保持代碼簡潔，讓攻擊面最小：復雜的代碼給Bug以滋生之沃土，給攻擊者以可趁之機。

44.事物命名

好好取名，需要時更名：用名字向讀者表達你的意圖，并且在意圖改變時及時更名。

45.需求之坑

無人確切知道自己想要什么：軟件開發更像是一種由用戶和程序員協同創造的行為。

46.處理無法解決的難題

不要跳出框框思考找到框框：在面對無法解決的難題時，識別出真正的約束。可以問自己∶"必須這樣做才能搞定嗎? 必須搞定它嗎?"

47.攜手共建

不要一個人埋頭鉆進代碼中：編程往往困難又費力，找個朋友和你一起干。

敏捷不是一個名稱

敏捷有關你如何做事

48.敏捷的本質

個體和互動高于流程和工具

工作的軟件高于詳盡的文檔

客戶合作高于合同談判

響應變化高于遵循計劃

49.務實的團隊

維持小而穩定、全功能的團隊：團隊應保持穩定、小巧，團隊中的每個人都應相互信任、互相依賴。

49.椰子派不上用場

做能起作用的事，在用戶需要時交付：不要卡著流程要求，刻意等到幾周甚至幾個月后才交付。

50.務實的入門套件

使用版本控制來驅動構建、測試和發布

盡早測試，經常測試，自動測試

直到所有的測試都已運行，編碼才算完成

使用破壞者檢測你的測試

測試狀態覆蓋率，而非代碼覆蓋率

每個Bug只找一次

不要使用手動程序

51.取悅用戶

取悅用戶，而不要只是交付代碼：為用戶開發能夠帶來商業價值的解決方案，并讓他們每天都感到愉快。

52.傲慢與偏見

在作品上簽名：過去的工匠在為他們的作品簽名時非常自豪，你也應該這樣。

開發者

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。