常常有人問到怎麼樣纔算一名合格的架構師,又須要掌握哪些設計原則呢?
今天咱們來着重分析一下
函數是程序員的工具中最重要的抽象形式。它們能更多地被重複使用,你須要編寫的代碼就越少,代碼也所以變得更可靠。較小的函數遵循單一職責原則更有可能被重複使用。程序員
應該儘可能減小函數之間的隱式共享狀態,不管它是文件做用域的變量仍是對象的成員字段,這有利於明確要求把值做爲參數。當能明確地顯示函數須要什麼才能夠產生所需的結果時,代碼會變得更容易理解和重用。編程
對此的一個推論是,在一個對象中,相對於成員變量,你更應該優先選擇靜態的無狀態變量 (static stateless variables)。架構
理想的反作用(例如:打印到控制檯、日誌記錄、更改全局狀態、文件系統操做等)應該被放置到單獨的模塊中,而不是散佈在整個代碼裏面。函數中的一些「反作用」功能每每違反了單一職責原則。less
若是一個對象的狀態在其構造函數中僅被設置一次,而且從再也不次更改,則調試會變得更加容易,由於只要構造正確就能保持有效。這也是下降軟件項目複雜性的最簡單方法之一。函數
接收接口的函數(或其餘語言中的模板參數和概念)比在類上運行的函數更具可重用性。工具
尋找機會將軟件項目分解成更小的模塊(例如庫和應用程序),以促進模塊級別的重用。對於模塊,應該遵循的一些關鍵原則是:單元測試
在面向對象編程中,繼承 – 特別是和虛擬函數結合使用時,在可重用性方面每每是一條死衚衕。我不多有成功的使用或編寫重載類的庫的經歷。測試
我的不是測試驅動開發的堅決分子,但開始編碼時先編寫測試代碼會使得代碼十分天然地遵循許多指導原則。這也有助於儘早發現錯誤。不過要注意避免編寫無用的測試,良好的編碼實踐意味着更高級別的測試(例如單元測試中的集成測試或特徵測試)在揭示缺陷方面更有效。編碼
常常看到更好版本的 std::vector或 std::string ,但這幾乎老是浪費時間和精力。一個明顯的事實是 – 你正在爲一個新的地方引入 bug,其餘開發者也不太可能重用你的代碼,由於沒有被普遍理解、支持和測試。spa
每一個程序員都應遵循的最重要的教誨:最好的代碼就是還沒寫的代碼。你寫的代碼越多,你將遇到的問題就越多,查找和修復錯誤就越困難。
在寫一行代碼以前先問一問本身,有沒有一個工具、函數或者庫已經實現了你所須要的功能?你真的須要本身實現這個功能,而不是調用一個已經存在的功能嗎?