拿什麼來衡量程序員的生產力

㈠ 如何辨別一個程序員水平的高低

1.自己介紹項目，看對項目的提煉總結能力（也是抽象能力）；
2.自己印象最深的bug，可以知道大概技術深度；
3.設計模式提問，看有沒有學習方法；
4.語法基礎問題，多線，分布，安全等問題，看知識面廣度；
5.智力問題，看反應能力，分析問題思路等
上述五步基本可知是否是一個好程序猿

計科專業從事軟體開發十幾年了，主要在瀏覽器內核領域研究的比較多，最近在研究伺服器後台方向，辨別程序員水平高低主要看做出了什麼產品，如同現在的程序員主要是項目經驗，簡歷上寫的一堆項目經驗都是面試的時候主要提及的問題。經常在面試中會問兩個關鍵點：一個是做過什麼項目；一個是在項目組中承擔什麼職務，畢竟參與過和做的多少程度是不一樣的，這些都是可以通過一些具體的細節檢測出來，問題越具體越是容易看出水準，具體的東西不是能夠編造出來的。

有很多技術公司直接不通過筆試，僅僅通過簡單的面試就確定工資水準了，最簡單的測試程序員水平的直接用筆試的方式，筆試可以把一些細節量化，盡量的細節化也是能測試出程序員基本功的，但這種基本用來測試初級程序員的，很多高級的程序員看到有筆試直接就抬腿走人了，因為有些程序員在一個方向做的時間太長了，很多基本功都忘得差不多了，所以筆試可能不過關，現實中很多程序員筆試不過關，面試還可以，也一樣可以做項目說的就是這類人，起碼這算是非常優秀的程序員。

有很多公司採用谷歌的方式，直接採用上機寫代碼的方式檢驗程序員水平，這種方式比較直接，但在現實中可能消耗的時間以及面試官的精力，目前只有極少數的公司用這種方式，國外的公司用這種方式比較多，這種看基本功非常有效。通過代碼可以看到編碼習慣以及演算法的設計上，都能直接看的出來。

普通的程序員直接看項目的經驗，高級的直接看做過的產品，特別是產品主要設計人員，這就是程序員內心的自豪感，畢竟作為一個程序員起碼要有自己設計開發的產品，也算是不白做一個程序員，在程序員的職業經歷中如果能經歷過一個產品從開始設計的初稿到最後推向市場，如果是完整的經歷，將是一種巨大的財富，只要經歷過一次都會對產品設計有一個比較層次的認識，這種能力需要靠直接的面試語言表達來展示出來，談下對產品的認識以及產品穩定性性能等方面的總結，能到這個層面起碼是高級軟體工程師的級別。

當然有些程序員內在的東西不是靠語言或者寫代碼看出來的，因為一個優秀的程序員不僅僅是代碼能力以及框架能力，還有幾個非常重要的能力

程序員的能力表面是可以直接展示出來，但很多內在需要是需要時間的磨合才能了解，人就才能見人心，而且很多優秀的程序員是培養出來的，能夠長時間在一起的隊友都是時間長了磨練出來的。

希望能夠幫到你。

自認為不是一個好的面試官，因為我認為在這么短的時間內，准確地衡量出來程序員水平的高低是有比較大的難度的，並且我有多次看走眼的時候，面試的時候覺得能力還不錯，但是入職工作了一段時間之後，編程能力不忍直視。

工作之後接觸一段時間，我會從這么幾個方面觀察他們，以判斷技術能力的高低和發展潛力。

能不能把開發任務按時按質量地完成，當然是最主要的衡量標准了:

在開發過程中，難免會遇到沒有見過的問題，有些程序員遇到問題無從下手，而優秀的程序員，自有一套解決問題的方法。

有人會認為，程序員的主要工作就是敲代碼，上班大部分時候都是在敲代碼，其實並不是這樣：

好的程序員，相同的問題不會犯第二次，差的程序員，總會在一個問題上栽跟頭：

不請自來，一介碼農路過，留下些看法。

程序員主要是有四種綜合能力，也就是debug 能力、 performance分析、 保護性編程和 投入產出比。

