程序員教訓

Ⅰ 成為程序員（或碼農）有哪些方面的要求

1、 程序員意味著要編程序。（如果你僅僅想得到一份高薪水的工作，喝喝咖啡就等老闆發薪水，我奉勸你還是另找一份更合適的工作，譬如練攤，真的，兄弟，這份工作不適合你）
2、你是學文的還是學理的，編程序也許需要浪漫，但更需要邏輯和嚴謹。（說坦白點就是，在你沒有找到樂趣以前，它很枯燥）
3、你有對新技術追求的熱情嗎？你有刨根問底的探索精神嗎？（熱情絕對是最重要的！你仔細思考一下自己的性格適合當程序員嗎？）
4、當程序員決不是什麼好差事，時刻需要學習，需要思考。（直到你成為那個可以引導別人去學習和思考的人，你才可以偷偷的嘿嘿笑，又一群傻蛋）
5、程序員的未來很迷茫。（但我認為關鍵看你自己！我希望你是一個有追求的人，不僅僅是混碗飯吃。因為真正的樂趣在於創造；如果你能改變軟體業的歷史，那才是英雄；不想成為Bill Gates，不想成為Dennis Ritchie和 Bjarne Stroustrup，我會說你沒有追求。有個關於程序員未來的笑話，也許你還沒聽過，你該聽一聽，摘抄如下：
一個程序員對自己的未來很迷茫，於是去問上帝。
「萬能的上帝呀，請你告訴我，我的未來會怎樣？」
上帝說「我的孩子，你去問Lippman，他現在領導的程序員的隊伍可能是地球上最大的」
於是他去問Lippman。
Lippman說「程序員的未來就是駕馭程序員」
這個程序員對這個未來不滿意，於是他又去問上帝。
「萬能的上帝呀，請你告訴我，我的未來會怎樣？」
上帝說「我的孩子，你去問Gates，他現在所擁有的財產可能是地球上最多的」
於是他去問Gates。
Gates說「程序員的未來就是榨取程序員」
這個程序員對這個未來不滿意，於是他又去問上帝。
「萬能的上帝呀，請你告訴我，我的未來會怎樣？」
上帝說「我的孩子，你去問侯捷，他寫的計算機書的讀者可能是地球上最多的」
於是他去問侯捷。
侯捷說「程序員的未來就是誘惑程序員」
這個程序員對這個未來不滿意，於是他又去問上帝。
「萬能的上帝呀，請你告訴我，我的未來會怎樣？」
上帝搖搖頭「唉，我的孩子，你還是別當程序員了」）
6、當程序員還是很有樂趣的。（當你學到新知識時，當你有新的思想見解時，當你有新的產品問世時，和知己探討你的成果時…我問你，覺得這些是樂趣嗎？）
7、當程序員不易也不難。（世間事有難易乎？為之…；不為…。你有決心和信心嗎？）
8、你真的要當程序員？是你自己的想法？
9、你捨得花錢買書嗎？（讀好書絕對是學習編程的最佳捷徑。你一定會說，現在電腦書籍真他XX的貴，沒法子，誰讓知識和技術在人家的腦袋，在人家的書里呢；等你寫書時可以把價格定低一點，記著還有好多沒錢但想買書的兄弟很困難呀。要捨得買書，買好書，不好的的書不如不讀，其害大於其益，關於買什麼書，你可以問高手或看候捷的書評；准備一個小本子記錄你想買的書的名字，逛書店時看看，如果好就買下，記住要讀，別光買不看。） 10、我告訴你，程序就是：任何有目的的、預想好的動作序列，它是一種軟體。
11、編程序就是編寫程序。
12、你想好了嗎？（如果你想好了還是決定要當程序員，可以繼續往下讀；否則，你可以繼續尋找別的出路了。）
（三） 一個程序員應該具備的基礎知識和概念
1、計算機是有什麼組成的，CPU是什麼東西，其工作原理是什麼。（對於這些以及下面將要提到的概念我不會告訴你什麼答案，你可以看相應的教材，關於教材我會在下一部分詳述，記住理解最重要！）
2、機器語言和微指令集的概念。
3、程序的概念。
4、匯編語言是低級語言但不是機器語言。
5、高級語言主要有那些？（C，C＋＋，Basic，Pascal，Fortran，C#，java等等；如果你是中國軟體業的英雄，你也寫一門語言，最好不用英語） 6、編譯程序和解釋程序的概念和其原理。（編譯器是高手和專家編寫的）
7、HTML、XML等是標識性語言。
8、Prolog是人工智慧語言。
9、操作系統OS的概念和原理。（Windows98，Windows2000，Windows NT，UNIX，linux，等等都是OS，還有一些實時OS，嵌入OS，編這些的絕對是高手）
10、Windows編程說白了就是Windows API的調用。（中國的程序員很多隻是會編windows程序，用的是VB，我的建議是這些程序員頂多隻是低級編碼員，我稱其是coder）
11、VC＋＋、VB、BC、BCB、Delphi、VF等都只是編程的工具和環境，不是編程語言。
12、面向結構的設計概念。
13、面向對象的概念。（好好理解，兄弟，這個東西還是很重要的）
14、軟體工程的概念和原理。（如果你想當老總就需要好好研究了，系統分析員比編碼員要高一個等級，薪水也高喲）
15、資料庫的概念。（要熟悉一些著名的資料庫系統和語言的名字，如Orcle，SQL，DB2，DyBase等）
16、了解網路概念。
17、了解多媒體概念。
18、熟悉和掌握數據結構和基本演算法。
19、是不是要求太高了，別著急慢慢來，進步在不知不覺之中。（一旦開始學習，一個月以後你就會有一個基本的概念；兩個月以後你就會感覺自己有了全面的基礎知識；當你知道編程序是怎麼回事時，說明你已經入門了。也有很多人編了很多年程序還沒有入門呢，你不會希望自己步其後塵吧。要有信心和耐心。沉不住氣怎麼能成大事？！）
（四） 教材推薦
――－推薦的教材主要還是針對概念來的，最好選用名校的教學用書。
1、《計算機組成原理》（熟悉）
2、《數據結構》（掌握）
3、《操作系統》（了解->熟悉）
4、《The C language》（掌握）
5、《編譯原理》（了解原理）
6、《匯編語言》（了解）
7、《計算機網路》（了解）
8、《軟體工程》（了解）
9、《關系資料庫》（熟悉）
10、《The C＋＋Languege 》（掌握）
11、《面向對象設計》（掌握；結合C++學習）
（五）一些經驗和體會
1、真正的程序員用C++；（一位專家說的）
2、動手去編程序；
3、動腦去思考；
4、要有良好的編程風格；
5、讀書，讀好書，盡量讀原版書！（我反復強調這一點，讀書要有選擇，堅持讀好書，名家出的經典書，不要浪費實踐在一些粗製濫造的書上面；堅持博覽群書）
6、有自己的學習計劃；
7、總結自己的經驗教訓；（准備一個筆記本，記錄錯誤和心得）
8、不要怕學新東西；
9、要有軟體工程的思想；
10、善於發現問題，然後去尋找答案；
11、向高手請教；（要虛心直到你成為高手）
12、和同行交流；（不善於交流肯定不行）
13、懂得軟體的實質，不要被千變萬化的表象所迷惑；
14、真正要學慣用的是編程語言和方法，不是什麼庫，什麼類，什麼工具；（學用那些什麼庫都比較簡單，但光會這些庫，我覺得還遠遠不夠）
15、學習wiodows編程主要是學習windows OS和win32 API；
16、有空了解一下嵌入式開發；
17、有空了解一下PDA軟體開發；
18、了解一下.NET框架和C#語言，也許它是你新的衣食父母；
19、要有耐心，不要作浮躁的人；
20、對程序加註釋，並保留你的老程序；
21、學到的東西越多，了解的越多，你就越接近專家；
22、有空去逛逛CSDN，那裡有你很多知己；
23、要有信心成為一個優秀的程序；
（六）一些好書的推薦
1、《The C Programming language》 （Keinighan & Dennis Ritchie 1988）
2、《The C++ Programming Languague》（Bjarne Stroustrup 1997）
3、《Inside The C++ Object Model》 （lippmans）
4、《Effective C++》 （同上）
5、《More Effective C++》 （同上）
6、《Exceptional c++》
7、《C++面向對象高效編程》
8、《設計模式》
9、《Thinking In C++》
10、《The Standard C++ Bible》（一般推薦）
11、《The Art of Computer Programming 》
12、《Programming Windows》 （Charles Petzold）
13、《VC++5.0技術內幕》
14、《MFC 深入淺出》
15、《軟體需求》
16、《Advanced Windows》
17、《C++ primer》
18、《win32程序員參考手冊》
19、《用TCP/IP進行網際互連》
20、《COM 本質論》
（七）學習計劃
――－這個學習計劃是我個人定的，也共享給大家參考一下，共同進步吧。 1、《計算機組成原理》
2、《操作系統》
3、《數據結構》
4、《匯編語言》
5、《 C 》
6、《 C++ 》
7、《VC 技術內幕》
8、《Programming Windows》
9、《深入淺出MFC》
10、《Advanced Windows》
11、《Inside The C++ Object Model》
12、《Thinking in C++》
13、《Effective C++》
14、資料庫
15、網路
16、嵌入式OS和編程
17、硬體單片機
18、.NET和C#
19、軟體工程
20、UNIX和Linux

