程序員任務交付質量怎麼衡量

❶ 程序員進度考核標准

程序員工作是一種智力活動，應主要根據工作結果來進行考核，主要考核指標有網站模塊質量合格率、時間節點任務完成率等，工作標准由你自己來定，一般這兩個指標的標准都要達到80%以上。
具體操作步驟如下：
1、根據公司要求及程序員的工作量制訂工作時間節點計劃表，設定成為幾個階段，每個階段有明確的時間規定和工作成果規定；同時設定考核指標、考核標准和獎懲措施。
2、到了節點的時間就對程序員的工作進行評估，如果沒達成節點成果，就要求程序員制訂改進措施，或加班或改進方法，措施也要有時間和效果控制標准，以便於確定改進措施的階段性評估。
3、在工作完成後根據程序員的工作完成情況，進行獎懲兌現。

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

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

❸ 提高工時估計准確性

「如果一個程序員告訴你他已經完成了 90% 的工作量，那麼他還需要同樣的時間完成剩下的 10%。」
軟體項目容易延期和跳票是屢見不鮮的事情，其中不乏知名項目。

剛畢業的時候，我在一家做系統集成的公司工作，我們定製了一套售票軟體，為景區接入互聯網售票方案。供應該軟體的軟體公司非常自信的說，這東西非常簡單，最多 2 個月就能搞出來。這家公司小有名氣，我老闆對 2 個月交付深信不疑，於是張羅了接入的客戶、市場的物料等。

不難猜到，最終還是沒能逃過 90% 定律，2 個月交付的東西只能算作一個 Demo。於是花了另外一個月測試，修復問題和完善業務邏輯，又花了另外幾個月時間響應對接客戶的要求，才逐漸穩定下來。

行百里者半九十，軟體開發也大體如此。開發者估不準工時常有，估准了才奇怪呢。

後來自己也做了軟體工程師，參與 IT 項目開發，項目延期也是非常常見的事情。

IT 團隊能准時交付是一項非常有價值的能力，哪怕交付時間長一點。計劃兩周交付，最後能准時完成，比承諾 一周時間，但是花了三周才交付重要得多。

越是大項目，越是重要。大項目的各個組件可能會發生相互依賴。如果不能准時交付，就會付出團隊等待的成本，那可是真金白銀。

做過項目管理的都知道甘特圖，甘特圖的每個泳道表達了項目各項資源的進展和計劃。然而，軟體項目不確定性非常多，存在各種突發事件。如果能提高准時按質量交付，各個單位的等待成本會小很多。

關鍵的是，衡量准時交付的關鍵是質量，其次才是交付。先給一個 demo，然後再慢慢改 bug。這種 「准時」 的交付，還不如有一個明確的延期時間，本質上還是 「猛糙快」。

談項目工時估算，應該是在滿足質量要求的前提下，否則估時沒有意義。

那麼能不能提高軟體工程工時的估算的准確性呢？其實是可以的，剛到 ThoughtWorks 的時候，參與了一個交付項目。在一個項目開始前就計劃了項目結束的時間，以及下一個項目的計劃和安排。結果讓我非常吃驚，那個項目的結束時間，和預期相差兩周左右。並且這兩周是逐步減少開發人員，最後只有 1-2 個人負責最後一周的交接期。

這就是專業軟體團隊和小作坊的差別，在專業項目經理帶領下能把 3 個月的項目估算，精確到 20 - 30 個人天。能把項目工時估算到這種程度，體現了 PM 的內功。

在一個敏捷團隊，需要把工時估准，不在於 「估」 ， 而在於團隊執行項目的穩定性。 一般來說，准確估算工時需要考慮需求分析程度、任務拆分的合理性、技術方案的可靠性、團隊成員的能力、外部依賴和環境，如果這個項目不是新項目，還需要考慮遺留系統改造的成本和數據遷移的成本。

只有把需求分析做的非常徹底，才能保證估算的輸入條件。非專業的業務分析師，只能看到需求冰山水面上的部分 —— 軟體的特性、功能的復雜性等。

專業的業務分析師，不僅需要考慮功能需求，並對功能需求的邏輯性考慮完備。比如用戶需要一個 APP，他實際上還需要一個後台，對應這個後台會有不同的用戶、角色等。

根據這些業務輸出、拆分出任務，敏捷開發中我們叫做用戶故事，一個用戶故事代表一個合理拆分的業務邏輯。能被評估工作量，然後根據這個工作量來評估工時。

除了這些功能需求之外，還有非功能需求。客戶不僅僅需要一個 APP，還可能需要的是一個安全的、高性能的、國際化的 APP，而這些往往被客戶當做默認選項。

一些性能優化的指標需要分析，並考慮性能優化的任務工時；安全需求可能有 HTTPS 配置，防病毒掃描等，都需要考慮；國際化也是額外的工作量。

挖掘用戶真實需求的目的是定義怎麼才算完成（Definition of Done），如果沒人說得清楚滿足什麼條件這個項目才算完，那麼估算工時根本無從談起。

徹底挖掘客戶的真實需求是評估項目工時的首要條件。

技術方案、團隊能力和項目時間估算有很大關系。很多項目的時間估算都是由技術經理或者 Tech lead 來完成，往往是他們按照自己的經驗和能力進行計算的。光是這樣，很難算的准。

團隊有多少人？對這套技術方案的熟悉程度如何？方案是否會發生較大的調整。人一多，人員水平差距就為工時估計帶來了不確定性。經驗多的人來做方案，如果是他做過的相似方案，自然會估的稍准一點。但大多數情況下沒有這么理想的場景。

要做好工時估算，需要結合技術方案和團隊成員能力，而不是自己能幹多少活兒，多快幹完來算。

