第一篇：一個C++程序員的心得（大全）

六年前，我剛熱戀“面向對象”（Object-Oriented）時，一口氣記住了近十個定義。六年后，我從幾十萬行程序中滾爬出來準備寫點心得體會時，卻無法解釋什么是“面向對象”，就象說不清楚什么是數學那樣。軟件工程中的時髦術語“面向對象分析”和“面向對象設計”，通常是針對“需求分析”和“系統設計”環節的。“面向對象”有幾大學派，就象如來佛、上帝和真主用各自的方式定義了這個世界，并留下一堆經書來解釋這個世界。

有些學者建議這樣找“對象”：分析一個句子的語法，找出名詞和動詞，名詞就是對象，動詞則是對象的方法（即函數）。

當年國民黨的文人為了對抗毛澤東的《沁園春·雪》，特意請清朝遺老們寫了一些對仗工整的詩，請蔣介石過目。老蔣看了氣得大罵：“娘希匹，全都有一股棺材里腐尸的氣味。”我看了幾千頁的軟件工程資料，終于發現自己有些“弱智”，無法理解“面向對象”的理論，同時醒悟到“編程是硬道理。”

面向對象程序設計語言很多，如Smalltalk、Ada、Eiffel、Object Pascal、Visual Basic、C++等等。C++語言最討人喜歡，因為它兼容C 語言，并且具備C 語言的性能。近幾年，一種叫Java 的純面向對象語言紅極一時，不少人叫喊著要用Java 革C++的命。我認為Java 好比是C++的外甥，雖然不是直接遺傳的，但也幾分象樣。外甥在舅舅身上玩耍時灑了一泡尿，倆人不該為此而爭吵。

關于C++程序設計的書藉非常多，本章不講C++的語法，只講一些小小的編程道理。如果我能早幾年明白這些小道理，就可以大大改善數十萬行程序的質量了。

1.C++面向對象程序設計的重要概念

早期革命影片里有這樣一個角色，他說：“我是黨代表，我代表黨，我就是黨。”后來他給同志們帶來了災難。

會用C++的程序員一定懂得面向對象程序設計嗎？

不會用C++的程序員一定不懂得面向對象程序設計嗎？

兩者都未必。就象壞蛋入黨后未必能成為好人，好人不入黨未必變成壞蛋那樣。

我不怕觸犯眾怒地說句大話：“C++沒有高手，C 語言才有高手。”在用C 和C++編程8年之后，我深深地遺憾自己不是C 語言的高手，更遺憾沒有人點撥我如何進行面向對象程序設計。我和很多C++程序員一樣，在享用到C++語法的好處時便以為自己已經明白了面向對象程序設計。就象擠掉牙膏賣牙膏皮那樣，真是暴殄天物呀。

人們不懂拼音也會講普通話，如果懂得拼音則會把普通話講得更好。不懂面向對象程序設計也可以用C++編程，如果懂得面向對象程序設計則會把C++程序編得更好。本節講述三個非常基礎的概念：“類與對象”、“繼承與組合”、“虛函數與多態”。理解這些概念，有助于提高程序的質量，特別是提高“可復用性”與“可擴充性”。1.1 類與對象

對象（Object）是類（Class）的一個實例（Instance）。如果將對象比作房子，那么類就是房子的設計圖紙。所以面向對象程序設計的重點是類的設計，而不是對象的設計。類可以將數據和函數封裝在一起，其中函數表示了類的行為（或稱服務）。類提供關鍵字public、protected 和private 用于聲明哪些數據和函數是公有的、受保護的或者是私有的。

這樣可以達到信息隱藏的目的，即讓類僅僅公開必須要讓外界知道的內容，而隱藏其它一切內容。我們不可以濫用類的封裝功能，不要把它當成火鍋，什么東西都往里扔。

類的設計是以數據為中心，還是以行為為中心？

主張“以數據為中心”的那一派人關注類的內部數據結構，他們習慣上將private 類型的數據寫在前面，而將public 類型的函數寫在后面，如表8.1(a)所示。

主張“以行為為中心”的那一派人關注類應該提供什么樣的服務和接口，他們習慣上將public 類型的函數寫在前面，而將private 類型的數據寫在后面，如表8.1(b)所示。

很多C++教課書主張在設計類時“以數據為中心”。我堅持并且建議讀者在設計類時“以行為為中心”，即首先考慮類應該提供什么樣的函數。Microsoft 公司的COM 規范的核心是接口設計，COM 的接口就相當于類的公有函數[Rogerson 1999]。在程序設計方面，咱們不要懷疑Microsoft 公司的風格。

設計孤立的類是比較容易的，難的是正確設計基類及其派生類。因為有些程序員搞不清楚“繼承”（Inheritance）、“組合”（Composition）、“多態”（Polymorphism）這些概念。2回頂部 1.2 繼承與組合

如果A 是基類，B 是A 的派生類，那么B 將繼承A 的數據和函數。示例程序如下： class A { public: void Func1(void);void Func2(void);};class B : public A { public: void Func3(void);void Func4(void);};// Example main(){ B b;// B的一個對象

b.Func1();// B 從A 繼承了函數Func1 b.Func2();// B 從A 繼承了函數Func2 b.Func3();b.Func4();}

這個簡單的示例程序說明了一個事實：C++的“繼承”特性可以提高程序的可復用性。正因為“繼承”太有用、太容易用，才要防止亂用“繼承”。我們要給“繼承”立一些使用規則：

一、如果類A 和類B 毫不相關，不可以為了使B 的功能更多些而讓B 繼承A 的功能。

不要覺得“不吃白不吃”，讓一個好端端的健壯青年無緣無故地吃人參補身體。

二、如果類B 有必要使用A 的功能，則要分兩種情況考慮：

（1）若在邏輯上B 是A 的“一種”（a kind of），則允許B 繼承A 的功能。如男人（Man）是人（Human）的一種，男孩（Boy）是男人的一種。那么類Man 可以從類Human 派生，類Boy 可以從類Man 派生。示例程序如下： class Human { ? };class Man : public Human { ? };class Boy : public Man { ? };

（2）若在邏輯上A 是B 的“一部分”（a part of），則不允許B 繼承A 的功能，而是要用A和其它東西組合出B。例如眼（Eye）、鼻（Nose）、口（Mouth）、耳（Ear）是頭（Head）的一部分，所以類Head 應該由類Eye、Nose、Mouth、Ear 組合而成，不是派生而成。示例程序如下： class Eye { public: void Look(void);};class Nose { public: void Smell(void);};class Mouth { public: void Eat(void);};class Ear { public: void Listen(void);};// 正確的設計，冗長的程序 class Head { public: void Look(void){ m_eye.Look();} void Smell(void){ m_nose.Smell();} void Eat(void){ m_mouth.Eat();} void Listen(void){ m_ear.Listen();} private: Eye m_eye;Nose m_nose;Mouth m_mouth;Ear m_ear;};

如果允許Head 從Eye、Nose、Mouth、Ear 派生而成，那么Head 將自動具有Look、Smell、Eat、Listen 這些功能： // 錯誤的設計

class Head : public Eye, public Nose, public Mouth, public Ear { };

上述程序十分簡短并且運行正確，但是這種設計卻是錯誤的。很多程序員經不起“繼承”的誘惑而犯下設計錯誤。

一只公雞使勁地追打一只剛下了蛋的母雞，你知道為什么嗎？

因為母雞下了鴨蛋。

本書3.3 節講過“運行正確”的程序不見得就是高質量的程序，此處就是一個例證。3回頂部 1.3 虛函數與多態

除了繼承外，C++的另一個優良特性是支持多態，即允許將派生類的對象當作基類的對象使用。如果A 是基類，B 和C 是A 的派生類，多態函數Test 的參數是A 的 指針。那么Test 函數可以引用A、B、C 的對象。示例程序如下： class A { public: void Func1(void);};void Test(A *a){ a->Func1();} class B : public A { ? };class C : public A { ? };// Example main(){ A a;B b;C c;Test(&a);Test(&b);Test(&c);};

以上程序看不出“多態”有什么價值，加上虛函數和抽象基類后，“多態”的威力就顯示出來了。

C++用關鍵字virtual 來聲明一個函數為虛函數，派生類的虛函數將（override）基類對應的虛函數的功能。示例程序如下： class A { public: virtual void Func1(void){ cout<< “This is A::Func1 n”} };void Test(A *a){ a->Func1();} class B : public A { public: virtual void Func1(void){ cout<< “This is B::Func1 n”} };class C : public A { public: virtual void Func1(void){ cout<< “This is C::Func1 n”} };// Example main(){ A a;B b;C c;Test(&a);// 輸出This is A::Func1 Test(&b);// 輸出This is B::Func1 Test(&c);// 輸出This is C::Func1 };

如果基類A 定義如下： class A { public: virtual void Func1(void)=0;};

那么函數Func1 叫作純虛函數，含有純虛函數的類叫作抽象基類。抽象基類只管定義純虛函數的形式，具體的功能由派生類實現。

結合“抽象基類”和“多態”有如下突出優點：

（1）應用程序不必為每一個派生類編寫功能調用，只需要對抽象基類進行處理即可。這一招叫“以不變應萬變”，可以大大提高程序的可復用性（這是接口設計的復用，而不是代碼實現的復用）。

（2）派生類的功能可以被基類指針引用，這叫向后兼容，可以提高程序的可擴充性和可維護性。以前寫的程序可以被將來寫的程序調用不足為奇，但是將來寫的程序可以被以前寫的程序調用那可了不起。4回頂部 良好的編程風格

內功深厚的武林高手出招往往平淡無奇。同理，編程高手也不會用奇門怪招寫程序。良好的編程風格是產生高質量程序的前提。2.1 命名約定

有不少人編程時用拼音給函數或變量命名，這樣做并不能說明你很愛國，卻會讓用此程序的人迷糊（很多南方人不懂拼音，我就不懂）。程序中的英文一般不會太復雜，用詞要力求準確。匈牙利命名法是Microsoft 公司倡導的[Maguire 1993]，雖然很煩瑣，但用習慣了也就成了自然。沒有人強迫你采用何種命名法，但有一點應該做到：自己的程序命名必須一致。

以下是我編程時采用的命名約定：

（1）宏定義用大寫字母加下劃線表示，如MAX_LENGTH；

（2）函數用大寫字母開頭的單詞組合而成，如SetName, GetName ；

（3）指針變量加前綴p，如*pNode ；

（4）BOOL 變量加前綴b，如bFlag ；

（5）int 變量加前綴i，如iWidth ；

（6）float 變量加前綴f，如fWidth ；

（7）double 變量加前綴d，如dWidth ；

（8）字符串變量加前綴str，如strName ；

（9）枚舉變量加前綴e，如eDrawMode ；

（10）類的成員變量加前綴m_，如m_strName, m_iWidth ；

對于int, float, double 型的變量，如果變量名的含義十分明顯，則不加前綴，避免煩瑣。如用于循環的int 型變量i,j,k ；float 型的三維坐標（x,y,z）等。2.2 使用斷言

程序一般分為Debug 版本和Release 版本，Debug 版本用于內部調試，Release 版本發行給用戶使用。斷言assert 是僅在Debug 版本起作用的宏，它用于檢查“不應該”發生的情況。以下是一個內存復制程序，在運行過程中，如果assert 的參數為假，那么程序就會中止（一般地還會出現提示對話，說明在什么地方引發了assert）。//復制不重疊的內存塊

void memcpy(void *pvTo, void *pvFrom, size_t size){ void *pbTo =(byte *)pvTo;void *pbFrom =(byte *)pvFrom;assert(pvTo!= NULL && pvFrom!= NULL);while(size--> 0)*pbTo + + = *pbFrom + +;return(pvTo);}

assert 不是一個倉促拼湊起來的宏，為了不在程序的Debug 版本和Release 版本引起差別，assert 不應該產生任何副作用。所以assert 不是函數，而是宏。程序員可以把assert 看成一個在任何系統狀態下都可以安全使用的無害測試手段。

很少有比跟蹤到程序的斷言，卻不知道該斷言的作用更讓人沮喪的事了。你化了很多時間，不是為了排除錯誤，而只是為了弄清楚這個錯誤到底是什么。有的時候，程序員偶爾還會設計出有錯誤的斷言。所以如果搞不清楚斷言檢查的是什么，就很難判斷錯誤是出現在程序中，還是出現在斷言中。幸運的是這個問題很好解決，只要加上清晰的注釋即可。這本是顯而易見的事情，可是很少有程序員這樣做。這好比一個人在森林里，看到樹上釘著一塊“危險”的大牌子。但危險到底是什么？樹要倒？有廢井？有野獸？除非告訴人們“危險”是什么，否則這個警告牌難以起到積極有效的作用。難以理解的斷言常常被程序員忽略，甚至被刪除。[Maguire 1993]

以下是使用斷言的幾個原則：

（1）使用斷言捕捉不應該發生的非法情況。不要混淆非法情況與錯誤情況之間的區別，后者是必然存在的并且是一定要作出處理的。

（2）使用斷言對函數的參數進行確認。

（3）在編寫函數時，要進行反復的考查，并且自問：“我打算做哪些假定？”一旦確定了的

假定，就要使用斷言對假定進行檢查。

（4）一般教科書都鼓勵程序員們進行防錯性的程序設計，但要記住這種編程風格會隱瞞錯誤。當進行防錯性編程時，如果“不可能發生”的事情的確發生了，則要使用斷言進行報警。5回頂部

2.3 new、delete 與指針