Ⅱ 如果，我想當一名程序員，如何從零開始

1、 程序員意味著要編程序。（如果你僅僅想得到一份高薪水的工作，喝喝咖啡就等老闆發薪水，我奉勸你還是另找一份更合適的工作，譬如練攤，真的，兄弟，這份工作不適合你）
2、你是學文的還是學理的，編程序也許需要浪漫，但更需要邏輯和嚴謹。（說坦白點就是，在你沒有找到樂趣以前，它很枯燥）
3、你有對新技術追求的熱情嗎？你有刨根問底的探索精神嗎？（熱情絕對是最重要的！你仔細思考一下自己的性格適合當程序員嗎？）
4、當程序員決不是什麼好差事，時刻需要學習，需要思考。（直到你成為那個可以引導別人去學習和思考的人，你才可以偷偷的嘿嘿笑，又一群傻蛋）
5、程序員的未來很迷茫。（但我認為關鍵看你自己！我希望你是一個有追求的人，不僅僅是混碗飯吃。因為真正的樂趣在於創造；如果你能改變軟體業的歷史，那才是英雄；不想成為Bill Gates，不想成為Dennis Ritchie和 Bjarne Stroustrup，我會說你沒有追求。有個關於程序員未來的笑話，也許你還沒聽過，你該聽一聽，摘抄如下：
一個程序員對自己的未來很迷茫，於是去問上帝。
「萬能的上帝呀，請你告訴我，我的未來會怎樣？」
上帝說「我的孩子，你去問Lippman，他現在領導的程序員的隊伍可能是地球上最大的」
於是他去問Lippman。
Lippman說「程序員的未來就是駕馭程序員」
這個程序員對這個未來不滿意，於是他又去問上帝。
「萬能的上帝呀，請你告訴我，我的未來會怎樣？」
上帝說「我的孩子，你去問Gates，他現在所擁有的財產可能是地球上最多的」
於是他去問Gates。
Gates說「程序員的未來就是榨取程序員」
這個程序員對這個未來不滿意，於是他又去問上帝。
「萬能的上帝呀，請你告訴我，我的未來會怎樣？」
上帝說「我的孩子，你去問侯捷，他寫的計算機書的讀者可能是地球上最多的」
於是他去問侯捷。
侯捷說「程序員的未來就是誘惑程序員」
這個程序員對這個未來不滿意，於是他又去問上帝。
「萬能的上帝呀，請你告訴我，我的未來會怎樣？」
上帝搖搖頭「唉，我的孩子，你還是別當程序員了」）
6、當程序員還是很有樂趣的。（當你學到新知識時，當你有新的思想見解時，當你有新的產品問世時，和知己探討你的成果時…我問你，覺得這些是樂趣嗎？）
7、當程序員不易也不難。（世間事有難易乎？為之…；不為…。你有決心和信心嗎？）
8、你真的要當程序員？是你自己的想法？
9、你捨得花錢買書嗎？（讀好書絕對是學習編程的最佳捷徑。你一定會說，現在電腦書籍真他XX的貴，沒法子，誰讓知識和技術在人家的腦袋，在人家的書里呢；等你寫書時可以把價格定低一點，記著還有好多沒錢但想買書的兄弟很困難呀。要捨得買書，買好書，不好的的書不如不讀，其害大於其益，關於買什麼書，你可以問高手或看候捷的書評；准備一個小本子記錄你想買的書的名字，逛書店時看看，如果好就買下，記住要讀，別光買不看。） 10、我告訴你，程序就是：任何有目的的、預想好的動作序列，它是一種軟體。
11、編程序就是編寫程序。
12、你想好了嗎？（如果你想好了還是決定要當程序員，可以繼續往下讀；否則，你可以繼續尋找別的出路了。）
（三） 一個程序員應該具備的基礎知識和概念
1、計算機是有什麼組成的，CPU是什麼東西，其工作原理是什麼。（對於這些以及下面將要提到的概念我不會告訴你什麼答案，你可以看相應的教材，關於教材我會在下一部分詳述，記住理解最重要！）
2、機器語言和微指令集的概念。
3、程序的概念。
4、匯編語言是低級語言但不是機器語言。
5、高級語言主要有那些？（C，C＋＋，Basic，Pascal，Fortran，C#，Java等等；如果你是中國軟體業的英雄，你也寫一門語言，最好不用英語） 6、編譯程序和解釋程序的概念和其原理。（編譯器是高手和專家編寫的）
7、HTML、XML等是標識性語言。
8、Prolog是人工智慧語言。
9、操作系統OS的概念和原理。（Windows98，Windows2000，Windows NT，UNIX，Linux，等等都是OS，還有一些實時OS，嵌入OS，編這些的絕對是高手）
10、Windows編程說白了就是Windows API的調用。（中國的程序員很多隻是會編windows程序，用的是VB，我的建議是這些程序員頂多隻是低級編碼員，我稱其是coder）
11、VC＋＋、VB、BC、BCB、Delphi、VF等都只是編程的工具和環境，不是編程語言。
12、面向結構的設計概念。
13、面向對象的概念。（好好理解，兄弟，這個東西還是很重要的）
14、軟體工程的概念和原理。（如果你想當老總就需要好好研究了，系統分析員比編碼員要高一個等級，薪水也高喲）
15、資料庫的概念。（要熟悉一些著名的資料庫系統和語言的名字，如Orcle，SQL，DB2，DyBase等）
16、了解網路概念。
17、了解多媒體概念。
18、熟悉和掌握數據結構和基本演算法。
19、是不是要求太高了，別著急慢慢來，進步在不知不覺之中。（一旦開始學習，一個月以後你就會有一個基本的概念；兩個月以後你就會感覺自己有了全面的基礎知識；當你知道編程序是怎麼回事時，說明你已經入門了。也有很多人編了很多年程序還沒有入門呢，你不會希望自己步其後塵吧。要有信心和耐心。沉不住氣怎麼能成大事？！）
（四） 教材推薦
――－推薦的教材主要還是針對概念來的，最好選用名校的教學用書。
1、《計算機組成原理》（熟悉）
2、《數據結構》（掌握）
3、《操作系統》（了解->熟悉）
4、《The C language》（掌握）
5、《編譯原理》（了解原理）
6、《匯編語言》（了解）
7、《計算機網路》（了解）
8、《軟體工程》（了解）
9、《關系資料庫》（熟悉）
10、《The C＋＋Languege 》（掌握）
11、《面向對象設計》（掌握；結合C++學習）
（五）一些經驗和體會
1、真正的程序員用C++；（一位專家說的）
2、動手去編程序；
3、動腦去思考；
4、要有良好的編程風格；
5、讀書，讀好書，盡量讀原版書！（我反復強調這一點，讀書要有選擇，堅持讀好書，名家出的經典書，不要浪費實踐在一些粗製濫造的書上面；堅持博覽群書）
6、有自己的學習計劃；
7、總結自己的經驗教訓；（准備一個筆記本，記錄錯誤和心得）
8、不要怕學新東西；
9、要有軟體工程的思想；
10、善於發現問題，然後去尋找答案；
11、向高手請教；（要虛心直到你成為高手）
12、和同行交流；（不善於交流肯定不行）
13、懂得軟體的實質，不要被千變萬化的表象所迷惑；
14、真正要學慣用的是編程語言和方法，不是什麼庫，什麼類，什麼工具；（學用那些什麼庫都比較簡單，但光會這些庫，我覺得還遠遠不夠）
15、學習wiodows編程主要是學習windows OS和win32 API；
16、有空了解一下嵌入式開發；
17、有空了解一下PDA軟體開發；
18、了解一下.NET框架和C#語言，也許它是你新的衣食父母；
19、要有耐心，不要作浮躁的人； 20、對程序加註釋，並保留你的老程序；
21、學到的東西越多，了解的越多，你就越接近專家；
22、有空去逛逛CSDN，那裡有你很多知己；
23、要有信心成為一個優秀的程序；
（六）一些好書的推薦
1、《The C Programming language》 （Keinighan & Dennis Ritchie 1988）
2、《The C++ Programming Languague》（Bjarne Stroustrup 1997）
3、《Inside The C++ Object Model》 （lippmans）
4、《Effective C++》 （同上）
5、《More Effective C++》 （同上）
6、《Exceptional c++》
7、《C++面向對象高效編程》
8、《設計模式》
9、《Thinking In C++》
10、《The Standard C++ Bible》（一般推薦）
11、《The Art of Computer Programming 》
12、《Programming Windows》 （Charles Petzold）
13、《VC++5.0技術內幕》
14、《MFC 深入淺出》
15、《軟體需求》
16、《Advanced Windows》
17、《C++ primer》
18、《win32程序員參考手冊》
19、《用TCP/IP進行網際互連》
20、《COM 本質論》
（七）學習計劃
――－這個學習計劃是我個人定的，也共享給大家參考一下，共同進步吧。 1、《計算機組成原理》
2、《操作系統》
3、《數據結構》
4、《匯編語言》
5、《 C 》
6、《 C++ 》
7、《VC 技術內幕》
8、《Programming Windows》
9、《深入淺出MFC》
10、《Advanced Windows》
11、《Inside The C++ Object Model》
12、《Thinking in C++》
13、《Effective C++》
14、資料庫
15、網路
16、嵌入式OS和編程
17、硬體單片機
18、.NET和C#
19、軟體工程
20、UNIX和Linux

