程序員修煉之道：從小工到專家閱讀筆記2

程序須要遵照的實用主義原則。

重複的危害：若是某個事物在代碼中重複屢次，就可能會在維護過程當中帶來問題，由於改動了一處而忘記改動另外一處形成自相矛盾。這加大了維護難度。要遵照DRY原則，即Don’t repeat yourself。

重複一般由這些東西引發：

強加的重複，由文檔或用戶需求決定。這一般能夠依照狀況消除。須要重複表示的信息能夠用元數據schema與代碼生成器消除重複。註釋與代碼會重複，但實際上這種重複沒有必要：註釋不該重複代碼中顯而易見的東西，而應該表達更高級的東西。文檔與代碼也會重複，能夠利用文檔生成工具。有些語言會強加一些重複，這比較難解決，只能依狀況而定，一些基本的技術是cpp中不要在其餘文件中引用函數，而應該使用頭文件。

無心的重複，由設計的疏忽形成，須要積極的檢查和重構。若是爲了性能須要違反DRY原則，記得將重複本地化，不要泄漏到模塊外，並保持模塊內行爲良好。

無耐性的重複，可能形成遠大於一時麻煩的痛苦後果。程序員要學會約束本身。

開發者之間的重複，須要增強開發者之間的溝通。

正交性：指系統各同層次的組件之間沒有依賴關係，改變一個不影響另外一個。若是系統不符合正交性，測試與維護會很是痛苦。而正交性的系統在出問題時更容易隔離修復，進行拓展時也沒必要改動已有模塊，增長了生產力。

爲了達到正交性，須要將團隊分爲幾個清晰的小組分別工做，對系統進行模塊化的設計。能夠經過詢問「討論某個改動時須要設計多少人」判斷小組分工是否正交，經過詢問「改動某個模塊背後的需求，會有多少模塊受到影響？」判斷系統設計是否正交。

引入第三方庫時可能會破壞正交性，要當心不要使第三方庫對總體代碼形成改動。若是第三方庫的接口存在問題，能夠將第三方庫用適合本身代碼的方式進行封裝。

編碼也有可能破壞正交性，須要注意：使代碼保持解耦，除了須要的功能不要暴露其它細節。避免使用全局數據。避免編寫類似的函數。

對項目進行測試與debug也能夠檢查項目的正交性。若是測試或修正一個小模塊會帶來許多其它的影響，那麼系統不夠正交。

正交性一樣適用於文檔，文檔內容與表達形式應該解耦。這讓我想到了markdown……

可撤銷性：許多需求會改變，許多政策會改變，因此編寫項目時任何決策都應該能夠撤銷。項目結構應該保持靈活，不要依賴某個已有決策。

曳光彈：這個比喻有點晦澀。做者介紹了一種方法，編碼之初先搭建一個大體框架，而後慢慢填充編碼。這樣既能夠方便編碼，又能夠隨時與用戶溝通項目是否符合他們的需求。假如現有成果不符合需求，能夠立馬進行修改，而沒必要等代碼基本固定時候再進行重構。

原型與便箋：不一樣於曳光彈，曳光彈在使用以後繼續保留，只是逐漸「生長」成更完整的系統。原型是爲了分析某個功能或需求創建的簡化模型，將細節遮蔽以方便分析，用來找到最好的實現方式，而後便丟棄不用。如分析UI需求時先用繪圖板肯定最合適的UI，再用編碼實現。

領域語言：任何領域都有本身的語言，如用於配製的語言，用於文檔的語言，用於描述需求的語言。能夠發展一種小型語言。小型語言分兩種，配置語言方便解析但難以閱讀，命令語言至關於小型的腳本語言，更近似於天然語言，但解析難度更高。小型語言能夠是獨立的語言，也能夠嵌入高級語言的代碼，方便直接執行。

這是一個很是有趣的設想，然而很惋惜，在咱們的項目中，受限於咱們的項目規模，這個設想不太可行。然而這給了我兩個啓發：

進行編程時，首先將用戶需求抽象化。用戶需求經常是用天然語言表達的，一般包含許多複雜的要求，如在某些狀況下將某個數據傳輸到另外一個服務器，在某些狀況下丟棄數據，在某些狀況下反饋警告等。直接試圖將天然語言描述的需求轉化成代碼極可能會很是困難，這時候先將需求抽象成一個無關具體細節實現的邏輯框架會更容易，不論是流程框圖、僞代碼仍是別的什麼。這也是自頂而下的思想。

不少時候編寫代碼須要知足的需求並非用戶的，而是直接對接的下一層的需求。好比負責數據庫層的程序員可能須要知足負責算法層的程序員的需求。在這種狀況下，交流時須要儘可能良好地描述需求的邏輯。這也須要清晰的層與層之間的接口以及風格良好的文檔。

模塊與模塊之間的信息交流須要清晰、易於解析並易於擴展。

估算：要學會估算。估算的方法在於限定問題的情景範圍，對系統創建模型，對模塊進行拆分並分別估算，抹去可忽略不計的量。估算不須要過於精確，但須要細心。