在這里不能說一棒子打死，至少對於很多人來說，能獨立完成是沒什麼問題的，有的是因為對業務熟悉，有的是真的基礎扎實。但怎麼說呢，程序員和瀏覽器打交道是最多的，現在這個互聯網時代，遇到的大部分問題網路都是可以解決的，也就是普通程序員 + 網路 = 超級程序員。 但很多人也沒明白具體的原理，甚至都是這個項目抄抄那個項目抄抄的，久而久之雖然解決了平時的業務，但進步的空間卻很少，甚至止步不前，寫出來的代碼也可能存在很多坑，所以，僅僅能獨立完成任務的話，離高手還有比較遠的一段距離。

也就是結合我們一開始列舉的那四個能力進行判斷。不同級別的程序員，在那綜合能力面前，強弱也是不同的。例如在奔潰的或者其他性能調優問題上，即使是面對大量復雜的代碼，在信息不全的時候也會一步步的分析，抽絲剝繭縮小范圍，最終定位根本原因

，並且最終給出一個好的方案。

當然還有看他摘了帽子是否禿頂這樣的笑話，就再不贅述了。

第一階段（黃金）:會用編程語言實現需求，比如現在的業務系統，都會找一些會搬代碼的人來拼工作量，也就是能自己獨立基於搭好的框架實現crud常規操作。

第二階段（鉑金）:除了crud，還會有一些自己踩過坑的經驗，知道如何處理一些常見問題，或者可以基於搜索引擎快速解決一些異常情況。

第三階段（鑽石）:能解決一些疑難雜症和會通過debug部分源碼類庫查看到這些疑難雜症是如何引發的，並通過編碼解決這些問題，還能進行一些局部的性能優化，類似某個系統介面緩慢可以單獨去優化。

第四階段（星耀）:會基於整個系統進行設計和規劃，根據業務特性選擇合適的框架，從源頭控制開發遇到問題的頻率，可以自主的搭建框架並完善機制，了解各個組件工作原理。

第五階段（王者）:小說裡面總是說練武功的永遠比不過創造武功的，同樣的道理，用框架的也往往不如寫框架的，所以寫框架的這類人單獨分層。

第六階段（榮耀）:其實這個階段不應該列入進來，因為這類人往往不編碼的，只是給出思想；像Hadoop這種框架就是基於人家發表的一些論文（bigdata)進行編碼實現的，這類人注重的是思想和演算法，區塊鏈，大數據，雲計算等等概念的創造和理論的支撐是這類人提出來的，這些人才是真正影響行業走向的人。

程序員的水平高低，不是靠語言或外在表現就能看出來的，不是看他會多少技術、參加過多少項目、寫了多少博客，而是看他在實際業務場景中解決問題的能力，尤其是面對一些特別復雜的問題，或在高強度、高壓工作狀態下解決問題的能力與態度。

技術可以通過學習掌握，但是解決問題、定位問題的能力卻不是一蹴而就。大家可能會說，「解決問題的能力」這個太寬泛了吧，可以更具象化嗎，有具體的測量方法嗎？簡單整理了以下幾點供參考。

會寫出滿足需求的代碼，早就不是評判程序員水平的標准了。代碼編寫既要滿足業務需求，同時還要考慮後續的軟體維護，說得通俗些，既要自己爽，也要別人爽。一個優秀的程序員，會致力於寫出更簡單、更效率、可讀性強、擴展性強的程序代碼。

程序員在日常工作中，需要理解各式各樣的業務需求，所以這就需要程序員具備一定的邏輯思維能力。可以說，邏輯思維是程序員的靈魂，因為每一行代碼都是程序員邏輯的體現。

項目著急上線，發布時出現問題？

業務高峰時段，系統宕機了？

業務催、運營催、用戶催、老闆催！

各種形態的bug，各種著急的心情，背後無數支眼睛盯得內心慌慌......

這些都是一位合格程序員所需要面對的日常。不同的程序員，在解決問題的方法、效率、質量等方面，都各有千秋。一個經驗豐富的程序員，能夠扛住各方壓力，在復雜條件下找到核心問題，通過抽絲剝繭的分析來找到產生問題的原因，並快速進行應對處理，事後及時復盤總結，減少同類問題出現的概率。

隨之互聯網的發展，越來越多的人湧入程序員這個賽道，競爭日益激烈，加之新技術層出不窮，更新迭代快，程序員所使用的語言、框架、模式都會發生天翻地覆的變化。如果不主動學習，你很快就會被落伍淘汰。