Ⅲ 工作多年後，有哪些工作經驗了是「血淚的教訓」

前幾天，打開知乎的「職場」話題，發現最多人關注的問題是：你有哪些特別的生存法則？

除此之外，還有很多類似的熱門話題，例如：

你有哪些工作多年後才明白的道理？

有哪些大家不說，但需要知道的社會規則？

工作後，你悟出什麼職場道理？

......

可見，職場「潛規則」是很多人關心的話題。尤其是一些初入職場的菜鳥新秀，很多人都想提前掌握一些不成文的「潛規則」，以便讓自己在職場上游刃有餘。

今天，我從幾百條回答中，挑選了3條引起我最深共鳴的內容，和你分享。希望可以對你有所啟發。

3自己的能力，才是真正的「鐵飯碗」

最近，一個研究生剛畢業的同學想離職。

因為父母希望她回家考公務員，對她說，考上公務員，就等於找到一個鐵飯碗，還事少離家近，這遠遠比你留在一線城市的創業公司靠譜得多。

其實，這位同學非常優秀，畢業不到半年就月薪過萬，還是公司重點栽培的對象。

可「鐵飯碗」的誘惑，還是讓她動搖了。

「鐵飯碗」之所以讓無數人趨之若鶩，無非是因為，它能給予人極高的安全感、穩定性。但鐵飯碗真的有你想的那麼「鐵」嗎？

姑且不論各個國企掀起的裁員風波、合同制，即使你進入了所謂的穩定單位，又能如何呢？

事實上，很多單位里的勾心鬥角能讓人直接被擊垮，一切都要談關系、談後台。你該如何保證自己不會成為勾心鬥角的「炮灰」？

那麼，什麼才是最可靠、最穩定的？未來學家托夫勒在他的《權力的轉移》一書中指出：

人類歷史上權力的來源已經從暴力、財富轉移到知識，知識將顛覆全球的權力格局。

我們不難發現，在當今社會環境下，真正有價值的工作，都是需要知識的工作。即使你半身不遂、喪失語言能力、常年坐著輪椅，但只要有發達的腦力，也一樣能發光發熱。

就比如，當代最著名的物理學家霍金，就是在這樣的身體條件下，寫下了名著《時間簡史：從大爆炸到黑洞》。

所以，根本沒有所謂的穩定，只有自己的能力，才是真正的鐵飯碗。

總結

很多人常說，聽過很多道理，卻依然過不好這一生。

其實，職場潛規則同樣如此，每個人根據自己的工作經歷，會得出不同的經驗教訓。

如果只是一味的看他人的「血淚教訓」，最終可能變成：「聽了很多職場潛規則，卻依然做不好工作」。

在職業成長過程中，有些道理只有自己經歷了才會更懂得。

就像這8個字所說：「理可頓悟，事須漸修。」

Ⅳ 做一個新手程序員應具體哪些知識

程序員是一種技術工作，在IT的發展中有相當重要的地位，從底層硬體通訊協議的建立， 到數據傳輸層的處理，到操作系統的建設，到資料庫平台的建設，一直到應用層上各種數 據營銷平台的搭建，程序員在裡面都扮演著舉足輕重的角色並為IT事業的發展做出了巨大 的貢獻。

中國有很多精於編碼的人，但是中國軟體行業，尤其是網路應用開發方面誤區很大，很難形成有規模的軟體開發力量和產品能力，不但比美國差距甚遠，和印度相比也是頗有不如。這些問題不是在於中國程序員的智商和工作努力狀況，也不是在於國家和民間對開發的投入程度，而是很大程度上，有一些對技術，對程序開發，對項目設計方面的思想誤區，這些誤區，導致了軟體行業的產品化能力不足，缺乏規模化和大型復用系統研發能力，可以說，改變認識誤區，是解決軟體行業小作坊模式和個體英雄模式所帶來的局限性 的重要工作。

中國有很多小朋友，他們18,9歲或21,2歲，通過自學也寫了不少代碼，他們有的代碼寫的很漂亮，一些技術細節相當出眾，也很有鑽研精神，但是他們被一些錯誤的認識和觀點左右，缺乏對系統，對程序的整體理解能力，這些人，一個網上的朋友說得很好，他們實際 上只是一些Coding fans，壓根沒有資格稱為程序員，但是據我所知，不少小網路公司的 CTO就是這樣的coding fans,拿著嚇人的工資，做著嚇人的項目，項目的結局通常也很嚇 人。

程序員基本素質：

作一個真正合格的程序員，或者說就是可以真正合格完成一些代碼工作的程序員，應該具 有的素質。

1：團隊精神和協作能力

把它作為基本素質，並不是不重要，恰恰相反，這是程序員應該具備的最基本的，也是最重要的安身立命之本。把高水平程序員說成獨行俠的都是在囈語，任何個人的力量都是有限的，即便如linus這樣的天才，也需要通過組成強大的團隊來創造奇跡，那些遍布全球的為linux寫核心的高手們，沒有協作精神是不可想像的。獨行俠可以作一些賺錢的小軟體發點小財，但是一旦進入一些大系統的研發團隊，進入商業化和產品化的開發任務，缺 乏這種素質的人就完全不合格了。

2：文檔習慣

說高水平程序員從來不寫文檔的肯定是乳臭未乾的毛孩子，良好的文檔是正規研發流程中 非常重要的環節，作為代碼程序員，30％的工作時間寫技術文檔是很正常的，而作為高級 程序員和系統分析員，這個比例還要高很多。

缺乏文檔，一個軟體系統就缺乏生命力，在未來的查錯，升級以及模塊的復用時就都會遇 到極大的麻煩。

3：規范化，標准化的代碼編寫習慣

作為一些外國知名軟體公司的規矩，代碼的變數命名，代碼內注釋格式，甚至嵌套中行縮 進的長度和函數間的空行數字都有明確規定，良好的編寫習慣，不但有助於代碼的移植和 糾錯，也有助於不同技術人員之間的協作。

