1）學習應該從基礎打起，不要一開始就嘗試最高深的技術。
2）每看一本書，不要說這章我以前學習過了，也掌握的很好，因此我可以跳過這一章看更重要的了。
3）對於作業，遇到不會的盡量不要立刻向別人請教。如果實在解決不了的問題，可以先完成你會的，然後把一些特別的難點提煉出來，向高手請教。
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）應該考慮**、函式的使用情況，不要超越函式可以使用的範圍使用之。
1. 紮實的基礎。資料結構、離散數學、編譯原理，這些是所有電腦科學的基礎，如果不掌握他們，很難寫出高水平的程式。據我的觀察，學計算機專業的人比學其他專業的人更能寫出高質量的軟體。程式人人都會寫，但當你發現寫到一定程度很難再提高的時候，就應該想想是不是要回過頭來學學這些最基本的理論。不要一開始就去學oop，即使你再精通oop，遇到一些基本演算法的時候可能也會束手無策。
2. 豐富的想象力。不要拘泥於固定的思維方式，遇到問題的時候要多想幾種解決問題的方案，試試別人從沒想過的方法。豐富的想象力是建立在豐富的知識的基礎上，除計算機以外，多涉獵其他的學科，比如天文、物理、數學等等。另外，多看科幻電影也是乙個很好的途徑。
3. 最簡單的是最好的。這也許是所有科學都遵循的一條準則，如此複雜的質能互換原理在愛因斯坦眼裡不過是乙個簡單得不能再簡單的公式：e=mc2。簡單的方法更容易被人理解，更容易實現，也更容易維護。遇到問題時要優先考慮最簡單的方案，只有簡單方案不能滿足要求時再考慮複雜的方案。
4. 不鑽牛角尖。當你遇到障礙的時候，不妨暫時遠離電腦，看看窗外的風景，聽聽輕**，和朋友聊聊天。當我遇到難題的時候會去玩遊戲，而且是那種極暴力的打鬥類遊戲，當負責遊戲的那部分大腦細胞極度亢奮的時候，負責程式設計的那部分大腦細胞就得到了充分的休息。當重新開始工作的時候，我會發現那些難題現在竟然可以迎刃而解。
5. 對答案的渴求。人類自然科學的發展史就是乙個渴求得到答案的過程，即使只能知道答案的一小部分也值得我們去付出。只要你堅定信念，一定要找到問題的答案，你才會付出精力去探索，即使最後沒有得到答案，在過程中你也會學到很多東西。
6. 多與別人交流。三人行必有我師，也許在一次和別人不經意的談話中，就可以迸出靈感的火花。多上上網，看看別人對同一問題的看法，會給你很大的啟發。
7. 良好的程式設計風格。注意養成良好的習慣，**的縮排編排，變數的命名規則要始終保持一致。大家都知道如何排除**中錯誤，卻往往忽視了對注釋的排錯。注釋是程式的乙個重要組成部分，它可以使你的**更容易理解，而如果**已經清楚地表達了你的思想，就不必再加注釋了，如果注釋和**不一致，那就更加糟糕。
8. 韌性和毅力。這也許是"高手"和一般程式設計師最大的區別。a good programmingis 99 weat and 1ffee。高手們並不是天才，他們是在無數個日日夜夜中磨練出來的。成功能給我們帶來無比的喜悅，但過程卻是無比的枯燥乏味。你不妨做個測試，找個10000以內的素數表，把它們全都抄下來，然後再檢查三遍，如果能夠不間斷地完成這一工作，你就可以滿足這一條。
* 比較寬的知識面，並且能夠時時補充自己的知識和完善自己的知識結構
* 耐心好，特別是在除錯和學習階段，世界上沒有聰明的人只有刻苦的人。做開發其實就兩件事情學習和改錯，在這兩件事情中間的開發過程其實是比較簡單的
* 永遠記住：**是給人看的而不是給機器執行的，計算機在執行程式時是不怕累的，而人在看**時是非常累的
* 良好的編碼習慣，至少保證自己能夠隨時看懂幾個月前自己所寫的**
* 盡量讓你的**能夠很容易的被別人理解，寫**時想想你會不會在兩個月後被別人罵
* 不要容忍自己犯重複的錯誤和寫重複的**
* 知道如何做比得到**更重要
* 盡量不要做已經有很多人已經做過的事情
* 學會尊重別人的開發成果，除非不得已不要下決定全面替換以前的系統
* 珍惜自己的時間與工作成果，盡量讓別人分享自己的開發成果
* 避免假設，多思考極端情況與引起錯誤的可能性，努力減少低階錯誤
* 不要相信至少是不要輕信自己為自己所做的測試結果
* 懂得堅持自己的開發思路，並懂得理解與吸收別人的思想
* 學會與其他人保持一致，但不能放棄自己的開發特色
* 懂得向你周圍的人學習，不論是開發能力上的還是開發經驗上的
* 懂得軟體結構的的重要性，分析**前先分析**的結構
* 學會總結，定期總結自己所學會的知識，看看自己前段時間因為各種原因所浪費的時間
* 學會計畫，盡量不要認為通過延長自己的工作時間來完成任務
* 學會正確估計自己的能力和工作時間
下面這些是我認為一些比較適合我自己的方面，不一定對每個人都合適：
* 多看些雜誌，沒事情的時候可以看看以前看過的參考書，書中很可能有你以前沒有注意到的一些細節
* 不要太早去做一些與開發無關的事情，因為學習的**時期是很短暫的
* 學會分析別人的系統，多看看別人所開發的系統的先進的一面。這裡包括別人的開發思路，實現時所採用的結構
* 時常感到自己將被淘汰，經常埋怨自己的不努力
* 知道自己缺少什麼
* 強迫自己做一些自己不喜歡做的事情，比如說寫文件
* 能夠有勇氣重寫自己所開發的系統，但當你重做時你應該採取和前一次不同的工作方式和方法，否則重做就沒有必要
* 將問題簡單化而不是複雜化
* 將維護時會產生的一部分問題轉移到開發時或是設計時來解決
* 有時候也不妨問問自己：我不做開發時去做什麼
* 堅持為自己做每週的開發計畫，在事情沒有做完以前不要輕易轉移自己的注意力
* 盡可能多的將你所做的教給別人，因為你有一天可能不再負責這個系統
* 做事一定要有始有終，除非是有不得已的理由否則不要在工作完成前提前離開
* 不要將你為公司做的東西帶走，你因該帶走的是開發經驗和對開發的認識而不是**和產品
* 感到累時就休息一下，給自己放個假也無妨，畢竟人不是機器
如何成為優秀程式設計師
1，文件習慣 文件是乙個軟體系統的生命力。乙個公司的產品再好 技術含量再高，如果缺乏文件，知識就沒有繼承，公司還是乙個來料加工的軟體作坊。作為 程式設計師，必須將30 的工作時間寫用於技術文件。沒有文件的程式設計師勢必會被淘汰。2，模組化思維能力 要想成為乙個優秀的程式設計師，他的思想不能僅僅只在侷...
如何成為優秀的程式設計師 （二）
1.紮實的基礎。資料結構 離散數學 編譯原理，這些是所有電腦科學的基礎，如果不掌握他們，很難寫出高水平的程式。據我的觀察，學計算機專業的人比學其他專業的人更能寫出高質量的軟體。程式人人都會寫，但當你發現寫到一定程度很難再提高的時候，就應該想想是不是要回過頭來學學這些最基本的理論。不要一開始就去學oo...
如何成為優秀的程式設計師 （三）
比較寬的知識面，並且能夠時時補充自己的知識和完善自己的知識結構 耐心好，特別是在除錯和學習階段，世界上沒有聰明的人只有刻苦的人。做開發其實就兩件事情學習和改錯，在這兩件事情中間的開發過程其實是比較簡單的 永遠記住 是給人看的而不是給機器執行的，計算機在執行程式時是不怕累的，而人在看 時是非常累的 良...