Coding的一些感想

1. 明確模組要實現的功能，著重明確需要提供的介面，並在程式設計中對介面進行思考和改進，力求在其它模組的呼叫過程中，無論本模組如何改動，都不會對其他模組造成影響

2. 編寫**的過程中，應該做好注釋的工作。本人在前期開發的過程中，經常懶得寫注釋，造成以後再用到這部分**時，就會如同重新寫一遍一樣，重新閱讀，明確每個函式的功能，輸入，輸出，以及返回值代表的意義等。

建議：建議養成寫注釋的良好習慣

 在每個函式之前，註明函式功能

 在每個函式之前，註明返回值的意義

 在函式的形參中，註明那些引數是輸入，哪些是輸出，方便呼叫者的使用

 在網路程式設計中，常常會涉及到自己定義資料結構，在一方對資料進行封包，在接收方，進行解包的運算。這種情況下在封包解包的函式注釋中盡量畫出資料報的格式，方便**的閱讀

總之一句話，寫出來的**要具有可讀性和易讀性。

3. 在模組測試時，提供規範的示例**，表明如何對模組的介面進行呼叫，如有需要最好可以附加圖示對呼叫的流程加以說明。

4. 耐心：在除錯程式的過程中，需要靜下心來，認真的將程式所發生的錯誤進行定位，本人常常採用縮小範圍的方式，對錯誤進行定位。比較有用的一種方法，是輸出除錯資訊，可以幫助開發人員確定錯誤發生的位置。

5. 養成良好的記筆記習慣：

在編寫，除錯**的過程中通常會遇到這樣那樣的問題，養成良好的記筆記的習慣，將自己遇到的具體問題和解決方法，記錄下來，方便以後查閱。部落格其實是乙個很好的筆記本哦~~

6. 注重細節問題：

程式設計中經常會由於乙個小的錯誤的疏忽就會導致整個程式的正常執行，如

在函式的形參中涉及到指標問題時，在函式體中在使用之前需要對指標進行判定，以免使用了空指標，或髒資料，對程式的結果造成影響。（如使用assert函式）

不要相信領導給你畫的大餅離開了，就不要回去他說的為你好，都是套路而已你會比你想象的更優秀不要認為提增加工資不好意思，你不提，他永遠不會給你加工資這就看你所處的隊友是怎麼樣的如果隊友是乙個很拼的，可能你需要比他更拼才能出人頭地，當然也要注意方法，不是埋頭苦幹，隊友不知道，領導不知道如果隊...

解決乙個問題，可以靠個人的能力，也可以靠組織的流程，組織的流程就是組織的能力。組織設計流程考慮的是可靠可重用。論解決問題的效率，通過組織的流程大概率是不如靠個人能力的。但組織擁有很多個個人乙個流程可以由多個個人共同完成，對於每乙個參與的個人感受到的可能是組織流程比個人能力解決問題更高...