有些coding fans叫囂高水平程序員寫的代碼旁人從來看不懂，這種叫囂只能證明他們自 己壓根不配自稱程序員。代碼具有良好的可讀性，是程序員基本的素質需求。

再看看整個linux的搭建，沒有規范化和標准化的代碼習慣，全球的研發協作是絕對不可 想像的。

4：需求理解能力

程序員需要理解一個模塊的需求，很多小朋友寫程序往往只關注一個功能需求，他們把性能指標全部歸結到硬體，操作系統和開發環境上，而忽視了本身代碼的性能考慮，有人曾經放言說寫一個廣告交換程序很簡單，這種人從來不知道在百萬甚至千萬數量級的訪問情況下的性能指標是如何實現的，對於這樣的程序員，你給他深藍那套系統，他也做不出太極鏈的並訪能力。性能需求指標中，穩定性，並訪支撐能力以及安全性都很重要，作為程序員需要評估該模塊在系統運營中所處的環境，將要受到的負荷壓力以及各種潛在的危險和惡意攻擊的可能性。就這一點，一個成熟的程序員至少需要2到3年的項目研發和跟蹤經 驗才有可能有心得。

5：復用性，模塊化思維能力

經常可以聽到一些程序員有這樣的抱怨，寫了幾年程序，變成了熟練工，每天都是重復寫 一些沒有任何新意的代碼，這其實是中國軟體人才最大浪費的地方，一些重復性工作變成 了熟練程序員的主要工作，而這些，其實是完全可以避免的。

復用性設計，模塊化思維就是要程序員在完成任何一個功能模塊或函數的時候，要多想一些，不要局限在完成當前任務的簡單思路上，想想看該模塊是否可以脫離這個系統存在，是否可以通過簡單的修改參數的方式在其他系統和應用環境下直接引用，這樣就能極大避免重復性的開發工作，如果一個軟體研發單位和工作組能夠在每一次研發過程中都考慮到這些問題，那麼程序員就不會在重復性的工作中耽誤太多時間，就會有更多時間和精力投 入到創新的代碼工作中去。

一些好的程序模塊代碼，即便是70年代寫成的，拿到現在放到一些系統裡面作為功能模塊 都能適合的很好，而現在我看到的是，很多小公司軟體一升級或改進就動輒全部代碼重 寫，大部分重復性工作無謂的浪費了時間和精力。

程序員應具備的素質中

6：測試習慣

作為一些商業化正規化的開發而言，專職的測試工程師是不可少的，但是並不是說有了專職的測試工程師程序員就可以不進行自測；軟體研發作為一項工程而言，一個很重要的特點就是問題發現的越早，解決的代價就越低，程序員在每段代碼，每個子模塊完成後進行認真的測試，就可以盡量將一些潛在的問題最早的發現和解決，這樣對整體系統建設的效 率和可靠性就有了最大的保證。

測試工作實際上需要考慮兩方面，一方面是正常調用的測試，也就是看程序是否能在正常調用下完成基本功能，這是最基本的測試職責，可惜在很多公司這成了唯一的測試任務，實際上還差的遠那；第二方面就是異常調用的測試，比如高壓力負荷下的穩定性測試，用戶潛在的異常輸入情況下的測試，整體系統局部故障情況下該模塊受影響狀況的測試，頻發的異常請求阻塞資源時的模塊穩定測試等等。當然並不是程序員要對自己的每段代碼都需要進行這種完整測試，但是程序員必須清醒認識自己的代碼任務在整體項目中的地位和各種性能需求，有針對性的進行相關測試並盡早發現和解決問題，當然這需要上面提到的 需求理解能力。

7：學習和總結的能力

程序員是人才很容易被淘汰，很容易落伍的職業，因為一種技術可能僅僅在三兩年內具有 領先性，程序員如果想安身立命，就必須不斷跟進新的技術，學習新的技能。

善於學習，對於任何職業而言，都是前進所必需的動力，對於程序員，這種要求就更加高 了。

但是學習也要找對目標，一些小coding fans們，他們也津津樂道於他們的學習能力，一會學會了asp，一會兒學會了php，一會兒學會了jsp，他們把這個作為炫耀的資本，盲目的追逐一些膚淺的，表面的東西和名詞，做網路程序不懂通訊傳輸協議，做應用程序不懂中斷向量處理，這樣的技術人員，不管掌握了多少所謂的新語言，永遠不會有質的提 高。

善於總結，也是學習能力的一種體現，每次完成一個研發任務，完成一段代碼，都應當有 目的的跟蹤該程序的應用狀況和用戶反饋，隨時總結，找到自己的不足，這樣逐步提高， 一個程序員才可能成長起來。

一個不具備成長性的程序員，即便眼前看是個高手，建議也不要選用，因為他落伍的時候 馬上就到了。

具備以上全部素質的人，應當說是夠格的程序員了，請注意以上的各種素質都不是由IQ決 定的，也不是大學某些課本里可以學習到的，需要的僅僅是程序員對自己工作的認識，是 一種意識上的問題。

那麼作為高級程序員，以至於系統分析員，也就是對於一個程序項目的設計者而言，除了 應該具備上述全部素質之外，還需要具備以下素質：

第一，需求分析能力

對於程序員而言，理解需求就可以完成合格的代碼，但是對於研發項目的組織和管理者， 他們不但要理解客戶需求，更多時候還要自行制定一些需求，為什麼這么說呢？

一般而言，進行研發任務，也許是客戶提出需求，也許是市場和營銷部門提出的需求，這時候對於研發部門，他們看到的不是一個完整的需求，通常而言，該需求僅僅是一些功能上的要求，或者更正規些，可能獲得一個完整的用戶視圖；但是這都不夠，因為客戶由於非技術因素多一些，他們可能很難提出完整和清晰，或者說專業性的性能需求，但是對於項目組織者和規劃者，他必須能夠清醒認識到這些需求的存在並在完成需求分析報告的時候適當的提出，同時要完整和清晰的體現在設計說明書裡面，以便於程序員編碼時不會失 去這些准則。

程序設計者必須正確理解用戶需求所處的環境，並針對性做出需求的分析，舉例而言，同樣一個軟體通過ASP租用方式發布和通過License方式發布，性能需求可能就是有區別的，前者強調的是更好的支撐能力和穩定性，而後者則可能更強調在各種平台下的普適性和安 裝使用的簡捷性。

第二，項目設計方法和流程處理能力

程序設計者必須能夠掌握不少於兩到三種的項目設計方法（比如自頂至下的設計方法，比 如快速原型法等等），並能夠根據項目需求和資源搭配來選擇合適的設計方法進行項目的 整體設計。

設計方法上選擇不當，就會耽誤研發周期，浪費研發資源，甚至影響研發效果。

一個程序設計者還需要把很多功夫用在流程圖的設計和處理上，他需要做數據流圖以確立 數據詞典；他需要加工邏輯流圖以形成整體的系統處理流程。

一個流程有問題的系統，就算代碼多漂亮，每個模塊多精緻，也不會成為一個好的系統。 當然，做好流程分析並選擇好項目設計方法，都需要在需求分析能力上具有足夠的把 握。

第三，復用設計和模塊化分解能力

這個似乎又是老調重談，前面基本素質上不是已經說明了這個問題嗎？

作為一個從事模塊任務的程序員，他需要對他所面對的特定功能模塊的復用性進行考慮，而作為一個系統分析人員，他要面對的問題復雜的多，需要對整體系統按照一種模塊化的分析能力分解為很多可復用的功能模塊和函數，並針對每一模塊形成一個獨立的設計需求。舉個例子，好比是汽車生產，最早每輛汽車都是獨立安裝的，每個部件都是量身定做的，但是後來不一樣了，機器化大生產了，一個汽車廠開始通過流水線來生產汽車，獨立部件開始具有一定的復用性，在後來標准化成為大趨勢，不同型號，品牌甚至不同廠商的汽車部件也可以進行方便的換裝和升級，這時候，汽車生產的效率達到最大化。軟體工程也是同樣的道理，一個成熟的軟體行業，在一些相關項目和系統中，不同的部件是可以隨意換裝的，比如微軟的許多桌面軟體，在很多操作模塊（如打開文件，保存文件等等）都是復用的同一套功能模塊，而這些介面又通過一些類庫提供給了桌面應用程序開發者方便 掛接，這就是復用化的模塊設計明顯的一個佐證。