這種其實在面試過程中能體現出來，溝通主要是技術溝通，以及和客戶之間的溝通，所有技術都不是閉門造車就能搞定的，溝通能讓事情推進起來更加順暢，包括和產品經理之間的流暢的溝通也顯得非常重要。程序員的能力表面是可以直接展示出來，但很多內在需要是需要時間的磨合才能了解，人就才能見人心，而且很多優秀的程序員是培養出來的，能夠長時間在一起的隊友都是時間長了磨練出來的。

線上出bug了，第一時間響應、處理；

團隊項目進度緊張、人手緊缺，主動補位；

又或者，在項目推進過程中如果只是關心自己模塊內容，對於整個項目置之不理，只守著自己的一畝三分地。

隨著時間軸的拉長，你會發現，有此f技術能力不是最好的，甚至不如你的小夥伴，最後做到了技術主管或經理、甚至更高職位，這裡面除了技術實力，還有一個叫「責任心」的東西。

結束語

判斷一個程序員的水平高低，核心是其解決問題的能力，而解決問題的能力養成，需要扎實的底層基礎來支撐，要綜合其代碼質量、項目經驗、框架能力、邏輯思維等等多方面，不能單看某一方面。

而對於1-6歲的程序員來說，想要成為一個高級程序員，變得越來越優秀，唯有持之以恆去學習、積累、實踐、修煉。

----end----

一：50歲的時候，頭發還是黑色的濃密的。

二：賺到的錢能保證家人快樂的生活。

三：當公司不要你的時候能成功轉型。

其他的例如編程經驗、寫代碼厲害啊什麼的根本不值一提。

這就是程序員的面試嘛 :-)

（1）是否能熟練使用所用編程語言的主要功能；

（2）是否知道用合適的數據結構解決問題；

（3）是否知道基本的演算法，並且用這些演算法解決問題；

（4）只看少量代碼的話，從變數命名和程序結構一般能夠判斷是否是新手；

（5）給出具體問題，能夠用程序解決，能考慮到所有的邊界條件；

（6）考慮程序的可擴展性，可維護性；

再往高一點走，就需要

（7）面對模糊的問題能夠分析並且找到細節和具體的需求；

（8）知道利用已有的庫，架構和工具等來解決新的問題，而不是什麼都自己實現；

（9）能發現並改進已有程序中的瓶頸；

（10）對整個大項目的程序架構有很清晰的了解，知道相互之間的依賴，以及知道為什麼採用這樣就架構；

（11）給一個大的項目，能夠對整個項目的程序架構和組件進行合理的設計，考慮並行性，低延遲，大數據量等各種需求和應對方式。

帶領團隊已多年，項目數十個，對判別程序員水平的高低，我有自己的看法，歡迎大家一起交流。

1.代碼質量。

優質的代碼，首先是經得起考驗。靜態分析工具過一遍，無錯誤，無警告。當然警告部分需要人工重審，因為靜態分析工具不一定完全正確。過了這一關，重要的還須過測試關，少Bug或無Bug的代碼，才是好代碼。優質的代碼帶有技術氣質和藝術氣質。閱讀起來，有一種賞心悅目的快感，即工整美觀，干凈利落，又蘊含著理論常識，運用技巧，精準到位。

2.表達能力。

3.文檔能力。

文檔形式包括但不限於PPT，文字，圖表，音視頻。文檔內容包括但不限於API說明，工具手冊，項目事項，技術論述，陷阱總結，方案展示，指導手冊。文檔要求必須是滿足公司或部門的規范和格式，否則五花八門的，不利於交流和傳承。

以上3點，是我量化判斷程序員水平的標准，僅供參考。相比水平，其實我更看重程序員的態度，執行力，時間觀念，自學力等等，也是很重要的團隊作戰能力，也可以說是程序員水平的考量吧。

謝謝大家。

㈡ 低級程序員和高級程序員的區別

低級程序員認為自己與高級程序員的區別, 主要是高級程序員任何功能都能編碼實現, 編碼速度快, 代碼無 bug. 正如一慣的那樣,
低級程序員之所以低級, 正是因為他們勉強能看到(或者根本看不到)事物的表象而看不到本質. 所以, 低級程序員總結出的一切東西,
你都可以大膽的忽略.

