在不同時期，有不同的判別標準。

在70—90年代，由於計算機硬體效能不高，特別是中央處理器，記憶體，顯示卡，硬碟、網路等裝置的頻率、容量、頻寬限制，導致了要計算機高效地工作，必須要求程式人員、軟體工作者要有過硬的技術，精簡的程式碼，高效的計算邏輯去解決問題。一個良好的演算法，往往會大大提高計算機的運算工作效率。該時期，往往編碼質量的高低優劣是以效率為導向的。

2000年之後，計算機硬體軟體都發生了巨大變化，作業系統的程序排程能力更加合理化，處理器頻率、記憶體容量等裝置遵從著名的摩爾定律飛速發展，該時期，考核高階程式設計師編碼質量側重於對程式碼的理解、維護、辨識、最佳化、可擴充套件性等方向。

現在的程式設計是一個系統的過程，程式設計師程式碼質量的高低往往也與他所處的團隊有較大的關係，也就是說頂層的設計與程式碼質量有直接的關係。所以說優秀的團隊往往都是優秀的程式碼，但是普通的團隊往往很難寫出優秀的程式碼。

程式碼的編寫大致上經歷幾個步驟，第一個步驟是頂層設計（架構師）。頂層設計包括軟體架構設計、技術方案等內容，落實到程式碼上往往就是大量介面的定義。好的設計需要考慮三方面因素，分別是結構性（模組化）、完整性、擴充套件性，當然還需要考慮可移植性，通常結構性好的程式碼移植性也會比較不錯。

第二步是核心程式碼的實現（研發級程式設計師）。有的團隊也把這部分稱作為“容器”開發，簡單的說就是功能性平臺開發，目的是實現平臺級API。這部分程式碼的開發是整個軟體開發的核心部分，承擔這部分開發任務的程式設計師往往就是我們所說的研發級程式設計師。研發級程式設計師程式碼質量的衡量標準主要在演算法設計與實現上，效能指標是考核的重要因素，另外還要考慮穩定性和完整性等核心因素。

第三步是功能編寫（應用級程式設計師）。功能編寫簡單的說就是完成具體的業務邏輯實現，需要呼叫平臺提供的API完成具體的功能。這部分程式設計師佔據了程式設計師群體的大部分比例，也就是通常所說的應用級程式設計師。應用級程式設計師的程式碼質量主要從程式碼編寫結構上來看，比如是否有標準的打包、命名、註釋，以及程式碼整體結構是否清晰，邏輯結構是否清晰等方面。

往往程式設計師程式碼的質量會隨著程式設計經驗的提高而不斷得到提高。

軟體蠶食一切，未來屬於程式設計師。所以人人都想當程式設計師。但是並不是每個人都能當好程式設計師。在你做出決定前還是先看看自己能不能當好程式設計師吧。

優秀程式設計師的幾個表現：

1、先進行實驗是他們的本能反應

編譯器和執行環境通常能比人更快地解釋一個問題。一個優秀的程式猿在拿著問題去向別人尋求幫助之前，會自己試試看並判斷方法是否有用，而不是直接找一個高階程式設計師問“我這麼做有用嗎？”。

2、對待程式碼和設計不要情緒化

程式碼就像紙巾：它有用你就用，沒用了就扔掉。幾乎我們所有人都認為程式碼複用（ code-reuse ）很重要，儘管確實如此，但是這也不意味著要像養孩子那樣去對待程式碼。程式碼沒有感覺也不會在乎，它們會像法蘭克斯坦（ Frankenstein ）怪物那樣攻擊你。程式碼只是一堆位元組，是一種責任（ liability ）。

3、對程式設計有激情

很多程式設計師幹這一行只是為了掙錢，如果有更好的職業，他們會毫不猶豫的辭掉程式設計師的工作。而優秀的程式設計師熱愛程式設計，喜歡鑽研程式碼中的問題，他們感到能指揮電腦來幫助人們和自己解決現實生活中的問題是一種神奇的能力。當遇到問題無法解決時，他們會茶不思、飯不想，無法入睡。

4、君子善假於物

優秀的程式設計師知道如何能更高效的完成任務，如何更能有效的解決問題。當遇到問題時，不鑽牛角尖，善於利用外部工具解決自己的問題，特別是能熟練應用搜索引擎。初級的程式設計師只會使用百度和百度知道搜尋問題，而高階的程式設計師/優秀程式設計師使用谷歌和Stack Overflow或者MSDN forums這類網站尋找更優秀的答案。

5、不僅關心技術方面的知識，同時關注非技術方面的知識

不稱職的程式設計師喜歡臨時抱佛腳，只有在需要的時候才去學習。而優秀的程式設計師會去主動學習各種相關知識，對各種知識來源都有一種開放的心態，而不會象有的人那樣固步自封。 而且，並不只侷限在跟職業相關的技術類知識，同時他也會學習任何感到有趣的知識，比如溝通技巧等。