一方面，技術負責人需要安排相應的技術預研，走在實際編碼的開發人員前面，探探路，驗證方案的可行性、實施難度、風險。就像作戰的偵查人員一樣，我們把預研叫做 spike。 spike 需要輸出一些結論、demo，支持項目的時間估算。

另外一方面，考察團隊真實運作效率很好的方式是根據迭代做工時統計。按照兩周為例，10 個人的團隊是 100 個工時。如果按照之前的估算，2 周內需要完成的 100 個工時的任務，實際上只完成了 50 個工時。也就是進度只有 50%。

我這個演算法比較粗糙，敏捷項目管理中還有更准確的速率計算方式。通過速率，就能對下一階段的工時估算做出調整，並在工作量、人員上做出調整。

通過方案預研和速率計算是提高項目工時估算準確率的良好方法。

我常常花了一下午時間完成了某個特性升級的編碼，但是花了一個月的時間才完成了線上平滑升級、數據遷移。

真正有經驗的工程師都知道，方案設計的難點往往不在設計一個新東西，而在於演進一個老系統。遺留系統演進是不可避免的，這種歷史包袱是造成工時估算不準的一個重要因素。

遺留系統演進帶來的估算困難來源下面幾個方面：

不負責的猜想，有一些客戶就是遺留系統演進不下去了，然後招標做新功能，實際意圖是想乙方順便消化重構的成本。總之基於遺留系統的二次開發都是一件困難的事情，能不接就不接吧。

另外，社會分工意味著一個人干不完所有的事情，IT 項目往往一個項目也不是獨立的。大多數情況下需要和外部條件進行集成，這部分時間超出我們的掌控。

集成這件事的成本需要視主動集成還是被動集成來說：

集成充滿了不確定性，估算工時時需要預留足夠的集成空間，才能讓工時估算更准確。

項目工時估算是一個系統性工作，基本上很難有一個萬能的方法。因此大多數情況下都是玄學，但是畢竟是 「估」 ，也不能要求 100% 精確。

軟體工程的估時更具有彈性，相對供應鏈管理的交付時間估算成本更低。做好估時，對減少項目運行成本和風險有巨大意義，工時估算的准確性也往往體現了一個 IT 團隊工程能力。

❹ 如何對程序員績效考核

對於程序員的績效考核主要綜合這么幾個方面，由於各家公司情況不一，對於側重哪個方面要看實際情況：
1 編碼任務的完成效率：可以結合提交代碼量、完成計劃任務時間點等綜合判定程序員是超額提前完成任務，准時完成任務還是出現拖延，相應給績效
2 程序員編碼的質量：可以結合所負責產品的BUG情況等來判定程序員編碼的質量情況，根據質量較高，一般，較差相應給績效
3 所負責額外工作情況，在產品開發中，可能涉及兼做一些其他的事情，比如配置管理，運維.工作.等等，另外比如作出技術研究，寫的東西可以推廣給其他人使用，提交他人的工作效率需要相應給出績效獎勵

❺ 怎樣更好的評測一個程序員的工作質量

量化:
1、必須要對程序員負責模塊所需工時有個精確估計(要根據代碼量和難度進行區分，然後結果和實際進行對比)
2、測試時記錄程序員負責模塊的bug數(當然也是平均bug數與實際bug數對比，當然跟代碼量有關)

❻ 如何對程序員績效考核

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

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

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

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

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

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

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

1. 代碼數量

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

2. 代碼質量

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

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

(7)程序員任務交付質量怎麼衡量擴展閱讀：

程序員的日常工作

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

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

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

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

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

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

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

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

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

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

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

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

謝謝大家。

❾ 程序員代碼質量的好壞是如何區別的

現在的程序設計是一個系統的過程，程序員代碼質量的高低往往也與他所處的團隊有較大的關系，也就是說頂層的設計與代碼質量有直接的關系。所以說優秀的團隊往往都是優秀的代碼，但是普通的團隊往往很難寫出優秀的代碼。
代碼的編寫大致上經歷幾個步驟，第一個步驟是頂層設計（架構師）。
頂層設計包括軟體架構設計、技術方案等內容，落實到代碼上往往就是大量介面的定義。好的設計需要考慮三方面因素，分別是結構性（模塊化）、完整性、擴展性，當然還需要考慮可移植性，通常結構性好的代碼移植性也會比較不錯。
第二步是核心代碼的實現（研發級程序員）。
有的團隊也把這部分稱作為「容器」開發，簡單的說就是功能性平台開發，目的是實現平台級API。這部分代碼的開發是整個軟體開發的核心部分，承擔這部分開發任務的程序員往往就是我們所說的研發級程序員。研發級程序員代碼質量的衡量標准主要在演算法設計與實現上，性能指標是考核的重要因素，另外還要考慮穩定性和完整性等核心因素。
第三步是功能編寫（應用級程序員）。
功能編寫簡單的說就是完成具體的業務邏輯實現，需要調用平台提供的API完成具體的功能。這部分程序員占據了程序員群體的大部分比例，也就是通常所說的應用級程序員。應用級程序員的代碼質量主要從代碼編寫結構上來看，比如是否有標準的打包、命名、注釋，以及代碼整體結構是否清晰，邏輯結構是否清晰等方面。
往往程序員代碼的質量會隨著編程經驗的提高而不斷得到提高。
我做軟體開發多年，目前的主要研究方向是大數據和人工智慧，也在帶大數據方向的研究生，我會陸續在頭條上寫一些關於大數據方面的文章，感興趣的朋友可以關注我的頭條號，相信一定會有所收獲。
如果有大數據方面的問題，也可以咨詢我，
謝謝！

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

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