衡量服務(wù)質(zhì)量的六個標準 如何辨別一個程序員水平的高低?
如何辨別一個程序員水平的高低?以上五個步驟基本上說明了它是否是一個好程序3000行,這是無腦代碼生成器計算代碼的結(jié)果。如果你不是在一家外包公司,你就是底層的藍領(lǐng)軟件工人。當然,公司也不小。質(zhì)量代碼,每
如何辨別一個程序員水平的高低?
以上五個步驟基本上說明了它是否是一個好程序
3000行,這是無腦代碼生成器計算代碼的結(jié)果。如果你不是在一家外包公司,你就是底層的藍領(lǐng)軟件工人。當然,公司也不小。質(zhì)量代碼,每天100行甚至30行已經(jīng)很好了。
我曾經(jīng)接手一個項目,由2-30人維護,但在運行中仍然存在問題。當時的問題是是否用新的建筑重新開發(fā)。在研究了項目架構(gòu)和代碼之后,我決定優(yōu)化現(xiàn)有的項目,而不是重新開發(fā)它。一個團隊做了客戶要求的新模塊,我?guī)ьI(lǐng)團隊做了提高穩(wěn)定性和使項目可維護性的工作。最后,在保持函數(shù)不變的情況下,我將項目的代碼減少到原來的十分之一,性能提高了100倍,數(shù)據(jù)量減少了30%。維修人員減少到5人??蛻舴磻?yīng)好,維修費用不變,所以利潤很高。我每天的代碼量相對于整個項目是負的。我以后做的就是每月檢查新代碼,找出不符合規(guī)范的代碼,要求整改,把不聽話的程序員轉(zhuǎn)到開發(fā)團隊做藍領(lǐng)。我什么時候才能理解架構(gòu)的規(guī)范和意義,然后考慮培訓和改進。就像軍訓一樣,我們會在方陣中邁出積極的一步,然后上來打一場硬仗。
要求團隊必須有經(jīng)驗并精通體系結(jié)構(gòu)。如果人不多,會有2-3人。如果人太多,他們就做不到。
當你的代碼減少到100行,公司對你的評價還可以時,你就真的是在編程,而不是在砌磚。
每天在公司寫3000行代碼,在行業(yè)內(nèi)是個什么水平?
讓我們從程序員的工作年限開始。
1-3年,屬于一個文件,筆記可以寫得很好,不怎么bug,就算通過了。
3-5年,屬于檔案,能看懂業(yè)務(wù),筆記貴精不多。我積累了經(jīng)驗。沒有輪子了。我會偷懶的。蟲子幾乎消失了,因為這個級別為自己的蟲子找借口。
六年后,它屬于第一級,可以說是編程領(lǐng)域的一把老炮。最難管理的人。但這群人嚴重兩極分化,有的會回到以前的水平,甚至更糟。還有一些人在建筑師的層面上努力工作。他們少寫代碼,多思考。他們在工作時間寫的代碼不多,但公司的框架可以及時出現(xiàn),沒有大問題。
關(guān)于這個問題,情況很正常。一年的工作重復8年,但有8年的工作經(jīng)驗沒問題,但絕對不如8年的水平。
不要噴灑。
怎么有的老程序員的代碼寫得還那么爛?
績效考核是對每個部門和員工工作數(shù)量和質(zhì)量的評估。各類工作都有其特殊性,因此考核工作必須建立適用于各類工作的量化標準。
從程序員的工作特點來看,生產(chǎn)代碼行數(shù)是評價他們工作的最合適的量化標準。雖然這個標準不足以考慮每個程序員的工作質(zhì)量,但是程序員的工作質(zhì)量并不是由他們自己控制的。他們只能保證自己輸入的代碼嚴格按照架構(gòu)師制定的語句原則和變量算法原則,保證輸入中沒有輸入錯誤,至少保證鍵語句輸入中沒有錯誤。只要能做到這些,程序員代碼輸入量達到規(guī)定的行數(shù)或超額,就可以判斷其性能考核結(jié)果是否合格或優(yōu)秀。
績效考核的最大難點是崗位量化原則的制定。有些崗位不能用工作量來考核,比如公關(guān)部。對于此類部門,其目標任務(wù)的完整性比率只能在考核周期內(nèi)計算。如果比例高于預定值,則為合格;如果比例低于該值,則為不合格或較差。
績效評估是人力資源部的一項挑戰(zhàn)。許多企業(yè)由于標準制定上的問題,使得績效考核流于形式,這是一種非常危險的現(xiàn)象。這將嚴重影響整個公司的工作效率,甚至嚴重削弱公司的核心競爭力,因為核心競爭力除了內(nèi)在的市場導向和品牌識別外,還包括企業(yè)文化戰(zhàn)略和人力資源戰(zhàn)略的有效性
為什么有些領(lǐng)導要用代碼的行數(shù)來衡量員工的工作量?
在沒有bug的情況下,首先,程序員熟悉編程。下一步是尋找最具創(chuàng)新能力的程序,并對代碼進行優(yōu)化和簡化。在一些語句中,你可以使用數(shù)組或一些最小的代碼來完成你想做的事情,因為有許多不同的方法來實現(xiàn)一個程序的結(jié)果,如何走得最快和最短簡言之,最簡單的方法來完成你要做的是高質(zhì)量的執(zhí)行。
在不出現(xiàn)bug的情況下,如何衡量一個程序員的代碼質(zhì)量高低?
自2003年以來,我們一直在做程序設(shè)計。一般來說,我們寫的代碼越多,我們需要的代碼就越少。
在程序開發(fā)之初,我主要做了功能實現(xiàn)。負責項目設(shè)計的同事把界面寫得很好,剩下的就是功能實現(xiàn)。實現(xiàn)寫功能并不困難。簡單地說,數(shù)據(jù)以固定格式處理后,就可以發(fā)回。在此期間,每天的代碼量相對較大,平均每天大約有500行。
隨著他們編碼能力的提高,很多代碼重用會做得更好。在整個實現(xiàn)過程中,他們會采用比較簡單的實現(xiàn)方法,也懂得如何使用模塊化的開發(fā)模式。通過這個過程,代碼的數(shù)量在一定程度上減少了,但是思考的時間變長了,有時需要一些時間來驗證。在2006年確定自己的主要方向時,代碼量再次下降。因為工作中心已經(jīng)從函數(shù)編寫調(diào)整到了一些框架設(shè)計和算法實現(xiàn),這段時間每天的代碼量大約在200行左右,其中很多是編寫接口。在此期間,重點工作是實現(xiàn)算法,做數(shù)據(jù)分析和建模。在這段時間里,還使用了Matlab,因此編碼量大大減少,但難度增加了很多。有時需要一周甚至更長的時間來完成算法的驗證。
2010年之后,我將機器學習和大數(shù)據(jù)添加到我的主要攻擊方向。這時,我每天的代碼量又下降了,平均有100多行。有時一天可以寫幾十行代碼,對算法進行分析、訓練和驗證的時間就變長了。當java第一次被使用時,代碼的數(shù)量可能會更多。后來,當使用Python時,代碼量減少了很多。目前,算法的實現(xiàn)也采用Python。
事實上,在計算機研發(fā)中,編程更像是一種工具。無論使用何種語言,最終的任務(wù)都是實現(xiàn)功能。編碼量與角色有很大關(guān)系,但與編程水平?jīng)]有直接關(guān)系。當然,高級程序員必須有大量的代碼基礎(chǔ),這是毋庸置疑的。