從網上面看了諸多資料，蒐集到這個程式設計師「八榮八恥」。經過個人的思考與概括，已基本成型。具體如下：
以動手實踐為榮，以分數排名為恥。
以演算法分析為榮，以胡編亂寫為恥。
以列印日誌為榮，以出錯不報為恥。
以多型應用為榮，以分支判斷為恥。
以**重用為榮，以複製貼上為恥。
以專業英語為榮，以四六級證為恥。
以定義常量為榮，以魔鬼數字為恥。
以總結思考為榮，以不求甚解為恥。
先別忙反對或贊成，我們來順應潮流細細分析一下！
1.以動手實踐為榮，以分數排名為恥。這個意思很明了，就是說要淡化理論考試的排名次，抓學分等一系列無現實意義的攀比活動！當然也不是說理論不重要，只是他向我們傳達了這樣乙個資訊——理論要在實踐中得到昇華，實踐要在理論中得到應用！這個過程是相輔相成的，只有多動手，多改錯，多總結，才能實現這個「以動手實踐為榮」目標。試想，不經過這個過程，不勞而獲就成為程式設計高手，那麼事情如此發生，豈不傷天害理？不過，老天總是理智的，努力的人盡可放心，現今社會早已拒絕白吃乾飯的人！
2.以演算法分析為榮，以胡編亂寫為恥。記得有個招聘人員在面試程式設計師的時候說過這樣的話，如果某人膽敢在簡歷上寫明「熟悉資料結構」，那麼我也不為難他，就讓他寫乙個二叉樹三種遍歷過程的演算法，其他程式語言技能無需考核！個人認為，這個考官有水平檔次！資料結構與演算法，編譯原理，離散數學這三個學科是軟體界最難掌握的了，熟悉它們的其中乙個遠遠比學習程式語言來得困難，而這類人才也是程式設計師中的「戰鬥機」！有些人在做程式時，態度也很端正，兢兢業業，吃苦耐勞，可是效果極其有限！殊不知胡編亂寫是效率低下的乙個表現，理智的人應該想想演算法。即使不能想出多麼優秀的演算法，但思考的過程經常會使人融會貫通，乙個小小的思維亮點就有很可能把你與一般人區別開來。想想看，用jsp，asp，vb等做出「***管理系統」的人一抓一大把，挑都挑得眼花繚亂，如何找到適合企業的人才呢，用「演算法分析」這個條件來選拔，應該不為過吧？想精通並不容易，但是如果有意識向這方面深入，可以斷定，你的水平高過一般人不成問題！
3.以列印日誌為榮，以出錯不報為恥。從我的經歷來看，以前經常犯這種錯誤！這種錯誤不是那種極為嚴重的錯誤，而是一些隱蔽的，難以察覺的錯誤！比如說，做乙個小系統，程式已經啟動，可以正常執行，但是控制台會報一些錯誤，而你發現這些錯誤也並沒有給系統的使用帶來什麼不良影響，就把它給忽略掉了。然而，這就是不少系統在後期執行時的造成效能不穩定的諸多因素之一。因為前期未發現，時間長，慢慢地曝露出來了，由於此時系統已經成型，這時候修補起來估計要花費代價的！這麼說來不如未雨綢繆嘍，何時發現，何時列印錯誤日誌，盡早的修改，完善，你說是吧？
4.以多型應用為榮，以分支判斷為恥。多型的好處不言而喻。它提公升了**的可擴充套件性，我們可以在少量修改甚至不修改原有**的基礎上，輕鬆加入新的功能，使**更加健壯，易於維護。在設計模式中對於多型的應用比比皆是，物件導向設計（ood）中有乙個最根本的原則叫做「開放–關閉」原則（open-closed principle ocp），意思是指對新增開放，對修改關閉。比如說，已經有了乙個animal(動物)類,現在需要新增bird(鳥)，那麼最好定義乙個bird類，讓他繼承animal,然後通過new 進行例項化即可。我們所做的就是新增新的類，而對原來的結構沒有做任何的修改，這樣**的可擴充套件性就非常好了！因為我們遵循了「開放-關閉」原則 —— 新增而不是修改。前面這個例子中還有乙個地方需要說明，animal 這個類，實際上應該定義為乙個抽象類，裡面的有些方法，事實上不需要實現，也沒法實現。咱們共同**啊，animal(動物) 的叫聲如何，你能想象出 animal(動物) 是怎麼叫的嗎,聲調多高？顯然，這個方法應該定義為乙個抽象方法，留給它的子類去實現，它自己不需要實現，那麼一旦這個類中有乙個方法抽象的，那麼這個類就應該定義為抽象類。如果不採用多型性，而是不停地進行if_else,switch-case重複操作，那麼帶來的麻煩是可想而知的，萬一少判斷乙個怎麼辦？萬一忘寫了break怎麼辦？這些還都是小事，錯了可以改。重要的是他沒有統一的「標準」，程式設計師之間，你用你的，他用他的，從頭判斷到尾，結果造成嚴重程式「不相容」、「不共存」，程式**紊亂不齊，這個是不是會影響團隊開發的效率呢？
5.以**重用為榮，以複製貼上為恥。程式設計師的基礎條件之一**重用！這個不多講，大家都明白！
6.以專業英語為榮，以六級證書為恥。這個估計要引發爭論了。有人反問，四六級都沒過關，談何專業英語呢?我想解釋的是，四六級固然能反映乙個人英語的水平，但也不是說四六級過了關就能夠在計算機專業英語領域為所欲為的。我的乙個老同學，他過了四級，但是六級沒考過，剛開始我也就以為他的水平一般而已，後來才發現他的詞彙量大得驚人，很多專業深邃的詞彙他都知道，看懂一篇正常的計算機英語科普文章還是很從容的。六級落榜是因為他不太會考試，聽力不好，心態不穩而已，大可不必懷疑自己的書面翻譯能力。還有不少同學都過了六級，但是我發現他的詞彙量也不過如此，正常程式設計用到的很多詞彙，都未必能正確的把握！這就從乙個側面說明，四六級考試只是形式而已，能過當然很好，不能過也不要強求自己。畢竟，我們不是考試大師，我們需要的是專業英語，而這些泛泛英語只是萬里長城的一塊磚。既定的目標是能夠應付多數的計算機英語書籍、科普文章就行！
與其花了大量時間考形式六級，我感覺倒不如買一本專業英語詞典和一本普通英漢詞典，經常遇到陌生的單詞就拿過來掃瞄幾眼，時間長了這就積累成為專業財富了，這就是前輩所說的「不積跬步，無以至千里；不積細流，無以成江海」。
7.以定義常量為榮，以魔鬼數字為恥。時常看見很多同學(說來慚愧，自己也包括在內)在自己的程式中無序地使用大量資料，這些魔鬼數字經常給修改、擴充套件帶來極大不便。數量少還能應付，那要是大量的資料怎麼辦呢？乙個個修改嗎？你有耐心嗎？即使有耐心，你能保證細心嗎？不好說吧！所以，編寫程式時，如果需要，那麼要盡量定義常量，這就在修改，擴充套件等方面帶來很大的便利！當然，我也在不斷拓展此方面的技能！
8.以總結思考為榮，以不求甚解為恥。這一點大家都能看出他的重要性！勤於總結，善於分析，這是對程式設計師的要求之一。由於軟體技術發展日新月異，誰也不可能在極短的時間內學會大量技術，這就要求我們要總結以往的技術經驗，拿過來可以為新的知識做鋪墊，做導向，達到以不變應萬變！而不是像有些程式設計師那樣會了就扔一邊去，下次做專案還得拿過來copy & paste & update & debug，嚴重拖累專案進度。這種治學態度注定乙個如此的程式設計師很難有所作為的，現實情況可以佐證我的觀點。
以上就是我對這個「程式設計師八榮八恥」的一些看法。固然每個人不可能做到所有的「榮」，但是我們可以摒棄大部分的「恥」，這樣「榮」多「恥」少，日積月累，汗水凝結成智慧型，技術昇華為經驗，你還用擔心你的發展會滯後於平均水平嗎？
一家之言，難免片面，歡迎批評指正，以求共同交流，取其精華！
專案管理之我見 程式設計師程式開發步驟
專案管理之我見 程式設計師程式開發步驟 專案遇到的問題 程式開發是專案的核心。因此缺少管理的程式開發，就不會作出成功的軟體專案。程式開發過程中，專案的程式設計師是根據已有的模組設計文件，理清思路，然後編寫程式。但是由於程式設計師編寫程式步驟比較隨心，導致可能出現對需求理解不清楚，又或者由於本身的水平...
頂尖程式設計師與普通程式設計師的區別
普通程式設計師認為自己與頂尖程式設計師的區別,主要是頂尖程式設計師任何功能都能編碼實現,編碼速度快,無 bug。正如一慣的那樣，普通程式設計師之所以普通，正是因為他們勉強能看到 或者根本看不到 事物的表象而看不到本質。頂尖程式設計師專業度 1 精通 除錯 debug 很多人在寫 的過程中，經常會有的...
程式設計師與程式設計師之間碰撞的火花
程式設計師與程式設計師的搭配指數 如果程式設計師找了個程式設計師女朋友，他們之間可能是這樣的 聊天時，你是我物件麼？男程式設計師詫異，心疼的把她緊緊摟在懷裡，說 沒事吧？我當然是你物件。他女友嫣然一笑 那好，過來，接下來我要將你例項化成一工具，再呼叫一下in out方法，沒意見吧？也可能是這樣的 在...