在這個行業里做了快4年了,多少總結了一些東西,成功也許很難復制,但是失敗卻時常被人們重復,我不敢說我做的很好,但是我希望總結出以前失敗的一些教訓,時不時看看,提醒自己以后再也不要犯類似的錯誤.這篇文章會不定期的更新,可能就是簡短的幾句話,但是,也是我實踐和思考的結果.
1)程序不會出錯,出錯的肯定是人;如果程序出錯了,那也一定是人的錯誤.
我時常在編碼調試的時候出現這樣的一種心理:出現問題的時候總是認為不是自己的錯誤,而認為可能是系統的錯誤.其實,久經考驗的系統出錯的概率幾乎很小,大多數的情況下出錯的肯定是編寫代碼的人,所以你的程序出錯了一定是自己的問題,有了這個觀念會十分有助于早點發現并且改正BUG.
2)程序就是用規則處理數據,規則包括:算法,數據結構,系統API,協議,語言,設計模式等等.
這句話很淺白,我想很多人一看就能明白,其實學習編程的過程就是在學習怎么去用規則去處理數據,想想看一路過來學過的課程都是如此:算法數據結構教會我們在什么情況下應該選取怎樣的方式去處理數據,操作系統教會我們系統如何處理數據,編譯原理教會我們編譯器如何處理數據,網絡協議,語言,正則表達式等等的更不必說了.至今我已經很少去關注什么語言之爭的無聊話題,因為我相信語言也是一種處理數據的工具,沒有哪種工具是萬能的,只有合適的場合采用合適的工具.同時,以后再學習一種新的"規則"時,也需要抓住這些重點:這個規則適用的場合,適用的數據,處理數據的方式.
3)Make it work, make it right, make it effective.
我已經忘記了在哪里看見的這句話(請知情者轉達一聲,謝謝:).中文的意思也很淺白:先讓它可以運行,然后讓它可以正確的運行,最后再去提高效率.我想,這應該是編寫大部分代碼的順序,這也是把一個問題從簡單慢慢的一步一步進行到復雜的過程.在你的代碼沒有正確的運行起來之前,暫時別做優化(當然了很顯然的優化是可以的),只有當程序正確的運行起來時,你通過測試或者工具發現了瓶頸所在再去考慮優化.
4)越早讓你的程序投入調試越好.
一般而言,寫好一段代碼比調試一段代碼的時間要少的多,而許多許多的問題也是在你寫代碼的時候所不能發現的.