所以, 我們來聽聽高級程序認為自己與低級程序員的區別是什麼. 高級程序員之所以高級, 在於他們認識到代碼 bug 是不可避免的,
有千萬種理由可以導致 bug, 但他們可以在設計和邏輯上保證(追求)滴水不漏, 並用邏輯的百分之百准確性還減少代碼 bug. 沒錯,
嚴謹的邏輯能力是高級程序員區別於低級程序員的最主要原因.

可以舉一個簡單常見例子: 網路購票終端的開發. 當然, 比低級程序員還低級的程序員做不出來. 我們先看看低級程序員是怎麼做:

order = Db::new_order();
ret = Network::place_order(order);
if(ret == TRUE){
order.finish();
}else{
order.cancel();
}

你看到的沒錯, 這段代碼邏輯清晰, 一般 90% 的情況都能正常工作, 有的甚至能達到 99%, 在某些特定的時間段, 這樣的系統 100% 能正常工作(幾乎是完美的系統).

你可能發現了問題: 網路是不可靠的, 網路請求可能發出去了, 也可能沒發出去; 對方可能收到了, 也可能沒收到; 響應可能由對方發出去了, 也可能沒發出去; 你可能收到了響應, 也可能沒收到.

但是, 低級的程序員會這樣解釋: 我用的是 TCP 協議, "TCP 是一種可靠的傳輸協議", 哈! 可笑的照本宣科. 這種低級程序員,
不僅在於他們寫出了邏輯上不完備的系統, 而且還惡劣地引經據典來做錯誤的辯護. 但他們引用的經典是不合時宜的(不能支撐他們的結論).

正確的做法應該是假設上面的每一行代碼都可能中斷執行, 然後進行相應的對策. 正如狹義上的網路協議其實是廣義上的交互協議, 我們可能把 TCP/IP 協議上的許多思想和機制應用到系統間的交互上來.

簡單來講, 可以加上就是重試(超時重傳)和對賬(請求確認). 所以, 邏輯上更准確的代碼應該是這樣:
Process_0{
order = Db::new_order();
}
Process_1{
order = Db::find_new_order();
ret = Network::query_order_result(order);
if(ret == NOT_FOUND){
ret = Network::place_order(order);
if(ret == TRUE){
order.finish();
}else{
order.cancel();
}
}
}

Process_0 和 Process_1 是相互獨立的處理邏輯.

Process_0 即處理用戶交互, 接受訂單.
Process_1 請求服務提供商進行對賬. 進行采購下單(補單), 更新訂單狀態.

上面的代碼邏輯實現了重試(超時重傳), 對賬(請求確認). 但上面的代碼在邏輯上還不是 100% 准確的, 例如, 如果對方系統誤報呢? 但其它的異常情況可以根據實際情況來忽略. 如果你發現這段代碼還有重要的邏輯上缺陷, 歡迎告訴我.

記住, 低級程序員和高級程序員的區別在於邏輯和抽象.

㈢ 憑代碼強生產力嗎

寫代碼是依靠腦力生產結果，而編程效率、編程水平、工作時長、代碼質量、運行效率、生產力......這些復雜的因素決定了最後項目的質量。有的大牛隻用50%的代碼量就解決了初級程序員需要100%的代碼才能解決的問題。所以，用「產出的代碼行數」、「每日上班敲代碼的時間」...這種指標來衡量生產力，是不科學的。

㈣ 如何對程序員績效考核

關於程序員的績效考核問題，相信是很多軟體公司致力追求卻一直無法做到量化的目標。很多考核標准都只是一個框架，但卻無法具體細致下去，從而引發了很多勞資方面的糾紛，到最後都是無果而終，無法堅持下去。但還是有很多人，特別是不懂得技術之人，樂此不疲，希望以此種方法來作為程序員報酬的衡量標准。

最突出的就是「任務量」問題。軟體編程行業的任務，懂點編程的人都知道，這個行業是一個創造性、思維性的行業。一個任務的工作量多與少是沒有一個衡量標準的，原因就是軟體功能的實現結果，根本就沒有一個最好的標准。