將一個大型的，錯綜復雜的應用系統分解成一些相對獨立的，具有高度復用性的，並能僅 僅依靠幾個參數完成數據聯系的模塊組合，是作為高級程序員和系統分析員一項最重要的 工作，合適的項目設計方法，清晰的流程圖，是實現這一目標的重要保證。

第四，整體項目評估能力

作為系統設計人員，必須能夠從全局出發，對項目又整體的清醒認識，比如公司的資源配置是否合理和到位，比如工程進度安排是否能最大化體現效率又不至於無法按期完成。評估項目整體和各個模塊的工作量，評估項目所需的資源，評估項目可能遇到的困難，都需要大量的經驗積累，換言之，這是一種不斷總結的累計才能達到的境界。在西方一些軟體系統設計的帶頭人都是很年長的，比如4，50歲，甚至更老，他們在編碼方面已經遠遠不如年輕人那樣活絡，但是就項目評估而言，他們幾十年的經驗積累就是最重要和寶貴的財富。中國缺這么一代程序員，主要還不是缺那種年紀的程序員，而是那種年紀的程序員基本上都是研究單位作出來的，都不是從專業的產品化軟體研發作出來的，他們沒有能積累 那種產品化研發的經驗，這也是沒有辦法的事情。

程序員應具備的素質下

第五，團隊組織管理能力

完成一個項目工程，需要團隊的齊心協力，作為項目設計者或研發的主管人，就應當有能 力最大化發揮團隊的整體力量，技術管理由於其專業性質，不大同於一般的人事管理，因 為這裡面設計了一些技術性的指標和因素。

首先是工作的量化，沒有量化就很難做到合適的績效考核，而程序量化又不是簡單的代碼 行數可以計算的，因此要求技術管理人員需要能真正評估一個模塊的復雜性和工作量。

其次是對團隊協作模式的調整，一般而言，程序開發的協作通常分為小組進行，小組有主 程序員方式的，也有民主方式的，根據程序員之間的能力水平差距，以及根據項目研發的 需求，選擇合適的組隊方式，並能將責權和成員的工作任務緊密結合，這樣才能最大發揮 組隊的效率。

一個代碼水平高的人，未必能成為一個合格的項目研發主管，這方面的能力欠缺往往是容 易被忽視的。

綜上可以看到，作為一個主管研發的負責人，一個項目設計者，所需要具備的素質和能力並不是程序代碼編寫的能力，當然一般情況下，一個程序員通過不斷的總結提高達到了這種素質的時候，他所具有的代碼編寫能力也已經相當不簡單了，但是請注意這裡面的因果關系，一個高水平的項目設計者通常已經是代碼編寫相當優秀的人了，但是並不是一個代碼相當優秀的程序員就可以勝任項目設計的工作，這裡面存在的也不是智商和課本的問題，還是在於一個程序員在積累經驗，逐步提升的時候沒有意識到應當思考哪方面的東西，沒有有意識的就項目的組織和復用設計進行揣摩，沒有經常性的文檔習慣和總結習 慣，不改變這些，我們的合格的項目設計者還是非常欠缺。

另外，為防止有無聊的人和我較真，補充一點，本文針對目標是作商業化的軟體項目和工程，那些科研機構的編程高手，比如演算法高手，比如圖象處理高手，他們的工作是研究課題而非直接完成商業軟體（當然最終間接成為商業產品，比如微軟研究院在作的研究課題），因此他們強調的素質可能是另外的東西，這些人（專家），並不能說是程序員，不 能用程序員的標准去衡量。

最後補充一點東西，一個軟體項目研發的設計流程是怎樣的呢？以通常標準的設計方法為 例，（不過筆者喜歡快速原型法）。

第一個步驟是市場調研，技術和市場要結合才能體現最大價值。

第二個步驟是需求分析，這個階段需要出三樣東西，用戶視圖，數據詞典和用戶操作手 冊。

用戶視圖是該軟體用戶（包括終端用戶和管理用戶）所能看到的頁面樣式，這裡麵包含了 很多操作方面的流程和條件。

數據詞典是指明數據邏輯關系並加以整理的東東，完成了數據詞典，資料庫的設計就完成 了一半多。

用戶操作手冊是指明了操作流程的說明書。

請注意，用戶操作流程和用戶視圖是由需求決定的，因此應該在軟體設計之前完成，完成 這些，就為程序研發提供了約束和准繩，很遺憾太多公司都不是這樣做的，因果顛倒，順 序不分，開發工作和實際需求往往因此產生隔閡脫節的現象。

需求分析，除了以上工作，筆者以為作為項目設計者應當完整的做出項目的性能需求說明 書，因為往往性能需求只有懂技術的人才可能理解，這就需要技術專家和需求方（客戶或 公司市場部門）能夠有真正的溝通和了解。

第三個步驟是概要設計，將系統功能模塊初步劃分，並給出合理的研發流程和資源要求。作為快速原型設計方法，完成概要設計就可以進入編碼階段了，通常採用這種方法是因為涉及的研發任務屬於新領域，技術主管人員一上來無法給出明確的詳細設計說明書，但是並不是說詳細設計說明書不重要，事實上快速原型法在完成原型代碼後，根據評測結果和 經驗教訓的總結，還要重新進行詳細設計的步驟。

