分而治之思想，
面對乙個體系很龐大（相對我而言）的程式的開發，首先應將程式合理的劃分一些層次和模組，
不要至上而下的開發，不然可能呆坐半天而下不了手，應該先把下層的小模組做好，再組裝起來，即使組裝的時候發現了很多需要修改的地方，也不是很要緊，利用resharper和vs的強大的重構和提示功能，完成修改並不算困難。
功能的分層和原子化
不要在乙個函式裡面做太多的事情，這句話以前一直聽到，但真正有體會，還是要等到自己實際遇到，我有乙個函式，解析dal物件傳遞的字段，控制任務物件的開啟、關閉執行緒，修改資料庫。但是當我應理解出錯或是需求更新，需要新增和修改功能的時候，就麻煩了。這個函式被改來改去，同時還要修改任務物件的介面，dal解析的內容，函式本身的引數。如果我當時能把這些功能合理的分割下，修改的時候就只需要修改相應地方就可以了。所謂「原子化」意為不可分割，表示這個功能一執行就全部執行，不執行就全部不執行，如果乙個函式的功能是這樣子的，那麼這個函式被修改的可能性就很小了。但是分層也需要注意合理性，不然層次太多，各種跳轉，也是無謂的加大了**的複雜度。
命名規範很重要，
一看就知道是個全域性私有變數，taskstate則可能是個區域性變數，要注意有效範圍了。類名的存放位置同樣如此，依據dal-model（definition）-class的層次存放類檔案，我們引用或檢視的時候，對類的結構首先就有了乙個大致的了解。
不過我老是不記得這點，寫著寫著就忽略了，不過後來發現resharper的命名提示功能不錯，尤其是它還可以自定義不同內容的命名規範，利用這個小工具，一定程度上可以保證名名規範。
雜談 一些廢話
2020 8 18 這好像是我第一篇部落格，感覺想寫就寫了，之前因為覺得markdown，latex 有點麻煩 在我有限的腦容量裡是無法佔據一席之地的，因為太虧了，就連這個 latex 都要用一些奇奇怪怪的符號 導致我註冊好幾個月之後沒有發一篇部落格，甚至還忘了密碼orz，我的問題我的問題qwq 今...
新手的一些廢話 2013 12 26重新補充
面對乙個體系很龐大 相對我而言 的程式的開發，首先應將程式合理的劃分一些層次和模組，不要至上而下的開發，不然可能呆坐半天而下不了手，應該先把下層的小模組做好，再組裝起來，即使組裝的時候發現了很多需要修改的地方，也不是很要緊，利用resharper和vs的強大的重構和提示功能，完成修改並不算困難。寫這...
關於學習設計模式的一些廢話
物件導向的軟體設計中有一些基本原則可以遵守，包括單一職責 開閉原則等，我們運用這些原則，去設計我們的軟體，最後達到的效果是高內聚 低耦合，也就是說各個模組內部聯絡緊密，但是模組之間的聯絡不緊密，只是通過一些公共的api來進行通訊。我們追求高內聚 低耦合的目的是為了使得程式更加易於維護 易於對應客戶的...