有的人就以工作時數來進行衡量。真的可以嗎？舉個例子：相同的任務且相同實力的程序員，有的程序員花了一天就完成。也有的程序員花了兩天完成，還有的花了三天，四天，五天完成的。花一天完成的程序員做了功能上的實現，它是完成的，針對績效考核來說，是滿分的。但是，比他花多得多時間的程序員呢？他們除了花在功能實現上，還花了很多時間在代碼優化以及界面操作設計上。那麼，從績效考核來講，也僅僅是滿分。花一天與花幾天的程序員的工作量真的可以相等嗎？誰都知道不可能的。再打個比方，兩個工作任務，有可能在任務量上它真的就一樣。但是，在任務安排上，一個項目組由於技術力量及時間限制上較為寬裕，在一個月內寬松地完成了，而另一個項目組由於在人力資 源以及時間限制上，加班加點，用了十天就完成。以此相比，是哪個項目組的任務量更大一點呢？

所以，績效考核的框架是死的，而程序員的任務是活的，用一個死的框架套住一個活的思想，程序員只為績效的要求而實現，久而久之，一個軟體項目根本就毫無創造性可言，就是一個生產線生產出來的一個標准化產品而已。

所以，我覺得，程序員的生產，就是個研發，而研發就是創造，不是生產工具，不能以簡簡單單的任務量來衡量，更不能成為技術層面之外的人簡簡單單的薪酬衡量標准。用簡單思想框架來束縛程序員的思維創造性，這是拖累研究，極易打擊程序員的研究主動性。

但真正沒有辦法為程序員計算勞動所得嗎？我覺得， 既然，程序員的工作是研發創造性的，那麼，程序員就應當有個感性的前提，那就是視自身的勞功項目體現出的市場價值作為其勞動所得的標准。所以，我覺得，在這方面上，項目獎比起冷冰冰的績效考核溫暖得多，它直接反映的是程序員的創造性結果。在項目組內部的評比，則需要靠他們的直接帶領人來衡量貢獻的突出性，一是針對項目的技術貢獻以及任務完成的質量貢獻。

㈤ 代碼量能衡量一個程序員的編程水平嗎

寫代碼是依靠腦力生產結果，而編程效率、編程水平、工作時長、代碼質量、運行效率、生產力......這些復雜的因素決定了最後項目的質量。有的大牛隻用50%的代碼量就解決了初級程序員需要100%的代碼才能解決的問題。所以，用「產出的代碼行數」、「每日上班敲代碼的時間」...這種指標來衡量生產力，是不科學的。

㈥ 頂級的程序員是怎麼樣的

頂尖程序員常說：「這個我以前寫過一個模塊，我找找，很快。「簡直是沒有對比就沒有傷害!
有人認為，普通程序員用復雜的代碼解決簡單的問題;而高級程序員能把復雜的問題簡單化並用簡潔的代碼去實現。在w3cschool看來，頂尖程序員和普通程序員至少在以下6個方面大有區別。

1、文檔能力
「文檔是第一生產力」，這一點在程序員的世界是毫無異議的。看看Spring，hibernate，Struts等最流行的開源軟體的文檔就知道，他們tutorial，他們的getstarted，他們的reference文檔寫的多麼的易懂。
如果要獲得更高的報酬，文檔是絕對關鍵的因素。有文檔就有溝通，就有交易。搞技術的容易忽視文檔的力量，也因為寫文檔十分困難，更多程序員選擇舒適區，習慣寫下代碼，但正因為如此，妨礙了不少程序員的進階。
2、解決BUG的效率差別
普通程序員可以利用搜索引擎(網路)尋找答案，經常性找不到好的解決辦法，然後更換技術方案!頂級程序員也利用搜索引擎(Google)尋找答案，一般bug都順利解決(其實跟前期框架選擇等關系非常大)。

3、表達能力
表達能力決定了你所做的技術的影響范圍，決定了你的影響力，決定你的威信，決定了你的報酬。普通程序員和頂尖程序員的表達能力差別非常大，這主要還是取決於他們格局的不同。良好的溝通能力讓你理解產品經理的設計思路，讓你更好的展現自己的特長。

對於累積人脈，當你的閱歷越來越豐富，人脈對你的幫助也越來越明顯。
4、優雅和美觀的抽象能力
普通程序員和頂尖程序員之間的區別在於優雅和美觀的抽象能力。好的系統通常是要做到兩個方面才合格，其一是好用，其二是好看。但是令人遺憾的是，普通程序員僅僅從實現的角度進行堆砌。頂尖程序員往往能夠更進一步，經常會去思考用戶在操作這個功能的時候，到底還會做什麼事情。
所以，頂尖程序員和普通程序員區別就是是否擁有用戶意識，是否敢於直面用戶。好用，好看一直是軟體能夠被普遍採用的前提，因此，我們有必要學會抽象優雅。
5、面對如何開源社區態度
普通程序員幾乎沒有在開源社區混，這也導致經常對新技術發展關注度低。而頂尖程序員則是擁抱開源社區。