第四個步驟是詳細設計，這是考驗技術專家設計思維的重要關卡，詳細設計說明書應當把具體的模塊以最』干凈』的方式(黑箱結構）提供給編碼者，使得系統整體模塊化達到最大；一份好的詳細設計說明書，可以使編碼的復雜性減低到最低，實際上，嚴格的講詳細設計說明書應當把每個函數的每個參數的定義都精精細細的提供出來，從需求分析到概要設計到完成詳細設計說明書，一個軟體項目就應當說完成了一半了。換言之，一個大型軟 件系統在完成了一半的時候，其實還沒有開始一行代碼工作。

那些把作軟體的程序員簡單理解為寫代碼的，就從根子上犯了錯誤了。

第五個步驟是編碼，在規范化的研發流程中，編碼工作在整個項目流程里最多不會超過1/ 2，通常在1/3的時間，所謂磨刀不誤砍柴功，設計過程完成的好，編碼效率就會極大提高，編碼時不同模塊之間的進度協調和協作是最需要小心的，也許一個小模塊的問題就可能影響了整體進度，讓很多程序員因此被迫停下工作等待，這種問題在很多研發過程中都出現過。編碼時的相互溝通和應急的解決手段都是相當重要的，對於程序員而言，bug永遠存在，你必須永遠面對這個問題，大名鼎鼎的微軟，可曾有連續三個月不發補丁的時候 嗎？從來沒有！

第六個步驟是測試

測試有很多種：

按照測試執行方，可以分為內部測試和外部測試

按照測試范圍，可以分為模塊測試和整體聯調

按照測試條件，可以分為正常操作情況測試和異常情況測試

按照測試的輸入范圍，可以分為全覆蓋測試和抽樣測試

以上都很好理解，不再解釋。

總之，測試同樣是項目研發中一個相當重要的步驟，對於一個大型軟體，3個月到1年的外 部測試都是正常的，因為永遠都會又不可預料的問題存在。

完成測試後，完成驗收並完成最後的一些幫助文檔，整體項目才算告一段落，當然日後少 不了升級，修補等等工作，只要不是想通過一錘子買賣騙錢，就要不停的跟蹤軟體的運營 狀況並持續修補升級，知道這個軟體被徹底淘汰為止。

寫這些步驟算不上賣弄什麼，因為實話講我手邊是一本《軟體工程》，在大學里這是計算機專業的必修課程，但是我知道很多程序員似乎從來都只是熱衷於什麼《30天精通VC》之類的，他們有些和我一樣游擊隊出身，沒有正規學過這個專業，還有一些則早就在混夠學 分後就把這些真正有用的東西還給了老師。

網上現在也很浮躁，一些coding fans亂嚷嚷，混淆視聽，實際上真正的技術專家很少在網上亂發帖子的，如筆者這樣不知天高地厚的，其實實在是算不上什麼高手，只不過看不慣這種對技術，對程序員的誤解和胡說，只好挺身而出，做撥亂反正之言，也希望那些還 沉迷於一些錯誤人士的coding fans們能認真想想，走到正途上，畢竟那些聰明的頭腦還 遠遠沒有發揮應有的價值。

Ⅳ 作為一個程序員，應該有哪些必須知道的事

1. 懂得分享。盡可能使用開源，並且當你有能力的時候，要對其有所貢獻。聚全社會之智慧，勝過某些「大」公司之短視。
2. 公平競爭。嘗試其他技術、框架、方法和觀點。不要總以為只有你的選擇才是可行的。別的選擇也有可能比你的要強得多。要以開放的心態，來檢驗其他人的選擇。
3. 不要攻擊他人。像第2條所說的，不要僅僅因為別人恰巧使用.Net、Java或PHP就去攻擊他們(我在這方面有一次教訓)。有時，它們或許要比你所認為的更有效。只要別人不是一無是處，你就可以從他們那裡學到很多東西。
4. 自我完善。盡量發布可以運行的代碼。不要指望QA能給你找出所有的程序錯誤。要經常並且全面深入地測試你的代碼。
5. 傷害他人要道歉。代碼審查是一個不錯但很少用的想法。指導經驗比你少的程序員，有助於整個團隊。不要公開批評他人。指導並不是貶低別人。別人有時候會接受，有時候不接受。其實，有時候你可能會從自認為水平不如你的人身上學到很多東西。
6. 未雨綢繆。動手寫代碼之前要盡量理解要解決的問題。要做原型、從網上查找實例、跟其他也做這個的人討論或者只是練練手而已。構建你從未做過或用過的東西是個壞習慣。如果開始就有思路，結果可能會更好。
7. 拿得起放得下。不要害怕替換、重寫、重構或者放棄垃圾代碼。有時候，如果碰到可留可不留的代碼，直接扔掉才是上策。永遠不要愛上你的代碼。
8. 平衡生活——學習、思考、繪畫、唱歌、跳舞、工作、玩耍，每樣都會一點。我喜歡Google的方式，在那裡，你有20%的時間用來思考任何你認為值得做的事情。老闆應該提供休息室、娛樂室或者一些能讓人放鬆清醒的環境。
9.編程是一項艱苦的腦力勞動活；有時你的大腦確實需要休息一下。拒絕例行公事地每周工作80小時，否則你的工作質量將大打折扣，花費大量時間取得的成果將前功盡棄。另外，如何釋放工作生活壓力，可以參考伯樂在線的這篇文章：《3步釋放工作和生活壓力》。
10. 每天下午小憩一會。每天工作24小時不會讓你更有效率。休息、回家，然後打個盹。通常，很多難題是在我回家的時候解決掉的，解決方法通常在我開車時或第二天早上突然想到。
11. 不要閉門造車。讀讀博客、學習新語言和框架、參與討論以及看看同行在干什麼。兩耳不聞業界事，你就無法成為一名更優秀的程序員。
12. 保持好奇心。想想塑料杯中的種子：根向下長，枝葉向上長，沒有人知道這是為什麼，但是我們都是這樣的。一般來說，在編程和技術世界，每天都有新奇東西出現。看！很神奇吧！每天學習，讓你思維更廣，技能更新，選擇也就更廣。如果你認為編程枯燥乏味，那麼你要該換行了。

Ⅵ 一個剛入職兩天的程序員，感覺自己做不來這份工作，剛來什麼都不會，給的小任務也不知道怎麼做

沉下氣來，靜下心來，這點適應性都沒還能做什麼？做不來是因為還沒入門，看書，上網查，上論壇請教，這樣能縮短入門時間。另外一個事情就是跟同事套近乎，跟前輩請教公司的歷史，業務，這樣充實一下腦子，熟悉一下環境。現在做不來一是環境陌生，二是遇到困難便退縮的性格；兩個月後發現做不來，那時要找出真做不來的原因，不夠勤奮？基礎不扎實？同事間相處不好？態度不端正？。。。。打工生活僅能維持生存罷了，學到的知識，積累的人脈，辦事的能力才是最寶貴，永恆的財富。年輕人，不要輕言放棄！

Ⅶ 程序員，在開發的過程中應該注意哪些安全方面的問題

可忽視的誤區 企業的軟體開發能力取決於該企業的軟體過程能力。如果一個企業軟體過程能力越成熟，那麼該企業的軟體開發能力就越有保證。大量的實踐經驗表明，在體現企業軟體開發能力的因素中，技術或工具並不是第一位的。其實，許多問題不是出在不懂怎麼做，而是沒有安排做，做的次序不對，或不知道怎樣做得更好。 目前，比照軟體過程管理模型（如圖一），中國的軟體企業中還存在各種影響過程改進的因素和誤區，主要表現在個體和組織兩個方面。 在組織方面，首先，中國軟體企業實施CMM往往缺乏高級管理者的支持。其次，沒有足夠的SEPG資源。從很多情況考慮，SEPG成員要比其他CMM相關組綜合素質高一個層次，CMM相關組的管理素質需要比技術類組高一個層次，才能順利開展工作。第三，沒有合適的先行者或者沒有適當全局觀的項目經理配合。被組織選為先行者的人員經常說自己沒有時間，由於這些人都是從各個項目中抽出來的，一般人很難有足夠的權力讓他們為配合CMM做工作。最後，軟體組織缺乏足夠詳細的項目計劃和監督調整機制。 在個體方面，首先，手工作坊式的個人英雄主義情結成為實施CMM的制約。其次，某些軟體開發人員錯誤地認為過程管理會影響或壓抑專業人員的創造性，其實這是不清楚過程的定義造成的。第三，由於軟體項目的成功更多地依賴於少數人員的傑出技術能力和項目管理能力，成功項目的經驗不能得到最大限度的繼承，軟體生產的可重復性相對比較差。最後，軟體企業人員變更相對頻繁也增加了實施CMM的難度。 「三七」法則 在過程改進總體建議方面，應該從三個方面做准備，分七步走。 首先，在組織方面的准備上，除了要求高層經理出資支持CMM改善軟體過程，委託具有管理職責的人員負責CMM實施之外，須成立軟體工程過程組（SEPG），研究CMM、編寫/修改必要的文檔並推廣文檔；成立軟體質量保證組（SQAG），研究軟體質量保證技術及過程，編寫/修改必要的SQA文檔並推廣已編寫的文檔，測量和分析項目進展情況，反饋項目過程狀態，准備和評審過程、計劃和標准，審計指定的軟體工作產品以檢驗其遵從性，審計軟體工作過程的符合性；成立軟體配置管理組（SCMG），研究軟體配置管理技術及過程，編寫/修改必要的SCM文檔並推廣已編寫的文檔，建立必要的工具支持。 在知識准備方面，要加強培訓工作，建立內部過程評估隊伍和龐大的過程改善隊伍。對各角色人員進行專項培訓，普遍開展軟體工程基礎及CMM的培訓，使每個崗位的人員都具備過程改進的意識，並掌握所必需的過程改進知識和技能。此外，要重視對軟體工程的研究，包括方法、工具和過程，加速培養過程改進的骨幹隊伍。 在能力准備方面，建立有效的軟體項目管理，文檔化且遵循軟體項目管理過程，在建立管理過程中，使用組織的方針來指導項目，建立基本軟體工作產品完成准則和檢查單，並迅速實施，然後根據反饋意見及時修改。堅持適當的監控機制，例如對項目進度進行跟蹤而建立的例會制度，制度化的日報和周報活動。做好實際數據收集、測量與分析工作等。重復成功的以前項目的開發經驗。 改進過程總體可以分為以下七個步驟。 確定目標：確定在一段時間內達到的改進等級。 狀態診斷：把過程改進要達到的狀態與目前的狀態作比較，找出存在的差距。 制定計劃：「凡事有計劃，按計劃辦」不僅是CMM強調的，也是軟體開發過程中應該注意的。 規程制定：過程改進的一個重要的地方就是「事事有規程，時時有記錄」，這樣，即使關鍵人走了，原來的事也能繼續而不致產生過多的停頓。 過程試點：制定了規程後，要對行動計劃按執行過程的情況進行適當調整。其中，尤其要注重評審和驗證，實現定期監控，注意採集度量數據。 反饋修正：總結過程試點的經驗，修訂規程。 過程推廣：擴大應用范圍。 軟體過程改進實施步驟 公司的過程改進活動也是一個項目，並且是很大的項目，涉及的人員、技術和資源都很多，還要平衡現有產品或項目的進度等。同時，它也是一個不斷往復，螺旋上升的一個過程。 第一個步驟為高級經理下定決心，提供足夠的資源來主持並完成前期的准備工作，這個階段核心是評價SEPG組長的資格和資質，還包括評估培訓、購買工具的預算及相應資金能否及時到位。 無論是軟體商業化的過程或CMM實施的過程之中，建立規范化的易於操作的軟體開發行為規范都是首先要做的工作。但是，切記，編制規范的時間一定不能長，以10到12個工作日為宜，文檔不宜過多，以5～6個規程為好（對應5個或6個關鍵過程域），這是第二個關鍵階段。評價標准可以是SEPG組長能夠順利、流暢地講解其制定的規程。在規程編制階段必須有老闆或常務副總直接領導CMM工作。但是一定要記住，制定的過程要遵從「從實踐中來，到實踐中去」，同項目經理、有經驗的開發人員研究、討論，從而使SEPG組長能夠及時反映工作中的問題，並且問題能夠得到及時解決。 第三個步驟是制定並發布公司的評估方針和方案，包括開發體系重組過程中的激勵措施，中層在此階段必須介入，這關系著過程改進的結果。SEPG和CMM實施的周例會，必須有高級經理參加，要有記錄或錄音作為證據，是考核的一個指標。 除此之外，對於還沒有進行基於CMM改進的企業，還要重視設計復查、代碼復查以及測試工作 。很多程序員習慣於「只做不想」這樣一種工作方式，他們更關心每天可以寫多少行代碼，完成幾個模塊，在這種態度下，他們都很不願意復查自己的工作，而習慣於在軟體測試階段把隱藏的錯誤改正過來。CMM實施過程，就是要通過各種復查，溝通信息，及早發現並更改問題。 在實施了初始的過程或技術部署後，培訓成了主要問題。但人員變動時，附加培訓的必要可能沒被認識到，管理技能的培訓尤為重要。而對於那些由於過硬的技術而被提升到管理職位的人員，需要接受一整套新技能的培訓，包括人際關系技能。 項目經理在整個過程改進中（尤其是CMM二級）的工作量大約要佔到整個總量的一半到四分之三，在評估訪談時也佔有了舉足輕重的地位。有些項目經理認為自己心裡有一套計劃，只要按計劃進行就可以按時保質完成項目，但事實並非如此，在項目組之間的協調問題上，高層經理的作用是非常明顯的。 試點或模擬項目可以很小，哪怕只有兩個人，或者聯合SEPG進行指導全部公司的模擬項目，這是縮短試驗的最好途徑。先組織配置管理活動的培訓或學習，配置管理活動和質量保證活動在此期間可以得到很好的練習。 CMM為軟體企業的過程能力提供了一個階梯式的改進框架，它基於過去所有軟體工程過程改進的成果，吸取了以往軟體工程的經驗教訓，提供了一個基於過程改進的框架; 它指明了一個軟體組織在軟體開發方面需要管理哪些主要工作、這些工作之間的關系、以及以怎樣的先後次序，一步一步地做好這些工作而使軟體組織走向成熟。 但是由於CMM中不研究所有軟體過程和質量改進問題，也未提供有關實現子過程域所需要的具體知識和技能，因此要進行個體軟體過程PSP的實踐活動，以填補這一空白，並優化過程改進途徑。

Ⅷ 一個程序員需要有怎樣的自我修養

作為一名程序員，一個「程序員的自我修養」是什麼？
盡管我們不一定要像尹天仇那麼的認真對待自己的事業，但，一些基本的修養，作為一名新時代的碼農，總應該是要具備的吧。不過真要說修養，方面還是挺多的，技術自我提示自不必說。但我並不打算從這個大家都覺得理所當然的技術方面入手，而是談談，可讀性代碼，這個容易被大家忽視的基本素養。
1、遵從所在團隊的代碼規范。
一個高效、成熟的團隊，必定有一個屬於自己的代碼規范，這個規范是團隊的寶貴的財富，它是整個團隊從各種坑中爬起來後積累的經驗教訓。什麼是規范，它是人們從無數經驗中總結出來的規則，標准。而代碼規范，指導團隊成員如何以最短的時間寫成最高效，可讀性強的代碼。試想，如果成員不遵從規范，你用駝峰命名，他用下劃線，這對程序的可讀，將造成多大的影響。我想，應該沒有一個人願意去閱讀一段，各種變數命名形式都能見得到，private, public 方法隨意排序，甚至常量類都散落在各個角落的代碼吧。
代碼，一個作用是讓機器閱讀，另一個重要的作用是讓人閱讀！！！

2、遵從行業內通用的規范
在團隊的代碼規范未涉及到的，那請按照行業內的規范來編寫代碼。規范的一個好處是，可以明顯減少學習和交流成本。在java中，當我們看到全大寫的變數名時，我們就知道這是常量，而不需要去看注釋，不需要去看代碼邏輯。為什麼這么迅速，因為行業里大家都習慣把常量用大寫命名。但假如你用其他命名方式命名常量，比如team_nums命名常量，不僅不能讓人迅速知道這是個常量，而且可能讓人誤會這是個變數，增加了團隊成員學習和溝通成本，甚至可能誤導他們。就見過一位仁兄，明明用的是工廠模式，偏偏按模版模式的命名方式來命名，問他，他說他知道這是工廠模式，但他覺得，更應該叫模版模式。。。我的天，，你這么任性，以後還能做朋友么?
舉個例子，我們需要根據支付類型，來生產多個支付產品，於是，我們寫了個工廠類，命名為FactoryPay。當其他人看到一個類叫FactoryPay，他們會猜測，這應該是個工廠類，負責生產各種支付產品的工廠，然後按照這個猜測去閱讀代碼，就能比較快速的理解整個類的作用。但是，假如我取名PowerPay，別人還不知道是啥，看了半天，才明白，這是個工廠的作用。這就明顯增加了他人的學習成本和維護代碼的成本。

不管你是新手還是老鳥，務必了解施行行業規范，切勿為了標新立異而違反規范。這么低端的裝逼，就沒必要採用了，要裝也寫個高端的框架來提升逼格唄。

3、變數、方法命名要能表達變數作用
在程序員這個圈子很久了，就發現，程序員這貨，都喜歡這套，「這個介面幹嘛用的，有文檔么」，「自己看代碼去」。很多時候都是一臉黑。
盡管程序員閱讀別人代碼技術都是一流，不管你是有沒有注釋，不管你是怎麼循環嵌套，也不管你是怎麼命名，他們都能耐心的，把代碼分析個所以然來。但，對於程序員這個視時間寶貴如生命，分分鍾都能創造幾百萬價值的群體來說，您行行好，給我們省點時間吧，把變數是幹啥用的，說清楚唄，沒准節省的這幾分鍾，多賺個幾萬，還能請大家出去嗨呢。
每每看到部門的某大神，用一個神一般的變數名「flag」，我就有吐血的沖動，他還這個flag一直雪藏，不用，只是傳遞到第n個方法才使用，頓時心力交瘁，我的天，這個flag都是是幹嘛用的啊，後來才明白，是isPay的意思，用來標識用戶是否支付成功了。當時一口老血吐屏幕上，心裡狂吐槽，老兄，你命名個isPay會死么，我的腦細胞這么不值錢么。到後來看到，去魔法數字，用int NUM_7 = 7,而不是MAX_MEMBERS來表示最大成員、用x y z來命名變數名，各種只有作者，或者作者後來都忘了的獨特命名方式，都見怪不怪了。更有甚者，一個變數命名為passed，作用居然是「未通過」的意思，當時就石化了，作者還真是用心良苦，這都要考我細心不細心。
一個好的變數名，能幫助閱讀者了解變數的作用，也輔助了對整段代碼的理解。

4、不要show英語，鄉下的孩子傷不起唉
LZ所在的團隊，英語一直都是團隊的硬傷，但總是能看到，某位仁兄，加上大把大把的英文注釋，有些變數名也取些高大上的復雜的英語單詞。敢問，你這么高的逼格，以後我們怎麼和你玩啊。(那位仁兄其實就是LZ，年輕時唉，罪過罪過)
代碼是用來溝通的，傳遞作者意圖的，都看不懂，怎麼溝通交流。建議英語好的童鞋，英語能力可以放到閱讀英文書籍中展示，在代碼中，如果團隊英語能力很弱，避免使用英文，變數命名也盡量按照團隊英語水平來命名

5、添加必要的注釋
正如上面LZ說的，經常遭遇「你仔細看看代碼，就知道幹嘛用的」這樣的神回復。盡管閱讀代碼是每個程序員的強項，但必要的注釋，比如邏輯比較復雜的地方，添加必要的注釋，對提升團隊成員閱讀熟悉代碼的效率是有很大幫助的。試想，一個類，幾百行，沒有一行注釋，對於閱讀者來說，閱讀它將是一個多麼恐怖的事。

6、注釋保持簡潔，避免沒有必要的注釋
即看過一行注釋都沒有的代碼，也看過注釋比代碼還要多的程序。一個是讓人生不如死，一個是讓人痛不欲生。(唉，有時不僅感嘆，在程序員界混，真的是難)。
LZ就經常看過，一大段注釋，啰嗦了半天，要不就是沒表達清楚重點，要不就是只為說明它是個循環的作用！！！譬如i++這樣的代碼，有必要加個「每個計數增加1」這樣的注釋么，這完全是把讀者定位為非程序員啊，或者就是嚴重鄙視讀者的編程水平。
注釋是幫助閱讀的人更好的理解程序的邏輯，只是輔助，如果不重視通過命名等方式來傳遞代碼的作用，而是依賴於注釋，這就是本末倒置了。而且，冗長啰嗦的注釋，這到底是幫助人理解，還是阻礙人理解啊，是讀程序還是讀小說啊。

7、擁有自己的編碼規范
規范是為了讓團隊更快的理解、熟悉代碼的，同理，擁有自己的一套規范，就能幫助其他人更快的理解我們所寫的功能，減少學習和溝通成本。

8、代碼清晰簡潔的表達出作者的意思
在我們每次寫完一段代碼時，一定要問問自己，代碼是否表達清楚了我的意思，是否需要添加些注釋，名字取得是否恰當了，別人在閱讀時是否吃力。。每每看到別人一團糟的費解的代碼，就時刻提醒自己，一定要把代碼寫好咯，我也確實是這么做的，一遍又一編的檢查，看變數名、方法名是否表明了它的用途，是否有些不必要的、只是為了提升逼格的代碼，別人是否能在短時間內看懂。所有的這些，只是為了寫出一段更優美的代碼。

9、堅持並捍衛上面的准則
經常能聽到，有些公司是代碼行數來定義績效的，但作為一個有操守，並秉承基本自我修養的程序員，我們絕不能為了各種誘惑或者脅迫，甚至是自己的惰性、個性，而放棄寫出簡潔清晰，可讀的代碼。

以上的幾點，並不是嚴格的意見或者建議，只是提醒廣大程序員同胞們，在痴心與高端的技術時，千萬不要忘了，代碼不僅機器要閱讀，人也需要閱讀。就算你寫出再復雜的代碼，但它讓人完全無法閱讀，這有什麼用呢。這就如同，你很牛逼很牛逼，但別人聽不懂你說的話，還不是沒用。如果你真的寫出了可讀性強的代碼，但你也不應該鳴鳴得意，我覺得，寫出一段優美，健壯，可讀性高的代碼，是一個程序員最基本的自我修養。

Ⅸ 程序員應該如何保護自己

Tips：「小鳥雲」是深圳前海小鳥雲計算有限公司旗下雲計算品牌，國內領先的企業級雲計算服務商。團隊擁有多年行業經驗，專注雲計算技術研發，面向廣大開發者、政企用戶、金融機構等，提供基於智能雲伺服器的全方位雲計算解決方案，為用戶提供可信賴的企業級公有雲服務。

中興事件讓我很為當事人惋惜，最近兩年程序員群體被大眾注意到，前有 WePhone 開發者被惡毒女詐騙自殺，後有中興70後程序員被內部宮斗想不開，程序員的弱勢在於常年跟機器打交道，以為什麼都很機器一樣講道理，低估了人性的復雜與醜陋，加上工作的原因，習慣了遇事自己獨立解決，導致遇到事情也不會妥善處理，更不會輕易請人幫忙，往往容易釀成悲劇。

其實這個世界是美好的，我們一生中接觸的人，遇到的事情99%都是好的，然而恰恰那1%的壞人壞事被你遇到，如果你沒有妥善處理，也許會對你的人生造成毀滅性的打擊。所以，今天我想給我的知識星球球友們總結幾點經驗，希望你們在遇到那1%的時候，可以輕松應對，想著對我的讀者也很有用，姑且也更新在公眾號上。

1.技術不是全部

這個觀點，我曾不止一次普及過，眼裡只有技術的程序員，跟讀書時候的書獃子沒什麼區別。程序員們很多都認為只要技術夠牛，我就可以憑借技術掙更多的錢，然後就可以過的更好，所以容易往往忽略了其他方面的發展，溝通交流、為人處事都是很重要的，程序員的弱勢在於常年跟機器打交道，以為什麼都很機器一樣講道理，低估了人性的復雜與醜陋，沒有一點防範心理，這些都是很危險的，總之一句話，程序員們大多智商較高，但是情商較缺乏，但是人這一生，情商絕對比智商要更有用的多。

2.培養第二技能

都說程序員是青春飯，被認為中年危機最嚴重的一個群體，在很多人看來不理解，說人到中年，有車有房，收入也較高，怎麼會有那麼大的危機呢？然而殊不知，人到中年，收入雖然高了，但是房貸、車貸壓力不小，同時還背負著家庭的責任，到處都是花錢的地方，而且經濟大環境不好，很擔心公司發展遇到困難，自己受到各種影響，跳槽的話雖然不愁找工作，但是這個年紀薪資崗位低了不想遷就，高的話除非管理崗位，否則企業不如找個年輕點的、工資低點的來代替了，種種原因導致中年危機感很重。

我之前就說過，一定要培養第二技能，永遠不要把所有賭注都押寶在工作上，年輕的時候趁早培養第二技能，寫作、演講、英語、咨詢等等都屬於第二技能，根據你的個人興趣愛好去選擇，第二技能會是你的後路，當你到了中年，也許第二技能早就發展的如火如荼，甚至超越你的本職工作，擁有第二技能的人從不會擔心危機的到來，奉勸所有程序員們，一定要重視第二技能的培養。

3.永遠不要在非正常狀態下做任何決定

這次事件很多人都想不通，當事人高學歷，經驗豐富，被裁了大不了換份工作就是了，何必想不開呢？簡直太懦弱了。其實我們不知道當時是在一個什麼環境下，我們處在事外當然看得清，但是很多決定其實都是一念之差，就是那麼一瞬間沒想通，導致沖動做出錯誤的選擇，我們能總結出的經驗教訓就是：永遠不要在非正常狀態下做任何決定。

什麼叫非正常狀態？醉酒、憤怒、極度傷心甚至興奮、異常喜悅等狀態都屬於非正常狀態，這種情況做出的決定通常都是不客觀甚至錯誤的，另外，做決定的時候多想想身邊的家人，考慮的因素全面點，會更能避免一些想不開發生。

4.職場中不要講感情

我以前也說過，成熟的職場人士是不會講感情的，不要把公司當做家一樣，更不能把公司同事當做家人看待，那些只給你打感情牌，沒有任何實質性的表示的公司或者老闆，你得小心了。

當然，可以對公司以及同事有感情，但是不可以感情用事，在公司的任何決定，如果你都可以拋開感情，其實都很好處理，但是很多同學想不開，在遇到類似事情的時候，往往會有非常不理智的處理方式。

僅以此事，給我所有的讀者普及下，希望不會有下一個悲劇發生，更希望我的讀者們都可以做一個不羈的碼農！