在C++中，操作符new 用于申請內存，操作符delete 用于釋放內存。在C 語言中，函數malloc 用于申請內存，函數free 用于釋放內 存。由于C++兼容C 語言，所以new、delete、malloc、free 都有可能一起使用。new 能比malloc 干更多的事，它可以申請對象的內存，而malloc 不能。C++和C 語言中的指針威猛無比，用錯了會帶來災難。對于一個指針p，如果是用new申請的內存，則必須用delete 而不能用free 來釋放。如果是用malloc 申請的內存，則必須用free 而不能用delete 來釋放。在用delete 或用free 釋放p 所指的內存后，應該馬上顯式地將p 置為NULL，以防下次使用p 時發生錯誤。示例程序如下： void Test(void){ float *p;p = new float[100];if(p==NULL)return;?// do something delete p;p=NULL;// 良好的編程風格 // 可以繼續使用p p = new float[500];if(p==NULL)return;?// do something else delete p;p=NULL;}

我們還要預防“野指針”，“野指針”是指向“垃圾”內存的指針，主要成因有兩種：

（1）指針沒有初始化。

（2）指針指向已經釋放的內存，這種情況最讓人防不勝防，示例程序如下： class A { public: void Func(void){?} };void Test(void){ A *p;{ A a;p = &a;// 注意a 的生命期 } p->Func();// p 是“野指針”，程序出錯 } 2.4 使用const

在定義一個常量時，const 比#define 更加靈活。用const 定義的常量含有數據類型，該常量可以參與邏輯運算。例如： const int LENGTH = 100;// LENGTH 是int 類型 const float MAX=100;// MAX 是float 類型 #define LENGTH 100 // LENGTH 無類型 #define MAX 100 // MAX 無類型

除了能定義常量外，const 還有兩個“保護”功能：

一、強制保護函數的參數值不發生變化

以下程序中，函數f 不會改變輸入參數name 的值，但是函數g 和h 都有可能改變name的值。void f(String s);// pass by value void g(String &s);// pass by referance void h(String *s);// pass by pointer main(){ String name=“Dog”;f(name);// name 的值不會改變 g(name);// name 的值可能改變 h(name);// name 的值可能改變 }

對于一個函數而言，如果其‘&’或‘*’類型的參數只作輸入用，不作輸出用，那么應當在該參數前加上const，以確保函數的代碼不會改變該參數的值（如果改變了該參數的值，編譯器會出現錯誤警告）。因此上述程序中的函數g 和h 應該定義成： void g(const String &s);void h(const String *s);

二、強制保護類的成員函數不改變任何數據成員的值

以下程序中，類stack 的成員函數Count 僅用于計數，為了確保Count 不改變類中的任何數據成員的值，應將函數Count 定義成const 類型。class Stack { public: void push(int elem);void pop(void);int Count(void)const;// const 類型的函數 private: int num;int data[100];};int Stack::Count(void)const { ++ num;// 編譯錯誤，num 值發生變化 pop();// 編譯錯誤，pop 將改變成員變量的值 return num;} 6回頂部 2.5 其它建議

（1）不要編寫一條過分復雜的語句，緊湊的C++/C 代碼并不見到能得到高效率的機器代碼，卻會降低程序的可理解性，程序出錯誤的幾率也會提高。

（2）不要編寫集多種功能于一身的函數，在函數的返回值中，不要將正常值和錯誤標志混在一起。

（3）不要將BOOL 值TRUE 和FALSE 對應于1 和0 進行編程。大多數編程語言將FALSE定義為0，任何非0 值都是TRUE。Visual C++將TRUE 定義為1，而Visual Basic 則將TRUE定義為-1。示例程序如下： BOOL flag;?

if(flag){ // do something } // 正確的用法 if(flag==TRUE){ // do something } // 危險的用法 if(flag==1){ // do something } // 危險的用法 if(!flag){ // do something } // 正確的用法

if(flag==FALSE){ // do something } // 不合理的用法 if(flag==0){ // do something } // 不合理的用法

（4）小心不要將“= =”寫成“=”，編譯器不會自動發現這種錯誤。

（5）不要將123 寫成0123，后者是八進制的數值。

（6）將自己經常犯的編程錯誤記錄下來，制成表格貼在計算機旁邊。小結

C++/C 程序設計如同少林寺的武功一樣博大精深，我練了8 年，大概只學到二三成。所以無論什么時候，都不要覺得自己的編程水平天下第一，看到別人好的技術和風格，要虛心學習。本章的內容少得可憐，就象口渴時只給你一顆楊梅吃，你一定不過癮。我借花獻佛，推薦一本好書：Marshall P.Cline 著的《C++ FAQs》[Cline 1995]。你看了后一定會贊不絕口。會編寫C++/C 程序，不要因此得意洋洋，這只是程序員基本的技能要求而已。如果把系統分析和系統設計比作“戰略決策”，那么編程充其量只是“戰術”。如果指揮官是個大笨蛋，士兵再勇敢也會吃敗仗。所以我們程序員不要只把眼光盯在程序上，要讓自己博學多才。我們應該向北京胡同里的小孩們學習，他們小小年紀就能指點江山，評論世界大事。

第二篇：一個C++程序員的學習經歷

正在上網的時候有這個念頭的，所以急急忙忙找了一些學習編程的高人的感想：

我開始學VC時就是自己一個人在啃，也沒什么人指導，當時沒有條件上網，資料特別少，在書店里隨便買本書就學了，在學VC的過程中走了許多彎路，現在回想起來覺得做了很多無用功。看見大家在這里暢所欲言，有高手也有新入門的ddmm，我也來談談學VC的一點“捷徑”吧，這條“捷徑”純粹走的是C/C++的路子，不考慮學習其他語言。（我只會C/C++，略懂VB和Java，所以對于通過其他語言來切入VC的沒有體驗，不置評論）

1.必須對C/C++非常熟悉

如果C不熟，可以看清華譚浩強的書，經典之作。（學習時間1到2個月，對函數、指針和鏈表須滾瓜爛熟）

如果C++不熟，可以看電子工業出版社的《面向對象的程序設計于C++教程》，張國鋒寫的，既講面向對象的思想又講C++的語法，是我見過的講C++最全最好的書，里面的例子都是精心設計的，值得好好體會。好像清華也出過一本張國鋒的，不過我沒看過。（學習時間2到4個月，關鍵在于理解OO概念和C++中的多態，對此應揮灑自如）

2.最好/應該對Windows結構相當熟悉。

如果你很牛，非要從MFC下手來了解Windows結構，當然也不是不可以，但我以為從MFC來學習Windows有霧里看花的感覺，很容易陷入迷惘中，我吃過這種苦頭，希望后來者不要走這條路。

如果對Windows結構不熟，可以看Microsoft Press的Windosw95 Programing，清華翻譯出版了中譯本《Windows95程序設計》，后來北大翻譯出版了最新的版本。清華版的譯得不錯，北大版的沒看過，好壞不知道。這本書講的是怎么樣用C語言編寫Windows程序，不講什么MFC或OWL的，看過后對Windows能有相當清晰的認識。（學習時間3~6個月，GUI對象和消息很熟，多線程、dll有一定認識）

3.以上兩部為準備工作，OK后就可以continue學習VC了。

學VC看Microsoft Press的《Inside Visual C++》清華翻譯出版了中譯本《Visual C++技術內幕（第四版）》比較容易上手，看《技術內幕》一定要看清華，有一本希望出版社翻譯出版的第五版技術內幕翻譯的太爛了，看希望的不如直接看英文原版。（學習時間4到7個月）

4.學習VC是為了在Windows平臺下做開發，所以當你對一上三步都很熟后應該進一步深入學習Windows體系才能開發出高性能的Windows程序，你也只有在這個時候才會明白為什么說VC是真正程序員用的工具而VB只是玩具。如果你在finish第三步之后已經忘記怎樣在Windows下用C語言編寫一個Windows程序，那么你應該把第2步Refresh一下。在這一層次應該深入研究Windows操作系統內的進程、線程、虛擬內存等知識，還應該了解Windows網絡程序的設計。這一步推薦的書是Microsoft Press的《Advanced Windows》清華翻譯出版了此書的中譯本《Windows高級程序設計（第三版）》，讀此書時很多東西有相見恨晚的感覺。機械工業出版社翻譯出版的《Windows核心編程》是這本書的第四版，結構上重新組織過了，內容沒有細看過，應該還可以。網絡編程有一本也是MicrosoftPress的，好像是叫《Windows Network Program》吧，機械工業出版社翻譯出版了此書的中譯本《Windows網絡編程》還不錯的。

5.往后你就看自己需要了，有興趣可以學習COM/DCOM/COM+，這套東西是現在Windows系統的核心架構。

用VC學VC兩年了，自認為不是什么高手，精通更談不上了，因為VC的功能實在太強大了。我只想談一談自己的學習過程和體會，總結一下自己的編程之路。

一開始也和大家一樣，對VC、VB、DELPHI、JAVA非常感興趣，但是學什么好呢？畢業設計來了，導師要求要么用VB要么用VC，聽說VC難學但很有用，于是狠狠心用VC吧。對于一個對編程一點都不感興趣的人我想他是學不好的，沒有強烈的動力和恒心也很難掌握一門知識。怎么辦呢？你總要畢業吧，這就是我的驅動力，而且編程還可以掙錢：），學吧！

對于一個一點都不懂的人來說，下面的知識應該補一補：程序算法和數據結構，C語言的變量、數組、指針、內存、文件、函數等等基本概念和用法，有的人說學c++可以不用學c，我個人認為還是從C學起好，因為c＋＋對c是兼容的。

有了最根本的編程基礎之后，我們就可以學習c＋＋的編程思想，就是面向對象（oo），自然對于什么是類、對象、成員、成員函數、構造函數、析構函數、虛函數、模板，最開始可能用不上析構函數虛函數什么的，但要想精通深入就必須掌握（當然可以以后再學）。可以說面向對象是c＋＋對c的一個最重要的擴展，而這也恰恰是我們理解和深入的基礎，這部分越扎實以后理解和掌握就越快。

再下來就是MFC了，MFC是一個很好的封裝類庫，它誠如大家所說對用戶屏蔽了很多實現機制，以致很多人只知其所以然，而不知其然。要想知其所以然，當然是學習windows編程，熟悉windows的消息、窗口、api函數。可惜當初我只是為了快，沒有深入地學，留下了現在地惡果，對MFC及其機制仍不甚明了。一則MFC已經封裝好了，二則自己覺得麻煩和累，一大堆長長的函數名和長長的函數參數把我嚇暈了，大家千萬不要學我^-^。基本觀點就是如果只求使用，不學api也可以，如果想做得更好精通，非學不可。對于MFC，對我幫助最大是www.tmdps.cn、程序員大本營、和MSDN，有了這三大法寶加上自己的刻苦鉆研，一定可以成為大蝦。前提是有一定的英文基礎，并且已經知道如MFC frame及application的基本運行機制，對對話框、編輯框、組合框、列表框、進度條、標簽.......等控件的基本功能都自己試過。我就是從這些開始學習MFC的，另外還學了一些和數據庫打叫道的東東，如ODBC之類的，我覺得如果僅僅是界面開發，這些東西還是可以勝任的，都是些簡單易學的在哪里設置什么屬性，添加變量和調用成員函數就行了，不笨的人都會，當然如果你不知道在哪里加又會變得很神秘和難于上青天，夸張了呵呵。這時候你就要查書問別人上internet和幫助網站去找了，具體成員函數的用法可以看MSDN。總之對于沒有學api耿耿于懷，對于沒有了解MFC機制也愧疚于心，因此把自己歸于初級水平還是可以的：

VC是一個開發工具和環境，在你需要的時候你可以邊學邊用。比如你要編網絡方面的東東，好！先去看看別人是怎么做的，有哪些基礎，另外你自己也要針對需求學一些網絡知識。微軟的主頁還是不錯的，英文好的話可以找到很多很好的東東。你要編關于數據庫的程序，請先了解一下數據庫的基本概念和它們在VC中的使用。你可能還有各種各樣的編程需求，如游戲、小程序、動態連接庫、靜態連接庫，COM,ActiveX等等，學習吧，這是唯一的捷徑。我的體會是，邊學邊用，邊用邊學。學習先打好一定的基礎，磨刀不誤砍柴功，看似浪費時間實則受益匪淺。學習要利用一切可以利用的資源，書（包括電子的，不過我很少看電子版本）、BBS、網站（比如VChelp）和高手，勤學好問，搜索不倦，想必你肯定也會成為高手的：）。書我是狂看、亂看、瞎看，主要是沒有條件和時間，當時也沒人指點應該看那一本好書，原則就是找到自己需要的東西的書就可以拿來翻一番（當然我有圖書館這個資源，學生借本書應該沒有問題的）。BBS主要去精華區溜達溜達，里面都會有你要問的一般性問題，如果實在找不到答案，請去codeguru，微軟網站和MSDN查找搜索，應該可以找到蛛絲馬跡。這樣還是很費精，如果有高手指點就不一樣了，他們做過的話，這可能就是小差一疊，隨便說一個關鍵詞就可以幫了你的大忙，可惜高手畢竟是少數，正好碰上做過的高手的概率就更小了。所以各式各樣的網站就顯得那么的重要，它們一天二十四小時都在，而且可能是很多高手都在，因此在它們身上可以找到一些參考答案。問專家我覺得不錯，VChelp更全面和包羅萬象。說了這么多，都是自己的胡思亂想了，一點個人體會，不當之處，各位多多批評指正了*^-^*

下面是我的一些建議,如有不對,請批評指正.謝謝!我想現在大部分的初學者都在問,怎么樣學C/C++最快?確實,這是個比較重要的問題,但對于初學者來說,最重要的,是你對學習C/C++的恒心!學習C/C++并不容易,我想這是每個初學者很清楚的事情.之所以選中C/C++是因為它的涉及面廣,并且強大.但自學想很快掌握C/C++編程那是不太可能的,除非你是個天才,或有專家專門對你進行輔導.如果學習方法和路線正確,的確可以提升學習的速度和效率.下面是我對怎樣學習C/C++的一些看法.總共分三步.第一步.系統的學習C/C++語言,(不要涉及MFC.)并且學習操作系統,對操作系統的運作有清楚的概念.這一階段,可以把重心放到研究算法上.(估計時間將會是一年.如果有人幫助的話,可能會減短.)第二步.開始學習MFC,并選擇發展的方向.一個程序員,很難做到各方面的編程技術都精通,所以要有選擇的學習你感興趣或有錢途的技術發展.如果做游戲,則可放棄對于MFC的學習,因為游戲不需要MFC.(估計時間將會是半年.)第三步.開始對各種技術的涉及.因為本人還沒有考慮到這一步,所以,不做多提,但如果你已經學到了這一步,也不用我再廢話了.(時間未定.)當然,以上的時間估計,是在假設你努力學習的情況下定的,并不具有實際意義.對于書籍的選擇,有很多人想用電子書.我提議,如果是初學,最好不要用電子書,來學習.還有些初學者對于編程工具不知如何選擇.我想無論是C或者是C++,VC都是一種不錯的選擇.如果機器配制不高,可以使用版本低的VC.VC1.52版本是個不錯的選擇.我在工作中，接觸到印度軟件公司開發出來的軟件：整個體系架構非常清晰，按照我們的要求實現了全部功能，而且相當穩定。但是打開具體的代碼一看，拖沓冗長，水平不咋樣。我們自己的一些程序員就有怪話了，說他們水平真低。

但是！印度人能夠把軟件整體把握得很好，能夠完成軟件，并得到相當好的設計文檔。而中國人在那里琢磨數據結構、算法，界面人員就還沒編碼就想著是Outlook式的還是VisualStudio式的界面。到最后就成為Code高手，對某些特定的開發工具精通，但是就是不能保證能夠把一個軟件穩當、完整的開發出來。

舉個簡單的例子：軟件中需要一個列表，用來表示我們處理的事務。該類表在業務繁忙的時候將變得很大。中國人就用雙向鏈表，抱著《數據結構》書在那里寫鏈表的類。印度人開了一個大數組，然后就開始干。為什么印度人不用鏈表，他們說：

1、你們給出的設備(小型機)，最少具備512M內存，浪費一些沒有什么。

2、數組方式訪問方便、效率高。看出了一拿到東西就吭哧吭哧作Code，和好好進行軟件分析的不同了嗎？ 正好前幾天我有幾個同事從印度回來和我們交流,那家公司是CMM4級公司.我感受的幾點:1,流程重于項目2,QC(就是QA)獨立于研發部門,專門檢查研發部門的開發流程是不是按照既定流程走.如果QC覺得流程不對,他會直接上報高層,項目定就此停止.3,所謂的項目經理(PC)一般也是從編碼人員升上來的,并不是所謂的不懂技術,一般都至少有四年以上的經驗4,PC主要就是制定開發計劃,負責協調,填寫各種表格.5,所有的東西(包括草稿)都有文檔.6,詳細文檔要求達到只有這個文檔就可以編碼的程度,一般寫文檔時間占60,編碼時間極少7,有各種詳細的review(同行評審),項目組內的,項目組之間的,客戶的...8,計劃很詳細,的確能達到小時級,但是實際情況還是誤差比較大,所以他們也有加班.先學習UML和Rose以及RU P，不要總是要找著證據。在中國的軟件開發水平下，很難給你一個好的例子，OK？中國人總是要看到一個東西有了試驗田，而且稻子長得好，才換稻種。要知道在國外上述的軟件開發模式的應用，大可以看看Rational網頁上的story。Justdoit!一句話，中國的軟件開發水平低得很。趕不上印度人，印度的軟件公司可以讓高中生編代碼，它的軟件工程水平可想而知。當然，你如果是個很牛的程序員。估計夠嗆，因為中國的氣氛中，很牛的程序員都很難接受軟件工程的。你可以測試一下自己，看看自己適不適合現在學習軟件工程：

1、你是不是不能忍受一個編程序不如你的人做你的項目經理？

2、你是不是覺得你的老板對客戶吹牛皮、夸大自己而感到不舒服?

3、你是不是一個拿到一個需求腦袋里第一念頭就是如何實現的人？

4、你是不是很崇拜Stallman，Linus，很討厭Microsoft?

5、你是不是曾經在深夜編碼的時候，突然感覺到一種乏味，對Code的生涯感到一種無趣？以管窺豹──印度神話作者：“Kino”我們現在處于深深的自卑當中，感到中國的軟件工程水平的低下已經是牽涉到民族劣根性的問題了。

1、他們的軟件教育水平：我們招聘印度人，給應聘者出了一份與國內差不多的試卷，有基礎概念和編程題目。等到他們完成后，我們這些中國的自認高手驚呆了！他們的編程題目簡直象是抄襲的?nbsp;?nbsp;程序結構，注釋，變量命名就不說了吧，全部都是極其類似！反觀中國的牛人、高手，每個人有自己的一套。到了新的崗位，先把前任的程序貶損一通，然后自己再開發更多的問題的代碼來代替。我的公司統計，一個軟件中有4個以上CSocket版本，每個人都覺得別人做得差，自己再搞一套。中國人，就是這個樣子，還會辯解說“我們這樣有創造性”。

其實軟件發展，早就走過了求伯君那個編碼英雄的年代，程序員已經是個坐辦公室的藍領了。你具備擰好一個螺絲釘的能力就可以了。Code是最低級的事情 了。

2、他們許多公司的項目經理根本就不懂技術。中國的項目經理如果不能在技術上壓服下屬，那么下屬將與他搞鬼，越是高手越喜歡搞鬼，根本不知道作軟件的終極目的是從別人兜里掏錢，而在內部搞不團結。技術高手都會糾集一些對他技術上崇拜的菜鳥，與管理層作對。而印度的軟件經理根本就不懂正在做的東西，許多甚至直接就是MBA，或者是領域專家(工業設計、地理專家等)，而不是編碼 的專家。但是卻能夠領導大群素質良好的程序員把工作做好，沒有內部不團結的情況。許多印度的程序員加入一個公司很長時間，都不知道自己整天編的代碼是干什么用的。給他們的任務可能就是一個函數的聲明以及該函數要實現的功能。我們呢？

3、他們的編程人員的流動率達到30!他們的編程人員流動率(包括內部項目之間的流動)高達30，可以想見他們的文檔水平如何。他們的產品不依賴任何一個人，誰都可以立即辭職，產品的開發還是會正常進行。而中國，是老板怕總工。技術骨干擁兵自重，抗拒管理。任何制定好的計劃，都有可能被技術人員推翻或者跟你消極怠工。

4、他們的開發計劃能夠做到小時級別。如果一個印度公司的項目經理沒有上班，那么他的下屬將可能不知道作什么。他們的計劃一般都定到天，每個基層開發人員每天的工作量就是8小時。而我們能夠給出月度計劃的 公司就很少，而給出的月度計劃要么不可能實現，要么就可能被取消。開發人員 被初略的給個任務，他在月初，可以慢慢琢磨是做成什么樣子，然后上上網，聊聊天。到了月中和月末，就開始熬夜編碼。看到每年，從各大高校不盡牛人滾滾來，我們是不得不要召人，同時又是不抱希望。我公司現在有意以后將核心軟件開發外包給印度公司，中國人？做做界面吧，中國人做界面會極盡奇技淫巧，搞得花里胡哨的。BTW，我公司非外企，大家不要誤會我們有什么種族歧視。但是我們現在就是對自己歧視，自卑得很。中科院那么多研究院，連個能用的操作系統都搞不定。北大開發一些東西，比如什么青鳥CASE，就是給一幫人評職稱的。楊芙清院士整天搞來搞去，搞出了什么東西？B大，T大的人最難管理，牛得看不見人。中國的程序員罵微軟，追Linux是全世界最狠的，可是我們除了漢化Linux，做了什么東西出來。CDE是瑞典人寫的，Linus是芬蘭的，GNome是墨西哥人寫的。哎，我們曾經是多么的瞧不起印度人。

現在，越來越多的人開始學習VC了，如果能精通VC，就象精通了九陰真經一樣，可以天下無敵了。我想很多VC愛好者都有這種追求武學至高境界的心理。

我就是抱著這種心理開始學習VC了，至今已近三年了，其間經歷過無數的困惑和磨難.....可是我最終沒有放棄，到如今已經有一定的功力 ：

以下就把我修煉中獲得的經驗與大家分享，一起提升修行！

首先要搞清楚VC能干什么.很多人只是聽說VC是最好的開發語言，便去學習，就象大家聽說辟邪劍譜厲害，便都去搶著學一樣，都是很盲目的。其實語言并沒有好壞之分，我在用C之前，一直覺的BASIC 是最好用的語言。現在在WINDOWS平臺下編程，VB和DELPHI可以滿足大多數的應用，而且速度不會很慢。使用VC主要是用來開發系統軟件和大型工具軟件以及開發游戲。現在比較流行的操作系統主要是WINDOWS系列和UNIX系列。這些操作系統都是復雜的多任務系統，在設計操作系統的時候就提供了一大堆應用編程接口（API，通常是C語言的函數），編程者使用C語言調用這些API便可以開發該系統下的應用程序了。這與DOS時代的 編程接口是不一樣的，那時侯的函數庫是由開發環境提供的（如Turbo C)，不具有很好的封裝性和設備無關性。

每當新版的WINDOWS操作系統發行，便會提供一個相應的plantform SDK(軟件開發包），開發者可以用SDK 編譯C程序。在沒有VC和VB的時候，WINDOWS程序就是用SDK編出來的。

VC跟這些亂七八糟的東西有什么關系呢？

其實VC的核心就是MFC，MFC是個C++類庫，就象結構化程序設計時代的C語言函數庫一樣，給程序員提供了豐富的編程接口，簡化了程序的設計。而MFC就是直接把WINDOWS的C語言編程接口API函數用C++的類封裝而成！這樣既實現了面向對象的編程思想，又直接使用了WINDOWS的原始編程接口，代碼的效率是 最高的！當然很多人不適應C++的編程方法，他們依然使用C語言編寫WinMain()和窗口 過程，VC同樣為他們提供了很大的便利，因為VC可以很方便的管理資源和代碼！

明白了以上關系，學習VC的步驟應該也明確了：首先要學習C語言（如果你還不會的話）！這是非常重要的。如果C語言不懂的話，一切都無從談起。懂了C語言，你就可以研究 WINDOWS系統的工作原理和WINDOWS應用程序的工作原理了。這也非常重要。VC只能用來 開發WINDOWS系列操作系統下的應用程序，如果不懂WINDOWS下的程序的工作原理就去寫WINDOWS 程序，那也是比較盲目的。主要是體會一下WINDOWS的多任務和消息驅動機制。然后就可以使用API編程了。這個過程是比較痛苦的，因為一切都變的復雜起來，你會遇到很多新的方法和概念！比如消息隊列，消息發送，窗口過程，GDI，設備上下文，句柄，線程，消息循環，繪圖對象......當你可以熟練的使用C語言進行WINDOWS程序設計了，你可以嘗試 面向對象的方法了。

這時你需要學習C++語言（最好是ANSI C++），這不是淺嘗則止，你要深入的理解C++語言的精髓！經過一定的努力，你可以用面向對象的思想去考慮問題了，這時一切都水道渠成，你可以很自然的使用MFC來編程了，有時你覺的MFC的類不好用，你可以從頭作自己的類，而不去繼承 MFC！

我每天要收到很多朋友的來信，有很大一部分朋友都詢問學習VC的方法和途徑，還有相當一些朋友對C/C++語言的前途感到擔心，總覺得學習C語言在開發效率上沒有趕上其他的開發工具，今天我就借“開發有感”這個欄目談談我的一些淺見。

首先來講我使用C/C++語言開發已經有六年多的時間了，在使用C以前我是用匯編語言的所以我轉變到C時就很自然和順利。但就目前的情況來講大家都不再需要學習匯編語言了，所以在進入C語言的世界時就會遇到一些困難這主要表現在指針的使用上。由于沒有親身的經歷所以我很難想象這個困難有多大，但我在這點上的建議就是開始時盡量避免使用指針，至于一些必須使用指針的C函數只要記住用法就可以了。當然這種情況不會持續太久，因為但你對語言的熟悉程度增加后自然也就會有使用指針進行開發的需求，那時候如果對指針的用法還沒有深刻的了解再學習也很容易，這就是主動學習與被動學習的區別。

其次很多朋友都問我如何學好VC，我想對于初學者首先應該掌握的是C/C++，VC只是C/C++的一種開發工具。如果是剛接觸C/C++則最好不要使用VC做為開發工具，因為VC的各種特性會分散你的注意力。我建議使用Turbo C++或Boland C++集成平臺做為開發工具，這兩個平臺雖然都是DOS下的但是對于初學者真是在適合不過了（當然MSC也可以）。

此外剛開始時開發一些字符界面的程序（也可以說是DOS程序，Console控制臺程序）來加深對語言的熟悉。在掌握了C/C++語言后就可以開始利用VC編寫基于Windows的窗口程序了，這時候就是一個轉折點，因為這時候Windows系統是基于消息機制的，這和單流程的程序有些區別。所以這時候也不要急著去寫學習開發和寫代碼而是應該先對Windows系統的消息機制做一些了解然后才開始學寫程序。其實我的主張是一開始用基本的SDK形式（也就是用WinMain函數的那種，不用MFC功能）來開發幾個程序做為入門，然后再使用MFC來開發程序。MFC開發的方式與SDK開發方式的最大區別就是MFC隱藏了很多細節，這是優點也是缺點對于初學者來講我認為是一個缺點，所以我建議初學者先用WinMain的形式寫程序，即使不親手寫也可以看幾個基本的程序來加深認識。

上面這些話都是為了說明一個問題“磨刀不誤砍柴工”，學習開發一定要打好基礎，還有一點就是一定要想辦法激發自己的學習積極性讓自己進入一個主動學習的境界。

下面我再分析一下C/C++與其他開發語言之間的差別，C/C++，(object)PASCAL，JAVA，PERL都是我認為比較通用而且是比較好的開發語言，但C的語法比PASCAL自由，PASCAL開發比其他結構化強，但這一點上C語言也能夠做到。至于JAVA和C++非常類似而且能夠跨平臺這一點上是很大的優勢，但JAVA開發的程序效率差。PERL也是一中我很喜歡的開發語言，雖然PERL沒有面向對象的特性（至少我認為它的面向對象很糟糕）但我喜歡PERL中自由的語法和各種時常讓人感到驚奇的用法。

如果說到Windows下的可視化開發工具現在大家接觸得最多的就是VC，VB，DELPHI，BCB，一些可視化開發的JAVA。其實我覺得VC并不能完全算是一個可視化工具，這表現在VC中編寫代碼還是占了開發工作的大部分時間。而其他的可視化工具中都在界面設計中耗費了大量的開發時間。我一直使用VC的原因就是因為我能夠一直將注意力集中在軟件功能開發上而不是界面設計上。我認為這樣能夠在開發的過程中更加自由和有更多的控制權。而且這種情況下產生的代碼維護性更強。舉個簡單的例子，在維護VB代碼時如果沒有一份詳細的說明和流程就會使維護變得不可能，我想其他的基于界面開發的工具都會或多或少的產生這樣的問題，因為在開發過程中開發工具將一個完整的流程分離成為多個部分，在開發完成后這些部分就很難統一起來。

選擇什么樣的工具的前提是你的開發目標，如果你希望開發一個很大的系統你就不應該選擇面向基于界面開發的工具，但你可能會選擇VB來開發前端的客戶軟件，而后臺使用VC來實現。

對于一些并不是很復雜的軟件來講，界面和操作方式可能是非常重要的，所以選擇VB，CBC都可以縮短開發時間。這時候選擇VC就有些不智。

所以我認為使用VC開發的朋友應該將更多的注意力集中在實現軟件功能的流程上，多從整體角度看問題。我想這一點來說其他的可視化開發工具是很難達到的，因為VB，CBC等開發的程序在很大程度上都是用各種控件“堆”出來的，這會在后期的維護升級過程中帶來很多的不便，例如要替換掉一個控件就可能會對整個程序的結構產生非常大的影響。

最后我想說的是每種開發工具都有它的價值，也各有優缺點，更重要的是如何根據具體的任務選擇合適的工具并利用這些工具來完成工作。

軟件開發高手：十年磨一劍

要成為武林高手，需要長時間的勤學苦練。要成為軟件開發高手，又需要多長時間呢？《Modern C++ Design》的作者Andrei Alexandrescu認為：一個人有可能在２０幾歲就成為編程高手，但要成為設計高手卻需要熬到３５歲左右。以２３歲大學畢業計算，要經過漫長的１２年時間。

以我個人為例（我尚不敢自認是設計高手），２２歲大學畢業后，在某研究所用８０８６匯編語言寫一些小規模的程序，頗覺得心應手。凡是能用流傳圖表示的問題，都似乎不在話下。工作中，與同事共同切磋結構化程序設計，并能有意識地用于實踐中。

三年后，承接一個縱向課題：在Windows上開發一個交互式排版系統。用Windows SDK開發。興奮之余，自然想起用結構化方法進行設計：把整個系統當成一個黑盒子（black box），輸出當然是排版結果，不管是什么格式，輸入是···。我卡住了。難道用戶操作是輸入嗎？但用戶操作有那么多，怎么表示呢？系統的數據流圖該怎么畫？數據字典該怎么寫？和同事討論n次后，仍不得其解。懊喪之余，先模仿Quark Express搭個界面吧。然后研究排版算法。程序結構經過至少三次大規模修改，終于能排出一些版式，并在兩年后通過了鑒定（鑒定后當然是將其束之高閣）。我從中體會到結構化開發方法不適合開發交互式系統。在開發初期，你不太可能正確地畫出數據流圖，而結構化設計方法完全依賴數據流圖。數據流圖發生改變，整個程序結構就要隨之改變。

后來，加入一家合資公司，擔任開發組長，有五、六個組員。這時我已讀過了邵維忠等譯的《面向對象的分析》、楊芙清等編譯的《面向對象的設計》和《Code Complete》中譯本。對面向對象的程序設計雖有所了解但仍是一知半解。

首先，我們用MSVC 1.5開發一個圖形編輯軟件。我用紙畫了20幾張對象圖，與同事討論通過后，開始編程。有人負責數據模型，有人負責用戶界面，有人負責圖形顯示。幾個月后，老板已可向潛在用戶進行展示，反應良好。老板和開發人員都被一種興奮的心情籠罩著。我們不斷地加新功能，老板不時地到展覽會上做演示。功能加齊了，開始讓潛在用戶試用。老板和我們都松了一口氣：就剩下改錯了，咱們是兵來將擋、水來土屯，沒什么可怕的。錯誤報告來了。我們信心滿滿地開始查錯改錯。有些錯誤很快地被改掉了。但最后我們發現錯誤源源不斷。改了一個錯誤有可能引起別的錯誤。軟件永遠達不到能用的地步。最后，時機被錯過。該軟件不得不被砍掉。懊喪之余，我們做了反省。大家都認為應盡早改錯。同時模模糊糊地覺得數據模型和用戶界面的程序一定要嚴格分開，否則程序極難修改。

后來，我們又開發一個類似Adobe Acrobat Exchange的PDF文件瀏覽器兼編輯器（當時Acrobat Exchange還不能顯示中、日、韓文）。這時，老板帶來一些過期的《C/C++ Users’ Journal》《Dr.Dobbs’ Journal》雜志。從書評中，我被幾本書吸引住了。一本是James Rumbough等著的《Object-Oriented Modeling and Design》，一本是現在大名鼎鼎的《Design Patterns》，還有就是Scott Meyers著的《Effective C++》和《More Effective C++》。我勸說老板買了這幾本書，并攛掇他買了一個CASE（計算機輔助軟件工程）工具：Select OMT 仔細研讀這幾本書后，頗有頓開茅塞之感。最大的收獲在于了解到降低類之間耦合度的重要性。一個類的實現細節發生變化，不應該影響使用該類的其它類的內部實現。更妙的是有不少Design Pattern能馬上用到我們的軟件中。

我用Select OMT軟件畫了一些高層的類圖、狀態圖和數據流圖等，并讓同事們審查。同事們都覺得通過這些圖對軟件的總體設計有了更好的把握。在寫程序的過程中，我們不斷調整程序結構以盡可能減小類之間的耦合度。老板很早就安排了專職測試人員。發現問題，馬上修改。一年后，我們的軟件終于通過了用戶的試用，賣出去了。當時，我可說是信心滿滿。

此后，我做了一年半多媒體編程。發現還是對系統開發更感興趣。于是加入了Quark軟件公司，開發一個基于CORBA的文件管理系統。這是我第一次參與異地開發，也是第一次大規模使用STL。我驚嘆于STL設計之妙，同時也對自己的信心打了折扣。此后，我閱讀了Martin Fowler著的《UML Distilled》、Bertrand Meyer著的《Object Oriented Software Construction》等書籍。并開始使用Rational Rose。Quark公司的技術文檔管理、設計復查、代碼復查、質量管理以及德國人（Quark公司德國分公司）嚴謹的工作態度都給我留下了深刻印象。

項目組下分開發組和測試組。開發組中有一個４到５人組成的設計小組負責軟件總體設計，其中一個人負責技術文檔，確保文檔反映最新的設計。定期進行設計復查。復查時，項目組成員全部參加，并可提出問題或建議。得出結論后，馬上付諸實施。開發組下又設若干小組。小組內定期進行代碼復查。由組長選出每個組員的源文件，交其他組員復查，盡量挑出所有的毛病。如果代碼太次，要打回從新寫過。代碼復查既能保證軟件質量，又是大家學習的一個機會。

一年半后，我離開Quark，加盟Sybase，參與PowerBuilder的維護和新版本的開發。這是我第一次參與軟件維護，令我認識到軟件維護的重要性，認識到編寫可維護的代碼是軟件開發的一個重要課題。Sybase系統化的質量跟蹤系統和用戶支援系統讓我獲益匪淺。在此期間，我閱讀了《Large-scale Software Development in C++》、Martin Fowler著的《Refectoring》、Andrei Alexandrescu著的《Modern C++ Design》，Herb Sutter著的《Exceptional C++》和《More exceptional C++》，以及Kent Beck著的《Extreme Programming Explained》等書籍。對軟件開發與維護有了進一步了解，但同時也更認識到軟件開發之難。

回想十幾年蹣跚走過的路，好像也略有所悟。試總結出以供參考：

1）要熟練掌握至少一種編程語言。我覺得最好是C++。掌握了C++，學習其它語言如Java或C#等并非難事，因為各種面向對象的程序語言盡管在語法上可能有很大區別，在語義上卻大同小異。

2）不要寄希望于一次就把軟件設計好。在開發初期，要盡量用最簡單的設計實現最基本的功能，以使你的軟件盡早地能實際運行，不要過于拘泥于細節。這樣你才能盡早得到反饋，才能更直觀更全面地理解你所面對的問題。你所關注的重點應依次是Make it work, make it right, make it fast。

3）軟件結構要分塊分層。低層模塊不要依賴于上層模塊。一個類、一個接口或一個函數都應只做一件事。沒有本質聯系的類或接口就不應有耦合關系。舉例而言，要用MVC（Model View Controller）Design Pattern切斷用戶界面與數據模型之間的直接關聯。

4）軟件設計的主要工作是給類分配責任（responsibilities）。盡量不要把類設計成控制者（controller），而要設計成協調者（coordinator）。控制者凡事自己做，協調者讓別人做。控制者的邏輯往往很復雜，難于維護；協調者邏輯簡單，易于維護。要站在類的使用者角度設計類的外部行為。要講究一點軟件美學，即簡單、清晰、一致、平衡等。

5）了解并運用UML、Design Patterns、Unit Test、Design by Contract等。6）使用代碼管理系統和質量跟蹤系統。

7）了解各種軟件開發過程控制方法，并找出適合你的方法。8）閱讀經典書籍，研讀經典代碼，訂閱雜志，與同行切磋。

在這行越久越覺得軟件開發難。軟件開發歷史還很短，才50年，還不是一門系統化的學科。有些人甚至認為軟件設計與編程是一門藝術。但軟件藝術大師還太少，而且我們很難直接欣賞到他們的杰作，除非所有的設計文檔和代碼都公開。軟件更容易藏污納垢。一個用戶界面很漂亮的軟件，內部設計和代碼卻很可能臭不可聞。一個地板傾斜、墻壁裂縫、屋頂漏水的房子沒有人會買。一個設計很爛的軟件卻可能賣得不錯。但這樣的軟件能撐多久呢？ 軟件設計與編程已經很難，而這僅僅是軟件開發的一個方面，軟件開發過程控制也很難，也許更難。成為軟件開發高手要走一條漫長的路，何日才能仗劍走天涯？

第三篇：C++程序員求職信

C++程序員求職信

光陰如水，找工作的黃金時間馬上就要到來，是時候好好地琢磨一下寫求職信的事情了哦。相信寫求職信是一個讓許多人都頭痛的問題，以下是小編幫大家整理的C++程序員求職信，僅供參考，歡迎大家閱讀。

尊敬的公司領導：

您好!

非常感謝您在百忙之中抽出寶貴的時間來垂覽我的求職材料!

我叫xx，是南開大學計算機系的一名本科大學生，即將面臨畢業。懷著對貴公司強烈的渴望和滿懷的激情，我十分希望成為貴公司的一份子!懇請貴公司給我這個機會!我也會向貴公司證明我的能力!

4年多以來，在老師的教育及個人的努力下，我具備了扎實的專業基礎知識，系統地掌握了c++語言、匯編語言、單片機原理、電子電路、計算機組成原理、數據結構、數據庫等有關理論，以及嵌入式系統開發的一些理論，同時也擁有一定的分析和設計能力。通過在校期間的試驗實習和課程設計的訓練我具備了較強的動手能力。

除了對計算機熱愛，在大學四年里我還不斷的學習英語知識，我深切的`感受到當今社會以及計算機行業，沒有過硬的英語能力是不行的，并且將會成為我們事業前進的瓶頸。我在大二上學期就通過了全國大學生英語四級考試。此外，我還積極參加校內的各種活動以及校外的各種社會活動，抓住每一個機會，鍛煉自己的能力。

我通過各種渠道大致了解了貴公司的情況，知道貴公司是個很有發展前途的具有現代潮流的公司，具有很大的活力，而我也非常希望能加入這樣的企業，盡自己最大努力為公司的發展奉獻自己的微薄之力。

我十分熱愛貴單位所從事的事業，殷切地期望能夠在您的領導下，為貴公司添磚加瓦;同時也在您的領導下發揮出我的實力與才能，在實踐中不斷學習、進步，在能力和素質方面進一步完善自我，為貴公司做出更大的貢獻。無論您是否選擇我，我都祝愿貴公司的事業蒸蒸日上!

此致

敬禮！

第四篇：一個老程序員的心得

1個老程序員的心得

[size=4]不知不覺做軟件已經做了十年，有成功的喜悅，也有失敗的痛苦，但總不敢稱自己是高手，因為和我心目中真正的高手們比起來，還差的太遠。世界上并沒有成為高手的捷徑，但一些基本原則是可以遵循的。

1.扎實的基礎。數據結構、離散數學、編譯原理，這些是所有計算機科學的基礎，如果不掌握他們，很難寫出高水平的程序。據我的觀察，學計算機專業的人比學其他專業的人更能寫出高質量的軟件。程序人人都會寫，但當你發現寫到一定程度很難再提高的時候，就應該想想是不是要回過頭來學學這些最基本的理論。不要一開始就去學OOP，即使你再精通OOP，遇到一些基本算法的時候可能也會束手無策。

2.豐富的想象力。不要拘泥于固定的思維方式，遇到問題的時候要多想幾種解決問題的方案，試試別人從沒想過的方法。豐富的想象力是建立在豐富的知識的基礎上，除計算機以外，多涉獵其他的學科，比如天文、物理、數學等等。另外，多看科幻電影也是一個很好的途徑。

3.最簡單的是最好的。這也許是所有科學都遵循的一條準則，如此復雜的質能互換原理在愛因斯坦眼里不過是一個簡單得不能再簡單的公式：E=mc2。簡單的方法更容易被人理解，更容易實現，也更容易維護。遇到問題時要優先考慮最簡單的方案，只有簡單方案不能滿足要求時再考慮復雜的方案。

4.不鉆牛角尖。當你遇到障礙的時候，不妨暫時遠離電腦，看看窗外的風景，聽聽輕音樂，和朋友聊聊天。當我遇到難題的時候會去玩游戲，而且是那種極暴力的打斗類游戲，當負責游戲的那部分大腦細胞極度亢奮的時候，負責編程的那部分大腦細胞就得到了充分的休息。當重新開始工作的時候，我會發現那些難題現在竟然可以迎刃而解。

5.對答案的渴求。人類自然科學的發展史就是一個渴求得到答案的過程，即使只能知道答案的一小部分也值得我們去付出。只要你堅定信念，一定要找到問題的答案，你才會付出精力去探索，即使最后沒有得到答案，在過程中你也會學到很多東西。

6.多與別人交流。三人行必有我師，也許在一次和別人不經意的談話中，就可以迸出靈感的火花。多上上網，看看別人對同一問題的看法，會給你很大的啟發。

7.良好的編程風格。注意養成良好的習慣，代碼的縮進編排，變量的命名規則要始終保持一致。大家都知道如何排除代碼中錯誤，卻往往忽視了對注釋的排錯。注釋是程序的一個重要組成部分，它可以使你的代碼更容易理解，而如果代碼已經清楚地表達了你的思想，就不必再加注釋了，如果注釋和代碼不一致，那就更加糟糕。

8.韌性和毅力。這也許是“高手”和一般程序員最大的區別。A good programming is 99% sweat and 1% coffee。高手們并不是天才，他們是在無數個日日夜夜中磨練出來的。成功能給我們帶來無比的喜悅，但過程卻是無比的枯燥乏味。你不妨做個測試，找個10000以內的素數表，把它們全都抄下來，然后再檢查三遍，如果能夠不間斷地完成這一工作，你就可以滿足這一條。

這些是我這幾年程序員生涯的一點體會，希望能夠給大家有所幫助 做了快三年的程序員了,有一點小體會和大家分享一下.1.好鋼是由鐵煉成的.一名好的程序員必須經過千錘百煉才行, 挫折是程序員最大的寶,要能承受挫折,戰勝挫折,只有不斷經受挫折,從挫折中吸取經驗,教訓,這樣你才能成為真正的程序員.2.手是好漢,眼是懶漢.看會不是目的,要會寫,勤動手,熟練書寫各種常用代碼,在學習之初 可以不借助IDE來書寫代碼,反復練習,熟能成巧,毋庸置疑.3.穩中求勝,小心使得萬年船.程序員最忌諱毛躁.代碼多,項目大的時候,錯誤是在所難免的,但低級錯誤一定不能犯,盡量把錯誤壓到最低,這就要求我們程序員養成穩重,多思維的方式,切忌浮躁,養成良好的書寫習慣和正確的思維方式.4.做就做程序員,不要做高級打字員.每個程序員都是從基礎學起的,在學的時候一定要把握好方向不要被眾多的語言,概念所迷惑,學的是語言,學的是編程思想不要在IDE上下功夫,研究哪個好,哪個壞,要敢于創新,程序是死的人是活的,在活人手里,也要讓程序活起來.多學多看數據結構等書多看別人的成型代碼,學習別人的思想,使自己成為真正的程序員.5.敢想敢做,持之以恒,一切皆有可能！

一點薄思庸見送給賽迪網java版的初學者們,僅代表本人個人意見,如有任何各位大蝦有好的方法或意見可以跟帖提出.java開發八榮八恥

以動手實踐為榮，以只看不練為恥。以打印日志為榮，以出錯不報為恥。以局部變量為榮，以全局變量為恥。以單元測試為榮，以手工測試為恥。以代碼重用為榮，以復制粘貼為恥。以多態應用為榮，以分支判斷為恥。以定義常量為榮，以魔法數字為恥。以總結思考為榮，以不求甚解為恥。

從大學開始到現在，學習編程已經四年了，在過去的四年里學了不少的東西，總感覺自已還行吧。怎么著也能找個好的工作。加上在學校表現良好，大專一畢業就順利應聘上一個政府機構的工作。雖然工資不算多，但也穩定。但總覺得自己有點屈才.一天，見到本市的一家知名軟件企業的招聘信息，就把自己從大學三年到現在寫過的一些東西簡單地寫了一份求職信過去（不是想跳槽，只是想測試一下我現在這份工作丟了,在社會上我能夠達到什么程度）。

沒想到，第二天，那家公司就叫我過去應聘了。感覺很突然，總覺得一些軟件公司在人才網站上打一些招聘信息總是借此做大做廣告，并不是想招聘人，就是要招聘人，可能因為這種因素的機率都很小吧。（這是我一直以來對人才網站上某些軟件公司的招聘信息的看法），不過卻增加了幾分信心,于是我便興沖沖的去了。

到了公司，首先就讓我填寫一張表格，填寫完一張表格以后安排一個技術主管過來與我談，談的倒不是一些深入的技術問題，我基本上的都能應上來。接著就是上機測試。測試的題目是寫一個人員信息的插入、修改、顯示。主考官說只需要寫一個功能就是，只是希望看看我的編程風格。于是我把數據操作寫了一個類，然后在按鈕的事件里得到輸入框值，組合一個SQL，傳到數據操作類里面去執行，然后返回插入結果就可以了。完了，很快搞定。馬上叫主考官過來看吧。呵呵，小意思。

主考官過來了，首先就在姓名的地方輸入好長的一串字符串，接著一陣亂輸，完了，出問題。名字太長了，郵件沒有限制，身份證沒有限制，生日沒有限制，完了，完了，我想，這么點東西，就出問題了，我心里好一陣緊張。還好就是主考官的態度還不錯，說：“雖然你做了足夠的注釋，縮近也注意了，但是卻沒有對輸入的值進行判斷，我們這為合理的判斷也是好的編程風格，再者，你雖然把數據操作寫成了類，但也有很多的改進，一是。。二是。。”說完以后還鼓勵我接著寫剛才的代碼。當時真是很是感動，但感動歸感動，說老實話，這些判斷平時還真的沒有寫過多少，都是寫一個以后，COPY過去COPY過來的用，現在一時還覺得有些短路，不知道如何是好，然后，就是按鈕的事件中寫對數值的判斷。終于完成了，再看看表，時間距剛開始測試已經快一個小時了。

主考官過來看了，覺得功能都實現了，就叫了公司的一個副經理(后來才知道的)來繼續面試我。這個副總就到我到另外的一個會議室去，問了我一些技術概念的問題，結果我基本上都答不過來（我以前覺得我能夠用就夠了啥，沒有太大的必有對這寫概念的條款記得這么清楚啥），結果，那位副經理訓斥了我一下，說：“你對這些概念都不清楚，怎么了解其間的性能呢，不了解性能如何開發高效率的程序呢?”(整個談話這句最讓我滿意，其他的都是“我們是專業的軟件公司，很注重軟件的性能，編程風格等等如事云云”)，最后問了我的薪水要求和能不能適應公司的開發等就叫我回家去等消息。

當然，由于后面沒有過關當然也沒有應聘得上。更當然，我吸取了這次應聘的經驗，總結以下幾條來做為以后學習的信條，寫出來與大家共勉：

一，學習應該從基礎抓起，注意學習的每個細節，爭取學精，避免為了開發而開發。

二，在以一門語言為主功語言的同時，要學習一下與之相關的其它技術。

三，長常保持對新技術的關注，了解未來發展的方向，做到有的放矢。

四，多參與項目開發，在項目中發現問題，解決問題，才能更好的了解學習中的細節問題。

五，加強交流，多寫文章，多發源碼，多收取意見，在交流學習并提高，才能更快了解自已的不足。

六, 永遠相信下一個作品是最好的....業余程序員最喜歡做的一件事就是對不同的語言進行比較。Java是否比C＋＋好？C＃是否會成為終極語言？凡此種種。從專業程序員的角度看來，這是最低級無趣的游戲。

其一，在項目諸元確定之后，通常并沒有選擇語言的余地；其二，語言的生存本身就是一個達爾文主義的問題：設若兩種語言有明確的可比較性，其中較劣的那一種必定早已被淘汰出局，又何來比較的必要？所以，有“C＋＋之父”美稱的Bjarne Stroustrup博士常常聲明自己不會拿C＋＋與其他語言比較——偏偏每次接受采訪時，必定有外行的記者或聽眾提出這一類最令他反感的問題，這是題外話，按下不表。

丟開實用主義的觀點，從美學（或者說，計算機科學）的角度來看，語言的比較似乎并不像它通常所表現的那么低級。畢竟，既然維特根斯坦反復強調“語言制訂游戲的規則”、“凡不可言說者必保持沉默”，可見語言并非僅僅是可通約的思想的映射，語言本身就決定思想的方式。使這個問題顯得那么低級而業余的，往往是業余程序員討論它的方式：僅僅憑著自己對幾種語言一知半解的認識、僅僅憑著使用一種語言的習慣、甚至僅僅憑著一種宗教狂熱來展開討論，這樣的討論自然是不值一哂的。

我是不是已經提到了“宗教狂熱”這個詞？如果說對語言的喜愛（或者憎惡）可以成為一種宗教狂熱，就有那么一些人可以憑著宗教般的狂熱成為開發高手，Ian Joyner無疑屬于這種人。1992年，在Unisys用C＋＋開發UNIXX.500時，Joyner感到C＋＋讓他“不自在”，于是就寫了一篇題為《C＋＋批判》的報告，張貼在Unisys的內部新聞組上。到此為止，一切都沒有什么不同。但Joyner與其他宗教狂熱者的區別在于：他有著遠為深厚的理論基礎，以及鍥而不舍的毅力。于是，《C＋＋批判》有了第二版和在Internet上廣為流傳的第三版。到1998年，這篇典型的論壇文章終于變成了一本書，“批判”也徹底變成了語言之間的比較（參與比較的另外兩種語言是Java和Eiffel），這就是我手上的《對象揭秘：Java、Eiffel和C＋＋》（Object Unencapsulated：Java，Eiffeland C＋＋，人民郵電出版社2003年7月）。

盡管宣稱自己反對“宗教戰爭”，但顯然Ian Joyner是深諳宗教戰爭之道的。從批評的方式來說，他與其他人并無不同：首先立論（“Eiffel是最好的語言”），然后不斷變換角度批評對手——時而是數學理論的完備性、時而是使用的便利和可靠、時而是命名的清晰??論據的選取完全只是為論點服務。也正因為此，這本《對象揭秘》足以讓絕大多數的語言比較者感到羞赧，因為在同樣的批評套路上，Joyner探索的深度和廣度令他們望塵莫及。譬如說，任何一個負責的語言比較者都必然會提到“繼承和類型系統”這一話題，但Joyner卻把這個話題寫成了長達63頁的一章（第5章，“類型擴展：繼承與虛擬”），并在后面的章節（第9章，“類型轉換”）中繼續討論相關的問題。拋開篇幅不談，單是Joyner習以為常的文法解讀、Lamda演算法和簽名變化理論，就足以使不夠水準的批評者自慚形穢了。

因此，在我看來，這本《對象揭秘》完全有理由成為所有語言比較者的必讀書目——也許說“入門書目”會更準確一些？因為你能想到的任何一條批評，Ian Joyner很可能早已做了鞭辟入里的闡述。如果在細讀《對象揭秘》之前妄自作評，結果很可能是貽笑大方。另一方面，在批評的方法上，Joyner為后來者作出了表率：簡單的反對與謾罵毫無意義，用錢鐘書的話來說，“反其道以行也是一種模仿”；只有拿出充足的論據，再拿出合理的解決方案，才稱得上一個高明的批評者。當然，這樣的“入門書目”也許讓門檻顯得太高了一點。但對于“Java和C＋＋誰更好”這樣一個通常只會令人感到莫名煩躁的話題，門檻總是不厭其高的。

像我一樣的Java人常常會抱怨“Java的經典書籍太少了”。C＋＋的經典好書總是層出不窮，實在令人艷羨——當然真正擁有這些書的人也同時擁有不少的煩惱，我就有最深切的體會。在這本《對象揭秘》中，IanJoyner順便也半開玩笑地揭開了這個秘密。也許，這句半開玩笑的話會成為Java人喜愛這本書的另一個理由：

“??學習C＋＋要花那么長時間??，要比Eiffel和Java都長得多。花那么長時間還未必掌握編程或者面向對象設計技術。這也是為什么關于C＋＋的書籍那么多而Eiffel和Java不需要那么多書的原因。”

我是初中時接觸編程的。那時父親廠里買了一臺微電腦，而我父親，當時正好可以接觸到這臺微機，于是，頗具戰略眼光的父親便開始幫我尋找各種書籍資料，讓我學起了計算機。

第一眼看到它，我就被吸引住了。那是在當時也很差的一種名叫“R1”的微機，可是顏色實在漂亮，典雅的奶黃色，配著深綠的按鍵，按下不同的鍵還有不同音調的悅耳的聲音。跟當時風行的大多數八位微電腦一樣，整個機身實際就是一個鍵盤，比現在PC機通常的鍵盤還要小，顯示器就用電視機。當我第一次把從書上抄下來的寥寥幾句的一個Basic程序從嘀嘀作響的鍵盤上敲入，最后再打進了“RUN”，而屏幕上忠實地顯示出了結果后，我就不可救藥地迷上了編程。父親的廠離家有五公里，每個星期天我都要自己一個人步行五公里，把一個星期里自己寫下的一大堆Basic程序拿來調試，當然一大半都被它冷酷的拒絕了，所以每次有一個程序通過了，我都會興奮的叫起來。那時我的體力不好，五公里走下來，相當累，還經常小腿抽筋，可是一坐到電腦前，聽見打開時“嘀”的提示音，一切的痛和累都消失了。

漸漸地我的程序通過率越來越高了，程序的規模也在增長。但是，那臺外表可愛的電腦卻開始不堪重負了，運行速度本來就慢，又加上效率低下的解釋性Basic語言，讓我實在不可忍受。于是，父親又到新華書店為我訂下了一本《Z80匯編語言》的書。書一到，我就捧起這部大塊頭的書，開始用我初中的程度一點點地啃。邊啃邊實驗，終于掌握了Z80匯編語言，又在電腦不具備輸入匯編語言能力的情況下，手工翻譯成機器語言，再通過Basic語言中的Poke語句把二進制代碼輸入內存，然后用Basic程序調用。在不懈的努力下，終于成功地做出了一個匯編語言的動畫程序！在這次成功之后，我就開始相信，只要肯鉆研，沒有學不會的技術，沒有克服不了的難題。

初中畢業后，我以全縣第一的成績進入了一所附近城市的省重點中學，從此我的眼界開始逐漸拓寬了，以后，我用到的電腦越來越高級，從高檔八位機蘋果電腦，到今天主頻以G計，內存以M計的奔四電腦，當年那臺主頻內存都只能以K計的八位機已是進了歷史博物館。但是這臺引領我進入編程領域，并且更驅使我深入鉆研匯編語言的電腦，將是我記憶中最珍貴的收藏之一。

在重點中學，學業的壓力是很重的，又是住校獨立生活，對于體力已較大程度下降、行動已呈現出不少不便的我，平添了幾許額外的困難。高中的第一年沒有計算機課，我只能在假期回家后才能有機會繼續學習編程，也以此來忘記一學期的壓力和苦累。高二時，終于盼到了計算機課，也見到了當時相對高檔的蘋果電腦。而我此時已有的基礎令老師吃驚，同學驚服。我加入了計算機興趣小組，開始在性能遠遠好于原來那臺電腦的蘋果機上快樂的編程了。在高二的暑假我和計算機老師一起給學校做個工資管理軟件。在學校里的一周時間內，由于宿舍已經鎖掉不能住，我就睡在了辦公室里。位于郊區的校園，蚊子格外多，咬的我一直睡不著。到了后半夜，我索性爬起來，打開了電腦干活。就這樣，我幫著老師寫程序、錄入數據，并且在即將交貨時找出了一個大BUG，又正確地判斷出問題根源在內存不足，算是立下了一個小功勞。

由于高考發揮出色(尤其是物理的滿分)，我進入了北京大學物理系。在大學里，計算機上機條件就更好了。當時蘋果的Macintosh剛剛推出，給我們系捐了好多臺組建了計算機室。這個計算機室從此就成了我大學四年最常去的地方。一年級的時候有兩門計算機課，一門是Fortran語言，一門是Pascal語言。而Pascal語言基本是我們自己學，每到晚上計算機室向我們開放。那是我第一次見識“窗口”形式的操作界面。第二年，計算機室的機器換成了386和Dos系統了，但是上機機時卻被限制住了。不能滿足的我到處找不喜歡計算機的同學借機時卡，好讓我有足夠的時間調試自己寫的程序。到了第三年，北大招生更多，系計算機室天天爆滿，所以上午只要沒課，我就會起個大早到機房門口等待開門。在一個寒冷的冬晨，還因此著涼發燒而暈倒在機房門口。就這樣，我熟練地掌握了Turbo Pascal和Turbo C++，也學習了好多相關的理論知識。

畢業后，我終于如愿以嘗當上了程序員。我被分配的任務，起先是用Delphi做一些文字處理的工具，供編輯部和數據部使用。后來Internet開始興起，又委派我寫為網絡版期刊使用的一些CGI程序。工作一直都很順利，我的眼界與編程水平也在穩步成長。兩年后，為了有更好的發展，我離開了我工作的第一家公司。這時，我把求職的陣地移到了網上。不久，就在某網站上看到了一家合資軟件企業的招聘啟事。盡管啟事上說明不接受來訪，我仍然勇敢地拿著簡歷于第二天趕到公司所在的翠宮飯店去求職了。幸運仍然在籠罩著我，這次我直接見到了經理，向他表達了自己對于編程的熱愛。我說，我夢想著成為IT業的傳奇英雄。也許是這句話感動了他，我成功的通過了面試。在這家公司，我第一次作為一個龐大項目組的一員，感受到了現代化的軟件項目管理，接受了團隊精神的洗禮。

在北京做了五年的程序員，這時候，我聽到了來自深圳的召喚。早在99年，我就在網絡上找到了一個位于深圳的名為“中華殘疾人服務網”的殘疾人網站。一天，我在這個網站的留言本上看到了站長的一席因殘疾人網絡事業缺少技術支持而發的感慨，不由心有所感，便留言說，愿投入殘疾人網絡事業，而不計待遇。從此，我的人生翻開了輝煌的一頁。那是2002年的10月6日。

起初以為，這個網站會類似于僅僅出于興趣的個人網站，走進去才真正發現，這是個志存高遠的團隊。而我真正感覺到了團結一致共創大業的團隊精神。在同樣因病致殘的站長有力領導下，這里基本解決了殘疾人在生活會有的種種不便，克服了許多社會上普遍存在的障礙，從而可以讓我充分發揮聰明才智，全身心地去攀登IT技術的高峰。

加入網站之后，我完成的第一個任務是改進網站新聞系統，增加圖片上傳和自動圖文排版功能。以前沒有做過ASP程序的我在原有的ASP程序的基礎上，通過學習和分析源代碼，完成了這個任務，同時也掌握了基本的ASP編程技術。然后，我又獨立完成了一套社區論壇程序，這套程序受到了全國以至海外殘疾朋友的歡迎，成為了許多足不出戶的殘疾朋友與網友熱烈交流的園地。也讓我從中看到了自己的價值。后來，因為網站的網管不辭而別，我又接過了網管的重任，從此一面開發程序，一面又管理著我們自己的兩臺服務器。盡管壓力和工作量成倍地增加了，卻使我同時掌握了兩個領域的技術，而這兩方面的技術又互相促進，使我的知識結構更為全面。

由于我們沒有外來資金的支持，要維持中華殘疾人服務網這個福利公益網站的運轉，必須走以網養網的道路，即為企業、政府提供信息化建設服務，以獲得經濟收入。所以，在給網站開發和升級程序之余，我又開始進行商業網站后臺程序的開發。僅網站新聞系統，就在兩年內從1.0版升級到了6.0版；還有大量為企業量身定做的功能程序。這些程序在網站原本就強大的前臺設計的包裝下，受到了市場的歡迎。網站也由此發展壯大。今天中華殘疾人服務網在全球排名中穩步上揚，進入了三萬以內的行列。

在承接網站建設工程的同時，一些客戶也開始找我們開發應用軟件。第一個應用軟件項目是一家與廣東移動通信有業務關系的公司，因為自身沒有軟件開發能力，便請我們合作為廣東移動通信做一個《“測試卡”管理系統》。根據要求，我設計了使用條形碼的輸入方案，又使用SQL數據庫作為局域網聯網的后臺數據庫解決方案。由于是第一次全程的開發與服務，在進行以前沒有接觸過的安裝過程中出現了大量問題，又沒有充分做好應對的準備，造成了一些被動局面。但是最終我仍然想出了臨時的解決方法，順利地完成了測試版的交付。遺憾的是由于中介的公司人事調動，這個項目最終沒有進行下去。

很快又一個重大考驗落在了以我為首的網站開發隊伍身上。這是一直從各方面扶持我們的深圳市信息化辦公室交給我們的任務。要求是我們收集深圳市所有的網站，以PDF電子書的形式印刷在光盤上。同時要有一個完善的分類搜索系統。時間緊、數據量大，而且不允許出現任何差錯。為了證明殘疾人團隊的開發能力，我和大伙都拼上了。而在送交初稿的前一天晚上，更是全民動員，站長第二天一大早要親自帶上光盤送去，但他也一起在熬夜。那個不眠之夜是我編程生涯中效率最高的一夜。不久后，這個項目終于完成，看著出自我們的頭腦和雙手的幾千張光盤，我知道自己的努力沒有白費，而自己的能力也提升到了一個新的境界。這個項目，在那些大公司看來也許是不值一提，可是對于一個核心成員僅五六人、而且全部是殘疾人組成的一個項目組，是非常了不起的成就！

2003年12月，世界殘疾人職業技能奧林匹克在印度新德里舉行，我有幸代表中國的殘疾人參加了其中編程項目的比賽。在中國，殘疾人的就業問題是一個大問題，因此，這種殘疾人的職業技能競賽尤其有意義。2002年12月，我以廣東省冠軍的身份取得了2003年在上海參加全國比賽的資格。2003年8月，我在上海憑著多年的編程經驗和創新精神，又取得了參加中國殘疾人代表團出征印度的資格。遺憾的是，在賽場上，為了追求更好的界面效果，我耽誤了一些時間，以至在最后因時間過于緊張，出現了一個致命的失誤，將本來有希望得到的獎牌拱手相讓。唯一的安慰，就是我的程序界面受到了印度裁判的稱贊。

從國外回來，我又打開了.NET的大門，準備帶領網站的幾個做程序的殘疾朋友進入.NET的開發。對未來，我充滿了信心，而新的夢想，又開始浮現在我眼前！

現在我的身份，一半是軟件工程師，一半是高級程序員。隨著網站這個實體的發展，我也許會逐漸成長轉型為軟件架構師，但是我仍然會夢想著掌握最高的編程技術，仍然愿意承擔基礎性的編碼工作。我相信，保持開放的心態，保持年輕的心態，再老也能做程序。當今的數字化時代給殘疾人士尤其是肢殘人士帶來了新的機會和挑戰。現在，純粹腦力勞動的門檻，因為程序員門檻的大幅度降低而降低，給更多由于社會原因而教育程度相對偏低肢殘人士提供了經過培訓進入初級程序員行列的機會。但是，這些機會要想轉化為現實，還需要更多更廣泛的“無障礙”環境的支持。我的第二個夢想，就是夢想中國能夠出現更多的“軟件工廠”，而這些“工廠”又是向殘疾人敞開大門的。

十年編程生涯，歷經了風雨坎坷，而程序代碼給我插上的翅膀在風雨中更加硬朗。今天，我喜歡在程序代碼的世界中自由飛翔。讓病魔去禁錮我的身軀吧，我的靈魂仍然在廣闊的世界里翱翔??

“我不是程序員”,楊過在電話那頭淡淡的說。楊過是大學同學叫他的外號，因為他的氣質和金庸造的楊過最像，連一些感情遭遇都像。

拒絕做程序員，雖然很火

楊過畢業那年軟件公司很火，據說在中關村隨便一個剛畢業的寫C程序的畢業生月薪一不小心會上萬。于是乎楊過不少的同學們畢業后紛紛改行編起了程序，跳進了大家現在也沒說清楚的IT行業。說改行是因為楊過學的不是計算機專業，只是沾上邊。

楊過那時根本不屑于做編程，雖然那時班里就他最喜歡打軟件游戲。他覺得去編程不是什么“正經事”，所以畢業后他去了大連一家生產糧油的集團企業，楊過說是“一顆紅心投入四化建設”。

由于不想拍馬逢迎，楊過徹底打消了“磨豆油”的念頭。不過他沒有直接留在大連找工作，而是跑到偏遠的老家和他青梅竹馬的高中同學結婚去了。楊過的感情故事太有傳奇色彩，跟金庸那個楊過有一拼。因為新婚的妻子在大連不好找工作，當時他留在家里，找了一個小公司用電腦給人設計零件圖。

本來大多數人的工作就是混口飯吃，楊過也不嫌公司小，老老實實過日子吧。可讓他接受不了是，公司的老板經常借口讓他熟悉工作為名把他當民工使，一氣之下楊過回了大連，幾個月也是白干，工資沒拿到一分錢，因為工資是三個月一發。楊過借口看病從老板那里借了幾百塊錢，老板也明白怎么回事，就給他了。直到現在，楊過還算是借著這個公司的幾百塊錢。

還得做程序員

楊過先自己回到大連，到人才市場一看，鋪天蓋地都是要程序員。“唉，不服氣不行，社會發展趨勢啊”。電話那頭的楊過一直在嘆氣。

畢竟楊過是重點大學畢業的和計算機相關專業，那時還很吃香。他很快找到一家做尋呼臺業務的軟件公司。由于以前“沒睡決時還看看計算機書”，他上手還挺快。干了一年，他跳到現在的這家公司，工資漲了一大截，在大連還算可以，老婆也接過來了。

楊過老婆剛開始在影樓做過一段，后來生病就沒再做。楊過說現在工資也夠兩個人花的，也不逼她找了，也不好找。

我不是程序員，也不考慮明天

楊過現在的這家公司雖然也不算小，主要是做政府機構的一些單子，但為了生存業務還是比較雜。楊過感覺自己“天天這編一點、那寫一點，從來沒有好好從頭做過一個正式的項目”。“我不是程序員，”他說，“可大家都這個樣子。”

公司里只有楊過一個人結婚了，其它都是小伙子。“以前沒睡覺還看看書，現在沒心思了”，楊過調侃。

由于換了幾個工作，楊過的國家基本保險也搞的亂七八糟。“我仔細研究過國家的一些文件，自己掏錢交那些基本保險沒有什么用”，楊過現在和老婆都沒有基本保險，自己存錢保險。

楊過無奈的笑笑，“也存了一些錢，前一段老婆病了都交給醫院了。”

最近,看到論壇一貼子，主題是：我從校園出來的這幾年。里面可熱鬧了，回復次數竟然達1425次，我讀了幾個鐘都沒看完，最后只能大概瀏覽一下了，不過里面大多數都說自己是程序員，并且出來工作都不容易，可謂是一部“千人辛酸史”了，從中多少反映出了中國不少程序員的生活狀況，不知道打算做程序員或者現在正入門的程序員朋友看了作何感想？

說實在的，目前在中國的程序員大都過得不容易，而且普遍表現為“青春飯”狀態，工作量大，導致對新知識的吸收能力隨著年齡增大而降低，到了一定年齡（30后）后因為跟不上時代發展面臨淘汰的厄運。雖然如此，但讓我覺得欣慰的是的不少程序員或打算做程序員的朋友都表示堅持在程序員的路上走下去，因為我也是一名程序員，而且我對未來充滿陽光，充滿希望。

我記住了這樣一個簡單的道理：過去并不代表未來！相信沒有人會不知道這個道理吧！大多程序員過去的辛酸大都可以歸結于中國軟件產業的發展的不成熟，而現在，中國政府制定政策大力扶持軟件產業的發展，而且不少國際軟件企業也看好中國的軟件產業，紛紛把投資向中國傾斜，而且國內也開始有了不少比較成熟的軟件企業，當然與國外的一些軟件企業相比，還有一大段距離。但它表明中國的軟件產業開始向規模化，規范化的方向發展了。

印度在軟件方面，在我們看來是成功，印度政府在1991年就制定相關扶持政策，到現在也有10多年了，才取得成功，另一個在軟件方面比較成功的亞洲國家——韓國，它也在1998年就制定了相關扶持政策，到現在也取得了一定的成功，用時不過4-5年，那么中國的軟件產業呢？要多久才能成熟起來呢？引金山總裁雷軍的話，3年左右有所成就，到全面成熟那就要比較長的時候了，但中國軟件產業的成熟和前述國家成熟概念不一致：印度是定位于軟件外包而取得成功，韓國定位于網絡游戲取得一定成就，而中國呢？定位于什么呢？中國的定位是組合式的，不是某一方面，而是全面的。

可以相信:在未來，中國的軟件產業無論在產業結構上，還是人才結構上都會具有優勢。關于后者，你只要看看中國建立的50多所軟件學院就可見一斑了，而且還有很多像印度的NIIT，北大青鳥（中外合資）等著名的國外軟件開發教育機構進入中國，把先進成熟的教育模式帶入了中國。

但是，以上的教育機構培養目標都不是精英程序員，而是最近大家抄的很熱的“高級軟件藍領”，成熟模式中的軟件開發團隊中需要“金領”，“白領”，再到“藍領”，而中國軟件企業大多是小企業，最需要的是能獨擋一面的“金領”，“白領”程序員，并不需要那么多只會Coding的“藍領”程序員，我想很多混的不那么好的程序員，大概你是屬于“藍領”程序員吧！

任何時代，任何時候，機遇總是垂青于有能耐的人的。但是，即使你現在不是“金領”，或者“白領”程序員，你還不是精英，而僅僅是“藍領”程序員或者還不是而想成為程序員的你聽到這句話，千萬不要泄氣，要相信你自己是將來的精英，雖然現在的生存環境不是那么好，但是，恰恰有更多機會讓培養自己獨擋一面的能力，隨著中國軟件產業的發展，將會需要大量有數年工作經驗，有整體系統架構能力的人才，而這些恰恰是任何學校都無法培養的人才，而現在的程序員，只要你們不放棄夢想，不放棄追求，繼續努力，你們將成為軟件產業的中堅力量！軟件人才的佼佼者。

最好，告訴大家一項調查，硅谷的程序員的平均年齡是35歲左右，而且微軟公司的核心開心者大都在35歲以上，可以遇見，程序員不在是“青春飯”，也會有“老來悄”的“老資格”了！

冬天來了，春天還會遠嗎？——謹飭送給所有的中國程序員。

如同一首民歌《三十里鋪》所言，路行三十要有個歇腳的地方，人行三十也要喘口氣。在IT，特別是程序員這個特殊的職業，流傳一種說法：30歲是職場上的一道檻，事業上此時會發生了許多變化。30歲和程序員真有某種特殊的聯系嗎？程序員到底能不能做到30歲以上呢？

J曾是一名計算機老師，因為厭倦了學校平淡的生活，應聘到一家開發嵌入式系統的公司做底層程序員。剛開始的一兩年，憑著一股熱情和鉆勁兒，投入到如火如荼的開發中，甚至購置了睡袋以備晚上加班。兩年中，他掌握了極其專門的硬件參數、規格、開發細節等知識，成為部門的骨干。

逼近30歲的那幾個月，他開始感到有些困惑。自己在公司雖然還算受重視，但是技術上翻來覆去就是那幾樣爛熟于心的東西，公司只需要自己慣性運作，實際不愿支付經驗轉換的成本；而公司的原始積累還遠遠未完成，自己仍然要和剛畢業的大學生一起加班，通宵達旦的干。因為缺乏人際交往，家里一直催著的婚姻大事，至今還八字沒一撇。很多同時期來的人都打算往管理轉了，可是自己對管理缺乏興趣，還是樂于從事技術工作。下一步怎么辦？J想到了辭職，但還沒有什么方向。

相比J，M要幸運得多。作為清華計算機本科、中科院研究生畢業的高材生，M在做項目經理時就能夠月收入2萬，先后換過3家公司，對所謂30歲的說法不以為然。M以前的項目都是用CMM做，項目管理很好，而核心的也就幾個人。手下帶過的人，當然是剛畢業的最差，因為要獲得30歲時的經驗，顯然需要一個過程。M最開始做程序是用Debug單步跟蹤、分析、定位；后來開發圖形界面的上層程序，哪怕半年寫1萬行，也覺得不叫程序；只有到后來轉到做底層開發以后，雖然半年只寫到2000行，但是卻感到了寫程序的快樂。M認為30歲以后程序員的體力不是問題，好的程序員不經常熬夜，有也是臨時的。M接觸過國外、比如印度的一些公司，技術人員們沒有固定辦公室，用互聯網聯系；很多人年齡都在35歲以上，技術很熟練，思想敏捷，讓人敬佩。

M的職業觀也很靈活。剛剛辭職在家，接點活干，非常忙。M有幾個同學在外企做程序，日子過得更舒服，但是幾年下來，個人、技術均無進展。究其原因，除了像微軟研究院、Intel等一些少數外企還做些研發外，其它外企都是挑國外剩下的做，反而是國外一些小公司倒是把最核心技術放在中國來開發。其它像金山這樣的一些本土企業應該也不錯。做為程序員，機遇、環境、職業（項目）都很重要，它不但直接決定現在的收入水平，更決定未來不同的命運。而程序員這個行業又有極強的主導性，如何做好職業生涯的規劃，恰恰是決定乾坤的關鍵棋子。

程序員圈子里流傳過一套書叫做《編程之禪》和《編程之道》。創造力、邏輯、判斷、體力、智力、手段都是所謂道的一部分，書中有個比喻，程序員編程時，只有硬盤在響。創造本身是一項神圣的工作，但是創造者的果實卻是世俗的。換句話說，年齡的問題本是見仁見智的，但是“30歲的檻”卻是世俗的。國內大部分公司還沒有好到為程序員做好一生的職業規劃的地步，因此路還得自己來走。不要讓過度的重復勞動損害了創造力，也不要太迷信技術的力量，而忽略了世俗世界的張力。“三十里鋪是一個小村莊，小村莊是我們經過的地方。經過的地方向著遙遠的別處，遙遠的別處還是三十里鋪。”

做為一名大四的學生,我面試過不少的單位，有成功的也有失敗的，但是對我來說所有的失敗在某種意義上都是一種成功，特別是我下面寫的這些，寫這篇文章的時，我已經簽了南京的一家軟件公司，但是想起今年2月21日我面試蘇州臺灣的IT公司的經歷聯想到我們現在學習編程的一些情況我真的深有感觸，這次面試使我深深的體會到了失敗但也收獲了很多。

我要說的將分成三部分，1.是我面試的具體經過 2.是由面試想到的 3.現今我應該做的。

當然這些話很大程度上是我個人的意見，不可能完全得到大家的贊同，所以 在某些觀點上如果哪位朋友覺得跟我的有很大出入，請不要介意，也不要對我攻擊，就當我 沒有說過，歡迎和我聯系共同探討這些問題！我的EMAIL:wutao8@263.net

1.面試經過

大約在年前我接到了臺灣瑞晟(Realtek)蘇州公司的面試通知，通知我2月21日到蘇州工業園區面試，接到面試后的幾天我把一些專業課溫習了一遍，特別是C++和數據結構，由于大學幾年里，我一直專研這些方面，加上通過了高級程序員的考試，對于一些常用的算法我差不多也 達到了爛熟于胸的地步，當時的感覺是如果問了我這些方面的問題我應該是沒有問題的！

21日那天我被安排在4：30面試，由一位技術人員單獨給我面試，在問了一些簡單的問題之后 ,他給我出了一道編程題目，題目是這樣的：

(由于具體面試的題目比較煩瑣，我將其核心思想提取出來分解成??（亂碼）

1)寫一個函數計算當參數為n(n很大)時的值 1-2+3-4+5-6+7......+n 哼，我的心里冷笑一聲！沒想到這么簡單，我有點緊張的心情頓時放松起來！于是很快我給出我的解法：

long fn(long n){ long temp=0;int i,flag=1;if(n<=0){ printf(“error: n must > 0);exit(1);} for(i=1;i<=n;i++){ temp=temp+flag*i;flag=(-1)*flag;} return temp;}

搞定！當我用期待的目光看著面試官的時候，他微笑著跟我說，執行結果肯定是沒有問題！但當n很大的時候我這個程序執行效率很低，在嵌入式系統的開發中，程序的運行效率很重要，能讓CPU少執行一條指令都是好的，他讓我看看這個程序還有什么可以修改的地方，把程序 優化一下！聽了這些話，我的心情當時變的有點沉重，沒想到他的要求很嚴格，之后我對程序 進行了嚴格的分析，給出了改進了的方案！

long fn(long n){ long temp=0;int j=1,i=1,flag=1;if(n<=0){ printf(”error: n must > 0);exit(1);} while(j<=n){ temp=temp+i;i=-i;i>0?i++:i--;j++;} return temp;}

雖然我不敢保證我這個算法是最優的，但是比起上一個程序，我將所有涉及到乘法指令的語 句改為執行加法指令，既達到要題目的要求而且運算時間上縮短了很多！而代價僅僅是增加了 一個整型變量！但是我現在的信心已經受了一點打擊，我將信將疑的看者面試官，他還是微笑 著跟我說：“不錯，這個程序確實在效率上有了很大的提高！”我心里一陣暗喜！但他接著說這個程序仍然不能達到他的要求，要我給出更優的方案！天啊！還有優化！我當時真的有點崩 潰了，想了一會后，我請求他給出他的方案！然后他很爽快的給出了他的程序！

long fn(long n){ if(n<=0){ printf(“error: n must > 0);exit(1);} if(0==n%2)return(n/2)*(-1);else return(n/2)*(-1)+n;}

搞笑，當時我目瞪口呆，沒想到他是這個意思，這么簡單的代碼我真的不會寫嗎，但是我為 什么沒有往那方面上想呢！他說的沒有錯，在n很大很大的時候這三個程序運行時間的差別簡 直是天壤之別！當我剛想開口說點什么的時候，他卻先開口了：“不要認為CPU運算速度快就 把所有的問題都推給它去做，程序員應該將代碼優化再優化，我們自己能做的決不要讓CPU做，因為CPU是為用戶服務的，不是為我們程序員服務的！”多么精辟的語言，我已經不想再說 什么了！接著是第二個問題：

他要求我用一種技巧性的編程方法來用一個函數實現兩個函數的功能n為如：

fn1(n)=n/2!+n/3!+n/4!+n/5!+n/6!fn2(n)=n/5!+n/6!+n/7!+n/8!+n/9!

現在用一個函數fn(int n,int flag)實現，當flag為0時，實現fn1功能，如果flag為1時實現fn2功能！他的要求還是效率，效率，效率！說實在話，如果我心情好的話我應該能給出一種比較好的算法，但我那時真的沒有什么心思再想了，我在 紙上胡亂畫了一些諸如6!=6*5!的公式后直截了當的跟他說要他給出他的答案！面試官也沒有 說什么，給出了他的思路：

定義一個二維數組 float t[2][5]存入[2!,3!,4!,5!,6!},{5!,6!,7!,8!,9!]然后給出一個循環：

for(i=0;i<6;i++){ temp=temp+n/t[flag][i];}

最后得到計算值！呵呵，典型的空間換時間的算法！這些總共花了50分鐘的時間，還有十分鐘我就跟他很隨意的聊聊天，聊了一些編程以及生活 的問題，那時的我已經很放松了，因為我知道這次面試結果只有一個：失敗。5:30的時候面試官要我等通知，于是我離開了他們公司。這就是面試的整個經過！

2.由面試想到的

真的是很失敗啊！我記得那天下好大的雨，氣溫也很低，我邊走邊想，從5:30一直走到7:30，全身都濕透了，又冷又餓，但是我只是一直走，腦子里面充滿了疑惑，我也想讓雨把自己淋 醒！看到這里有些朋友可能覺得那些面試題目不算什么如果讓自己做的話肯定能全部答對，我 肯定相信你，因為我從未懷疑過中國程序員的能力，我認為中國有世界上最好的程序員，我也 從未認為自己是高手，所以我做不出來不代表中國程序員比臺灣或者別的地方的程序員差，所 以我就從我的角度，我的所見所想來談一些感想：

不錯全世界都有優秀的程序員，中國也不例外，但是我疑惑的是：到底中國和臺灣或者國外 的優秀的程序員的比例到底是多少？臺灣我不知道，中國100個程序員里有幾個是優秀的呢?我 根本算不上，從上面的表現就足以說明一切了！是1個？5個？10個？50個？這個數字我不敢亂 猜，恐遭網友一頓痛罵，那么我們國內有多少人學習計算機呢？拿我們學校來說，計算機97級 4個班，98級5個班，99級10個班，2000級17個班，人多了，老師怎么辦？我們學校的做法是讓 研究生上課，然后呢？補考一抓一大把，大把大把的補考費落入了學校的口袋，還說現在的學

生素質低！真是好笑，我都不知道學校這么做是為了什么，為國內培養大量的程序員嗎？學生 們能真正學到計算機知識嗎？好了，我敢講，在我們學校學習編程學生和優秀程序員(注意我 指的是優秀，只會編幾個糟爛程序的人算不上)的比例應該是100:0.1 在這種比例下雖然我們中國學習編程的人鋪天蓋地，但是想想有多少個人能真正為中國軟件 業發展作出貢獻，有多少人能真正寫出優秀的程序名揚海外！

我從學習編程以來，不管是自學還是老師指導，從來都是解決問題就好，編出程序來就行，我的疑惑是：我們有真正的強調過程序的效率，程序的質量嗎？我們有仔細分析過我們寫的東 西，看看有沒有可以改進的地方，看看有沒有簡單的方法來達到同樣的目的呢？我問心自問，我發現，我從來沒有對我寫出來的程序進行過優化，最多就是進行詳細的測試，然后Debug，但是這就足夠了嗎？這些天我偶爾發現我曾經寫過的一個游戲，那是一年做為 其中一員時候，感覺應該拿點東西出來，然后花了一個星期的時間寫出來的！程序不算復雜，但是用到了不少數據結構的東西，也用到了一些精彩的算法，加上windows的界面和游戲的可 玩性，寫完后受到了不少好評，我當時真的很佩服自己！但是現在看呢：沒有一句注釋，好多 丑陋的函數名比如：void chushihua()，好多沒有必要的變量，可以用簡單語句完成工作的我 使用華麗的算法，大量使用全局變量.....,說不好聽的話，六百多行的程序除了能運行之外就 是一陀屎！如果一年前我能聽到一些反面意見的話，大概我能早一點覺悟，但是自原代碼在 網站發布以來聽到的都是贊美之詞，沒有一個人向我提出程序改進的意見，這又說明了一個什 么問題呢？很值得思考啊！

還有一個疑惑是：我們說的和做的真的一樣嗎？我在學校的時候曾經受學院指派承辦過一個 計算機大賽，請了一個老師出決賽的題目，主要是一些算法題目，這個老師可能是我上大學以 來唯一敬佩的老師了，從程序調試到打分，對于每個程序都仔細分析其時間效率和空間效率，然后綜合打分，四十個人的卷子，老師從下午三點一直調試到晚上十點，在有些寫的精彩的語 句后還加上批注。我真是高興很遇到這樣的老師并且和他做深入的交流，但在事后，卻發生了 一件不愉快的事，在比賽中獲得第二名的學生找到我，說他程序全部調試成功應該給他滿分，并且應該得第一，我說不過他，最后調出了他的原程序和第一名的原程序對比，錯，兩個程 序都運行的很好，這時，那個同學開口了：“我的程序寫的十分簡捷明了，僅僅數行就完成了 題目要求，而他的卻寫了一大堆，為什么給他的分多過給我的分。”我當時很是氣憤，如果不 是老師負責的話，那么現在第一名和第二名的位置真的要互調了，拜托，不是程序的行數越少 程序的質量就越高，我記得我跟他大談這方面的道理，最后說服他了！哈哈，但是我，只能說 說而已，我不知道還有多少人一樣，說起來頭頭是道，但心里卻壓根就從未重視過它！

3.我打算做的！

其實那天我想到的遠不止上面那么多，但是我不想再說了，因為我猜想看這篇文章的網友大 概都有一肚子的感想，一肚子的抱怨，借用這篇文章發泄可不是我想達到的目的，在上面我把 自己罵的一文不值也不是妄自菲薄，但是在某些方面我真的做錯了，或者說是偏離了正確方向，現在是矯正方向和重整旗鼓的時候了，就象我前面說過的，我相信中國有世界上最好的程序 員，我也相信我的水平不會一直保持現狀，我現在就收拾起牢騷真正的實干起來！真的很巧，就寫到這里的時候我在網上偶爾發現了這篇手冊，我不知道這預示著什么，但是 我想如果我照下面這個基本原則一直踏實做下去，我一定會實現我的理想---一名優秀的軟件設計師!

（下面這些文字不是我的原創，是我偶爾在網上發現的，我真的很幸運能看到這些，這篇文 章也隨著下面的文字而結束，我真心的希望您能從這篇文章中得到啟發,這篇文章歡迎大家隨 意轉載！）

作者：金蝶中間件公司CTO袁紅崗

不知不覺做軟件已經做了十年，有成功的喜悅，也有失敗的痛苦，但總不敢稱自己是高手，因為和我心目中真正的高手們比起來，還差的太遠。世界上并沒有成為高手的捷徑，但一些基 本原則是可以遵循的。

1.扎實的基礎。數據結構、離散數學、編譯原理，這些是所有計算機科學的基礎，如果 不掌握他們，很難寫出高水平的程序。據我的觀察，學計算機專業的人比學其他專業的人更能 寫出高質量的軟件。程序人人都會寫，但當你發現寫到一定程度很難再提高的時候，就應該想 想是不是要回過頭來學學這些最基本的理論。不要一開始就去學OOP，即使你再精通OOP，遇到 一些基本算法的時候可能也會束手無策。

2.豐富的想象力。不要拘泥于固定的思維方式，遇到問題的時候要多想幾種解決問題的 方案，試試別人從沒想過的方法。豐富的想象力是建立在豐富的知識的基礎上，除計算機以外，多涉獵其他的學科，比如天文、物理、數學等等。另外，多看科幻電影也是一個很好的途徑。

3.最簡單的是最好的。這也許是所有科學都遵循的一條準則，如此復雜的質能互換原理 在愛因斯坦眼里不過是一個簡單得不能再簡單的公式：E=mc^2。簡單的方法更容易被人理解，更容易實現，也更容易維護。遇到問題時要優先考慮最簡單的方案，只有簡單方案不能滿足要 求時再考慮復雜的方案。

4.不鉆牛角尖。當你遇到障礙的時候，不妨暫時遠離電腦，看看窗外的風景，聽聽輕音 樂，和朋友聊聊天。當我遇到難題的時候會去玩游戲，而且是那種極暴力的打斗類游戲，當負 責游戲的那部分大腦細胞極度亢奮的時候，負責編程的那部分大腦細胞就得到了充分的休息。當重新開始工作的時候，我會發現那些難題現在竟然可以迎刃而解。

5.對答案的渴求。人類自然科學的發展史就是一個渴求得到答案的過程，即使只能知道 答案的一小部分也值得我們去付出。只要你堅定信念，一定要找到問題的答案，你才會付出精 力去探索，即使最后沒有得到答案，在過程中你也會學到很多東西。

6.多與別人交流。三人行必有我師，也許在一次和別人不經意的談話中，就可以迸出靈 感的火花。多上上網，看看別人對同一問題的看法，會給你很大的啟發。

7.良好的編程風格。注意養成良好的習慣，代碼的縮進編排，變量的命名規則要始終保 持一致。大家都知道如何排除代碼中錯誤，卻往往忽視了對注釋的排錯。注釋是程序的一個重 要組成部分，它可以使你的代碼更容易理解，而如果代碼已經清楚地表達了你的思想，就不必 再加注釋了，如果注釋和代碼不一致，那就更加糟糕。

8.韌性和毅力。這也許是”高手"和一般程序員最大的區別。A good programming is 99 weat and 1ffee。高手們并不是天才，他們是在無數個日日夜夜中磨練出來的。成功能給 我們帶來無比的喜悅，但過程卻是無比的枯燥乏味。你不妨做個測試，找個10000以內的素數 表，把它們全都抄下來，然后再檢查三遍，如果能夠不間斷地完成這一工作，你就可以滿足這 一條。

這些是我這幾年程序員生涯的一點體會，希望能夠給大家有所幫助。

第五篇：C++ 心得

2010.10.13

今天在學習用windows自帶的dos命令提示符窗口的命令：

列文件名dir，創建文件夾md（其他文件不能通過該命令創建，即使用了該類文件的后綴名，也只是將該名稱和后綴名一塊作為了一個新建文件夾的名字，例如md aa.txt的作用是建立一個名為aa.txt的文件夾），刪除文件夾下的所有文件del（但是不包括該文件夾下的子文件夾。網上還有人說用deltree可以刪除目錄樹，但是我試了不管用），刪除文件夾rmdir或者rd（必須是空的，不能含文件或者文件夾），重命名文件或者文件夾ren x y（將x改名為y，如果是文件則應包括后綴名，如果是文件夾只是名字就可以），移動文件或者文件夾（沒找到），復制文件copy a b（a和b可以是文件夾，這時候會復制a中的所有文件但不包括子文件夾到b中，遇到同名文件會詢問是否覆蓋；如果a和b是文件，則要包括后綴名，而且不只是相同后綴的可以復制，例如兩個txt文件，而且非同后綴的文件也可以，例如txt復制到doc文件或者rar文件，這種復制后會連txt的屬性一起復制給doc或rar，包括大小和占用空間這兩個屬性，doc的話還是可以打開，但是rar會損壞掉），創建文本文件copy con A.txt（或者用edit A.txt，區別是前一個會在輸完命令后讓你再輸入文本內容，輸完用ctrl+z結束，而后一個會跳出一個類似turbo-c的界面讓你輸入文字再保存），以樹形結構顯示出目錄tree（用參數-f 將列出第個文件夾中文件名稱）。

然后我想解壓一個再f盤的壓縮文件B，發現在ms-dos里進入B的目錄后，直接輸入

B.rar或者B.rar /x都會直接打開B，和雙擊B的效果相同（之前裝.NET 3.5 Framework的時候用過這個命令dotnetfx35.exe /x來解壓，我想用類似命令解壓B的，結果證明不行，上面這個命令應該是只針對.EXE文件有效果，而且不是普通的EXE文件，應該是壓縮類的exe文件）。但是我在實驗exe文件的時候發現一個有用的辦法。平時在有些文件夾里會有一些exe文件，雙擊之后有些可以運行，但是dos窗口一閃之后就沒有了，看不到內容，但是先打開ms-dos，再進入該exe文件目錄后輸入名稱回車則會看到運行內容，并且ms-dos窗口不會關閉。這可以用到C++編程之中。C++編程中，程序運行后有時候也會出現上面的情況，dos窗口一閃而過，看不到運行結果，以前都是直接在程序末尾加入system（”pause”）命令，現在也可以先將程序編譯并生成exe文件，再打開MS-DOS，進入exe文件所在文件夾，輸入該exe名稱的方法來運行，這時候一定可以看到結果。