6、面對功能點
普通程序員：立馬開始構思自己如何實現腦海里出來一個方案。
頂尖程序員：發現功能點很普通github上面早已經有非常多的解決方案，著手根據業務選擇一個最適合最優的方案

㈦ 如何衡量程序員的工作效率

不過，最近Shahar Yair和Steve McConnell指出了該方法的一系列重要缺陷。首先，使用代碼行數之和無法有效評估一個項目的實際進度，因為它更注重行為而不是結果。最終產品在多大程度上依賴於代碼的性能和質量，這也是代碼行數無法說明的。因此，聚焦於此實際上是非常有限的工作效率測量方式。
SLOC無法表明要解決的問題的復雜性，也不能以可維護性、靈活性、擴展性等等因素來說明最終產品的質量。說到質量，它反而可能起到負面作用。通過重構、使用設計模式會減少代碼行數，同時提升代碼質量。代碼量大，可能意味著有更多不必要的代碼、更高不必要的復雜性、更加僵化難懂。
他指出，有些問題可以通過測量度量功能點數解決掉。那麼決定程序大小的因素就變成了輸入、輸出、查詢和文件的數目。不過這種方式也有其缺陷。McConnell提出一些操作性上的問題，比如必須要有一個大家認可的功能點測量機制，而且要想把每個功能點映射到程序員身上也不容易。Daniel Yokomizo是一位經過認證的功能點專家，他在評論中明確指出了這種方式的其他問題：缺少測量功能點復雜度的工具；還需要考慮諸如代碼共享、框架、程序庫之類的事情。這些都會影響到完成一個功能的時間。
有很多人參與了對於測量方式的討論，他們都同意這些做法有其局限，不過他們都覺得衡量開發人員的績效還是有必要的。實際上，不少人認為SLOC可以作為基礎，在其之上通過考慮多種不同因素來進行更復雜的分析。McConnell提出了四條分析開發人員工作效率的必備指導原則，他們也都同意。這四條原則如下：
1、不要指望單一維度的工作效率測量方式能告訴你每個人的真實情況。
2、不要指望任何測量方式可以在很小的粒度上區分出每個人的工作效率差異。這些方式可以為你提出問題，卻不會告訴你答案。
3、牢記：趨勢總是比單獨一點的測量來得重要。

㈧ 如何成為一個優秀程序員

從初入職場菜鳥到職場大咖，很多程序員在努力充實自己，有時候我們需要對自己進行一次能力定位，了解自己的優勢和沒有掌握的技術。芯學苑列出幾點作為初入職場的新手評估自己，明了前進學習的方向。

1、技術能力(解決問題的能力)

這是非常重要的事;過硬的技術能讓你得到面試機會，並在工作中游刃有餘。當公司招聘一個Java開發人員時，是會優先考慮能力因素的。在實際的項目開發中，一個程序員的技術能力等於其解決問題的能力。

如果拿一個尺度來衡量這個能力的話，一個程序員的能力可以用能完成任務的數量和難度來衡量。一個程序員能基本無誤的完成項目中的一個功能算是合格，但在此之前，他對項目的生產力為負，為他布置的任務，中間環節的溝通，修補bug的時間其實要多於自己直接完成該功能的時間的。能較好完成一個完整模塊的程序員才算是較好的程序員，也是項目中的主要開發者。能獨立完成整個項目才是優秀的程序員。

2、專業基礎(知識的積累)

一個程序員的知識積累很大程度上決定了其解決問題的能力。知道如何編寫代碼是基本的技能，但是知道Java編程語言的原理，知道代碼背後的演算法將使你從人群中脫穎而出。

3、主流編程工具

今天，事實是，你不能成為一個樣樣都懂的人(雜而不精)。你必須選擇你要掌握的工具。有時這是由工作的環境決定的，但是按照下面說的去做也是一個很好的選擇：

構建工具：Maven或Gradle。

SCM：Git(不是GitHub。大不相同)。

構建自動化：Jenkins。

IDE：Netbeans或Eclipse——不僅用於編寫代碼，而且還從IDE中重構和調試代碼。我遇到了很多沒有如何從他們最喜歡的IDE調試的開發人員。

