(羅恩發表於2002-10-29 8:16:01)
1） 學習應該從基礎打起，不要一開始就嘗試最高深的技術。
2） 每看一本書，不要說這章我以前學習過了，也掌握的很好，因此我可以跳過這一章看更
重要的了。
3）對於作業，遇到不會的盡量不要立刻向別人請教。如果實在解決不了的問題，可以先完成你會的，然後把一些特別的難點提煉出來，向高手請教。
4）不要指望書本和行家能幫你解決一切問題，因為並不是所有問題都能由別人教給你。
5）向別人請教問題應該把問題說明白。對於錯誤提示資訊應該原樣提供出來，不要按自己理解的資訊提供。因為既然你自己做不了，說明你理解一般都有問題。
6）問問題最好能帶**。
7）不要說「編譯通過，可是執行時..."，因為編譯錯誤和執行錯誤可能根本沒有關係。一般來說，編譯是語法問題，而執行是邏輯問題。
8) 書看千遍不如做程式一遍，應該盡量嘗試去寫程式。
9）做程式千個不如做好程式乙個。應該盡量完善你現在做的程式，而不要不斷開新的計畫，而每個計畫都虎頭蛇尾。
10）要想到你不是乙個人寫程式，而是和大家一起寫程式。
11）高深的技巧雖然顯示了高深的本領，但是對於合作往往是有害的，應該盡量寫出簡單易讀的**。
12）編制程式應該盡量做到自注釋，即**本身一讀就懂，好象自己在說明自己的邏輯一樣。
13）複雜的**如果實在做不到自注釋，應該給出適量的注釋。
14）注釋在修改**的時候應該相應修改，不能用陳舊的注釋去誤導別人。
15)**應該盡量可重用，相同功能的**應該由相同的函式完成，重要函式應該給出除錯資訊，以便除錯時及早發現問題。
16）應該盡量寫小函式，每個函式盡量不要超過40行或者更少。這樣不用滾動螢幕也許就可以讀完整個函式。
17）對於switch語句，盡量不要有過多的分支，如果分支太多，可以考慮用跳轉表。
18）盡量少使用一些有爭議的語句，如goto和三目運算子，既然有爭議，它肯定有一定的缺點。
19）對於goto，許多任務程師技術高到可以合理使用，而不至於導致問題。但是你的程式並不一定給你同水平的人看和修改，他們可不能保證合理的讀和修改這些相關**。
20)**編寫時應該有一定的格式，其基本要求是對理解**有一定幫助。
21）如果資料是多個模組共有的，應該提供乙個封裝的類來管理它，並提供乙個合適的介面給各個模組。這樣，如果資料內容有重大修改，則只要介面不變，基本上可以保證程式不要很複雜的修改。
22）應該盡量考慮到資料的併發控制。
23）資料的併發控制應該封裝在介面內，而不要暴露給其他模組，這樣可以減少因為併發原因導致的程式死鎖。
24）資料本身結構不可以太複雜。應該盡量把不相關的資料分割成為兩組資料。
25）對於資料量比較大的情況，應該考慮資料庫。
26）資料庫介面應該採用標準odbc或者ado介面，盡量不要根據實際資料庫dbms提供的介面來處理，因為你可能在實際使用中更換dbms。
27）小的資料可以考慮檔案，檔案路徑應該必須設計成相對路徑。
28）在乙個函式中，應該盡量開啟檔案後使用完後立刻關閉，這樣其他程式可能使用檔案。
29）不要嘗試把檔案全部讀到記憶體中，應該分次處理大檔案。
30）編寫程式應該提供相關的測試程式，以提供測試手段。
31）應該考慮**、函式的使用情況，不要超越函式可以使用的範圍使用之。
隨便寫了這麼點，呵呵，應該是比較凌亂的，也不完全，希望大家不要見笑。
感悟生活的一些語錄
1 只有抱著一顆學習的心，年輕才是你的資本，否則，沒有前提的青春注定是一段荒蕪的生命，沒有意義，也沒有價值。2 並不是所有的懂得都在經歷之前，這也就是為什麼生活會有它自己的意義。也並不是所有的珍惜都在失去之後，這也就是為什麼有些幸福沒有遺憾。3 傷害人的永遠都不會是愛情，傷害人的只有人！4 走在沙灘...
面向硬體程式設計的一些思考
一 硬體程式設計 其實說道硬體程式設計，大家肯定乍一聽感覺很難，很高大上，但是我想說的是除了需要了解一些硬體程式設計中對於各種機器工作狀態的理解之外，剩下的就真沒有什麼了，基本都是邏輯and邏輯and實際，說白了就是看文件，理清楚邏輯再加上一些根據實際狀況的除錯就可以很輕鬆的能夠搞定硬體程式設計。硬...
關於教學立意的一些感悟
此次我們一行7人，前往北京參加了全國歷史高階學術會議。會議研討的主題是關於 教學立意 在課堂中的呈現，有8位知名專家就此問題發表了自己的見解。聽後，受益匪淺。特別是在首師大附中觀摩了兩位教師的展示課之後，與會成員坐在一起展開了熱烈的研討。同行與同行火花的碰撞，專家與一線教師思想的交流，不禁讓我對 教...