程式設計中的感悟

      1.　學習應該從基礎打起，不要一開始就嘗試最高深的技術。

　　2.　每看一本書，不要說這章我以前學習過了，也掌握的很好，因此我可以跳過這一章看更重要的了。

　　3.　對於作業，遇到不會的盡量不要立刻向別人請教。如果實在解決不了的問題，可以先完成你會的，然後把一些特別的痛點提煉出來，向高手請教。不要指望書本和行家能幫你解決一切問題，因為並不是所有問題都能由別人教給你。

　　4.　向別人請教問題應該把問題說明白。對於錯誤提示資訊應該原樣提供出來，不要按自己理解的資訊提供。因為既然你自己做不了，說明你理解一般都有問題。

　　5.　問問題最好能帶代碼。

　　6.　不要說“編譯通過，可是運行時..."，因為編譯錯誤和運行錯誤可能根本沒有關係。一般來說，編譯是文法問題，而運行是邏輯問題。

　　7.　書看千遍不如做程式一遍，應該盡量嘗試去寫程式。

　　8.　做程式千個不如做好程式一個。應該盡量完善你現在做的程式，而不要不斷開新的計劃，而每個計劃都虎頭蛇尾。

　　9.　要想到你不是一個人寫程式，而是和大家一起寫程式。

　　10.　高深的技巧雖然顯示了高深的本領，但是對於合作往往是有害的，應該盡量寫出簡單易讀的代碼。

　　11.　編製程式應該盡量做到自注釋，即代碼本身一讀就懂，好象自己在說明自己的邏輯一樣。

　　12.　複雜的代碼如果實在做不到自注釋，應該給出適量的注釋。

　　13.　注釋在修改代碼的時候應該相應修改，不能用陳舊的注釋去誤導別人。

　　14.　代碼應該盡量可重用，相同功能的代碼應該由相同的函數完成，重要函數應該給出調試資訊，以便調試時及早發現問題。

　　15.　應該盡量寫小函數，每個函數盡量不要超過40行或者更少。這樣不用滾動螢幕也許就可以讀完整個函數。

　16.　對於switch語句，盡量不要有過多的分支，如果分支太多，可以考慮用跳轉表。

　　17.　盡量少使用一些有爭議的語句，如goto和三目運算子，既然有爭議，它肯定有一定的缺點。

　　18.　對於goto，許多工程師技術高到可以合理使用，而不至於導致問題。但是你的程式並不一定給你同水平的人看和修改，他們可不能保證合理的讀和修改這些相關代碼。

　　19.　代碼編寫時應該有一定的格式，其基本要求是對理解代碼有一定協助。

　　20.　如果資料是多個模組共有的，應該提供一個封裝的類來管理它，並提供一個合適的介面給各個模組。這樣，如果資料內容有重大修改，則只要介面不變，基本上可以保證程式不要很複雜的修改。

　　21.　應該盡量考慮到資料的並發控制。

　　22.　資料的並發控制應該封裝在介面內，而不要暴露給其他模組，這樣可以減少因為並發原因導致的程式死結。

　　23.　資料本身結構不可以太複雜。應該盡量把不相關的資料分割成為兩組資料。

　　24.　對於資料量比較大的情況，應該考慮資料庫。

　　25.　資料庫介面應該採用標準ODBC或者ADO介面，盡量不要根據實際資料庫DBMS提供的介面來處理，因為你可能在實際使用中更換DBMS。

　　26.　小的資料可以考慮檔案，檔案路徑應該必須設計成相對路徑。

　　27.　在一個函數中，應該盡量開啟檔案後使用完後立刻關閉，這樣其他程式可能使用檔案。

　　28.　不要嘗試把檔案全部讀到記憶體中，應該分次處理大檔案。

　　29.　編寫程式應該提供相關的測試程式，以提供測試手段。

　　30.　應該考慮代碼、函數的使用方式，不要超越函數可以使用的範圍使用之。