Bug跟蹤：Bugzilla或Jira。

4、JSF的知識

應用程序伺服器

所有Java開發人員應該知道如何在Apache Tomcat中部署。

當Glassfish開發停止時，下一個最好的事情是J Boss Wild Fly。

5、溝通的能力

溝通是我們做好一切事情的關鍵。我們必須與我們周圍的環境保持互動，無論是在我們的私人還是職業生活中。一個良好的程序員知道如何在各種團體面表達自己。也許對你來說顯而易見的東西在他人的角度來看並非如此。

從大的尺度(比如一個人的工作生涯)來看，一個程序員知識積累的多少只決定於其自學能力和他對編程本身的興趣。

在一個分工明確的項目中，程序員需要理解產品，和領導溝通理解自己的任務，和同事們溝通以正確的方式進行合作。無論哪一個方面溝通出了問題都不是小事情，同時，程序員還需要正確的傳達設計的實現難度，以及讓別人正確的理解自己設計模塊的介面。在不寫文檔時，正確的口頭溝通非常重要，需要寫文檔時，良好的編輯能力也算做是溝通能力的一部分。

6、自學能力

這是一個非常重要的技能，在你自己的空閑時間學習新的技能。不要等待公司為你提供培訓。你需要自己去學習新技術，提升自己在相關領域的水平。從Java後端開發到架構模式，總是有一些新事物值得學習。經常閱讀博客和論壇，嘗試加入本地聚會小組。你學到的東西可以幫助你的事業。知識刷新頻率極快讓人無法追趕的這個時代，難免會有超出自己知識范圍的時候，此時你的自學能力決定了你能多快的完成任務。

7、良好的團隊合作精神

無論是部分編程還是大型項目，所有開發人員都是作為團隊的一部分在協同工作。你需要致力於團隊的目的，或幫助新的團隊成員克服障礙。不要存在這種「我只要做好我的本職工作，下班就直接回家」的態度。成為團隊的一部分，幫助周圍的同事，對自己的能力也是不小的提升。

就像拿破崙說的不想當元帥的士兵不是好士兵，追求參與一個大型軟體系統的開發，是每個程序員的夢想。在此之前，應該學習更多的專業知識，達到優秀程序師的標准。最後希望各位程序員閱讀本文後能夠得到一些裨益，在這條路上走得更好。

㈨ 如何量化衡量一個程序員的工作量和工作效率

1. 代碼數量

可以統計代碼行數，或者字元數量。

2. 代碼質量

顯然，代碼長不等於工作量很大。不光要考慮代碼的數量，還要考慮代碼的質量。那麼什麼樣的代碼是高質量的呢？什麼樣的代碼是「好」的呢？

「好代碼」的評判標准可能非常主觀。主流的價值觀中大概有以下標准：可讀性好（注釋不多不少，版面整潔，符合公司規則，變數名有意義等）bug 少（正確處理各種異常和錯誤）。優雅（設計優雅，實現優雅）

(9)拿什麼來衡量程序員的生產力擴展閱讀：

程序員的日常工作

1.確認通過審查方案的目標，輸入數據，分析師，監事，和客戶的輸出要求的項目要求。

2.安排項目要求在編程序列分析要求;准備工作流程圖和使用計算機知識的能力，題材，編程語言和邏輯圖。

3.編碼工作流程的信息轉換成計算機語言的項目要求。

4.通過輸入編碼信息的計算機程序。

5.確認程序操作進行測試，修改程序序列和/或代碼。

6.准備寫操作指令供用戶參考。

7.保持歷史記錄，通過記錄方案的制定和修訂。

8.維護客戶的信息和保護保密的業務。

技能/資格：一般的編程技巧，分析信息，解決問題，軟體演算法設計，軟體性能優化，注重細節，軟體設計，軟體調試，軟體開發基礎，軟體文檔，軟體測試。程序員其實分為很多種，大家開發的語言可能不盡相同，但是都是有他們的共同點。

參考資料來源：網路-程序員

㈩ 關於程序員，卓有成效的績效考核方法

考核程序員第一條：編程能力，看代碼行數和實現的功能項數
考核程序員第二條：糾正能力，考核其按時完成整改和待整改問題的比率
考核程序員第三條：程序風格，檢查裡面違反編程規定的次數作為關鍵的考核點