6、有好的工作習慣

養成程式設計師的工作習慣或工作態度及解決問題的辦法.

比如,我在公司接手一個新的專案,我首先會在電腦上建一個這個專案的資料夾,然後分門別類的把涉及這個專案的所有資料,都放在一這個資料夾裡.

然後在後續的開發,及修改過程中,我會把自己的分析,及解決辦法,業務的理解,客戶的需求等等統統記錄下來.這樣,就算我讓其他同事負責這個專案了,他也會有資料看,或者我辭職了,接手的程式設計師也會很快上手的.假如我去一個新公司,接手一個專案的維護工作,如果沒資料,我很難上手的話,我會很快再辭職的.(這對公司來說也是一個很大的損失)

7、就是善於總結

善於思考技術點.假如思考這麼多年的話,關於底層的,很多技術的來龍去脈都會很清楚.也會舉一反三進行創新.

糟糕程式設計師的幾個表現：

（1）無法對程式碼進行推理

對程式碼進行推理意味著能跟隨程式碼的執行路徑（“在腦子裡執行程式”），同時清楚地知道程式碼執行的目標。

（2）補救措施

程式猿可以透過實踐來克服這個缺點，如果 IDE 自帶的偵錯程式能單步除錯，就把它作為助手使用。比如說在 Visual Studio 裡，這就意味著要在問題區域的起始處打上斷點，然後按下‘ F11 ’單步除錯，檢視變數的值（變化前後都要檢視），直到你明白了程式碼正在做什麼。如果你的目標環境不具備這種特性，那就找一個擁有這種特性的環境去實踐。

這麼做的目的是，讓你做到不再需要偵錯程式就能在腦子裡跟隨程式碼的流程，而且有足夠的耐心去思考程式碼正在對整個程式的狀態做什麼。這麼做的好處就是能夠識別出冗餘且無用的程式碼，而且不需要從頭執行整個路徑就能在當前程式碼中找出 bug。

（3）難以理解語言的程式設計模型

面向物件程式設計（ Object Oriented Programming ）就是一種語言模型，正如函數語言程式設計（ Functional programming ）或宣告式程式設計（ Declarative programming ）一樣。它們每一個都和過程式或指令式程式設計有著顯著不同，就像程序式程式設計明顯不同於彙編或基於 GOTO 的程式設計。此外，雖然有很多語言都跟隨同一個主流程式設計模型（如面向物件的程式設計），但它們都只介紹自己的改進，例如遞推式構造列表（ list comprehensions ）、泛型（ generics ）、鴨式分類（ duck-typing ）等等。

（4）不使用版本控制

版本控制確實是一個非常有用的技術。它不僅可以跟蹤解決方案中的每個檔案，儲存整個歷史，還可以區分不同的版本到分支，知道什麼時間是誰改變了什麼（並且如果提交的資訊足夠詳細，還可以知道原因）。

（5）使用糟糕的變數名

知道將variable1和variable2作為變數名有什麼問題嗎？變數應該根據它們做什麼或者它們包含什麼來命名。對了，Visual Studio有一些強大的重構工具，可以相對容易的讓它們回到井然有序的狀態。

（6）重複程式碼

非常推崇《Pragmatic Programmer》（《程式設計師修煉之道》）這本書，上面推薦的第一個秘訣就是不要重複程式碼。上面要求無論如何都不得重複程式碼，在我看來過於極端了。如果相同的程式碼需要重複4次，那麼可以為這段程式碼建立一個函式，這將極大地改善你的程式碼。

怎樣成為一名架構師：

Java行業在當下人才是供不應求，但是作為Java程式設計師的你也得居安思危，你要知道你身處的是一個高速變化的行業，稍不留意你的位置還是存在被取代的風險，那麼對於一個Java程式設計師來說，要如何避免被淘汰呢?

1. 時刻關注Java行業動態

每一個Java程式設計師該做的，除了日常的工作外，要花點時間在Java行業動態上，不要輕易相信那些對Java不好的言論，比如“Java將死”，從而產生極大的焦慮，你要做的就是根據Java行業動態冷靜分析，實時對自己的發展方向做出調整。

2. 不斷學習新出Java技術

很多Java程式設計師，一直固守不前就是因為覺得自己當下的Java技術應付當下的工作綽綽有餘了，而不重視新的Java技術的學習。你要知道你這就是安於現狀，那麼你就真的只是一直會是低階Java程式設計師，因為你的Java技術不更上時代的發展，即使你在Java行業從事再多年，你依舊勝任不了高階Java工程師的工作，自然面臨淘汰。

3. 學習和總結的能力

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

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

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