所以，如何使**變得更好？
好的**可以被識別為易於閱讀、理解、除錯和修改的**，而且最重要的是很少有缺陷。顯然，編寫好的**需要花費更多的時間，但從長遠來看，它也有更多的價值，因為維護成本更低，而且更易於重用。
事實上，我們可以將好的**與可重用的**等同起來，這是在這裡列出的許多技巧背後的驅動原則。**可能實現您的短期目標，作為乙個特定功能的程式設計師，但是如果沒有其他人希望重用它(包括您未來的自己)，那麼它一定是缺少某種方式。要麼它太複雜，太具體，太可能在不同的環境下崩潰，或者不能被其他程式設計師所相信。
我發現，不斷嘗試將下面的最佳實踐應用於您所編寫的所有**(包括您的實驗和原型)，無論您的經驗水平如何，都能帶來更好的**。
1、遵循單一責任原則
函式是程式設計師最重要的抽象形式。它們可以重用的**越多，編寫的**就越少，它們的可靠性也就越高。更小的函式遵循單一責任原則更有可能被反覆使用。
2、減少共享狀態
您應該隱式最小化函式之間的共享狀態，無論它是檔案範圍的變數還是物件的成員字段，都有利於明確要求的值作為引數。當**明確了該函式需要什麼來產生期望的結果時，**就變得更容易理解和重用。
在這種情況下，你應該更喜歡靜態無狀態變數，而不應該選擇物件上的成員變數。
3、區域性化***
理想的***(例如，列印到控制台、日誌記錄、改變全域性狀態、檔案系統操作等等)應該放在單獨的模組中，而不是分散在整個**中。功能上的***常常違反單一責任原則。
4、喜歡不可變物件
如果乙個物件的狀態在其建構函式中被設定一次，並且再也不會發生變化，那麼除錯就變得容易得多了，因為只要構造正確仍然有效。這是減少軟體專案複雜性的最簡單方法之一。
5、介面/類
接受函式的介面(或在c++中使用模板引數或概念)比在類上執行的函式更具有可用性。
6、將好的原則應用於模組
尋找機會，將軟體專案分解為更小的模組(例如，庫和應用程式)，以支援模組級的重用。模組的一些關鍵原則是：
1.最小化的依賴性
2.每個專案都應該有乙個明確的職責
3.不要自我重複
你應該努力使你的專案小巧而明確。
7、避免深度繼承
在物件導向程式設計中，繼承，尤其是虛函式中，在可重用性方面往往是乙個死胡同。我幾乎沒有成功地編寫或使用那些過載類的庫。
8、在設計和開發過程中進行測試
我並不是測試驅動開發的核心支持者，但是當您開始編寫測試**時，編寫測試自然遵循了許多指導原則。它還可以幫助我們更早地發現n個錯誤。但是，要避免編寫無用的測試，良好的編碼實踐意味著更高階別的測試(例如：整合測試或單元測試的特性測試)在揭示缺陷方面更有效。
9、更喜歡標準的庫，而不是手寫的庫
我不能告訴你我多久看到乙個更好版本的std::vector或std::string，但它幾乎總是浪費時間和精力。除了你正在引入乙個新的bug地方（參見10）外，其他程式設計師不太可能重用您的**，而不是被廣泛理解，支援和測試。
結束語我發現，程式設計是一種非常類似於學習藝術形式或運動的技能，你通過有意識的練習和向他人學習而變得更好。不斷努力提高你的**質量將有助於你成為更高效的程式設計師。
譯自：cdiggins.github.io/
譯文：blog.csdn.net/xiaole0313/…
blog.csdn.net/xiaole0313
【qq技術群】279126311 [未]
【qq技術群】484572225 [未]
30多年的編碼經驗濃縮成的 10 條最佳實踐
英文 christopher diggins 譯文 開源中國 my.oschina.net editorial story blog 1525762 所以，如何寫出一手好 良好的 更易於閱讀 理解 除錯和修改，最重要的是它的缺陷也更少。顯然，編寫良好的 需要更多的時間，但是從長遠來看，它也具有更多的...
30多年程式設計師生涯經驗總結
在我30多年的程式設計師生涯裡，我學到了不少有用的東西。下面是我這些年積累的經驗精華。我常常想，如果以前能有人在這些經驗上指點一二，我相信我現在會站得更高。這是我在我的第乙份工作上面學來的。只有當我們給客戶展示產品的時候，他們才會意識到哪些是必須的。給出乙個功能性原型設計遠遠比一張長長的文字 要好。...
30多年程式設計師生涯經驗總結
這是我在我的第乙份工作上面學來的。只有當我們給客戶展示產品的時候，他們才會意識到哪些是必須的。給出乙個功能性原型設計遠遠比一張長長的文字 要好。安全防禦現如今是全世界都在關注的大課題 大挑戰。我們必須時時刻刻積極完善它，因為黑客只要有一次成功，就可以徹底打敗你。假設有黑客會徹底破壞你的防禦系統，那你...