02.28 每天在公司寫3000行代碼,在行業內是個什麼水平?

太乙神數


單憑3000行這個數字說明不了什麼,如果有特定的模板,或者簡單一點的需求,3000行也是寫得出來的,本人曾趕一個後臺,一天一夜之間完成100多個文件,至少在3000行以上;但如果是高難度需求,一天寫10來行也很正常。本人還曾經碰到一個高難度需求,前前後後一共折騰了差不多個把月,修改的次數不算,僅重寫就搞了五六遍,最後歸集為一個類,整個類定義才300多行,最核心的算法部分才30幾行。等最後把這個類寫完,感覺整個人都快要癱了似的,比一口氣寫那上百個後臺文件累多了。


暫時沒有取任何名字


3000行,那是不用腦子外加代碼生成器的代碼也計算在內的結果。如果你不在外包公司,就是最底層的軟件藍領當然公司也不小。有質量的代碼,一天100行甚至30行就已經很牛了。

我曾經接手過一個項目,有2-30人維護,但運行還是問題不斷,當時的問題是要不要用新架構重新開發。我看過項目架構和代碼後,就決定對現有項目進行優化,而不是重新開發。一個團隊去做客戶需求的新模塊,由我帶領的小組做提高穩定性和讓項目可維護。最後、在保持功能不變的情況下我將項目的代碼縮減到原有的十分之一,性能提高100倍,數據量縮小30%。維護人員降到5人。客戶反響好維護的費用不變,這樣利潤很高。而我每天的代碼量相對於項目整體而言是負數。而後面我做的工作就是每月檢查新增代碼,把不按規範做的找出來,要求整改,不聽話的程序員調到開發組去做藍領,什麼時候懂規範了,理解架構的意義了,再考慮培養提升。就像軍訓一樣,會走正步方陣了,再上來打硬仗。

這要求的是團隊裡必須都是有經驗懂架構的高手,人不多就2-3人,多了也沒法搞。

什麼時候你的代碼量降低到100行而公司對你的考評也是ok的,那你才算真正是在編程序,而不是砌磚。


懶爸爸育兒日記


程序員正常的水平一小時寫10行左右。這個速度不是單純地寫代碼,還包括了調試,測試的時間。能保持這個水平的程序員應該很不錯了。

程序員的水平不能單純看他寫代碼的速度。我自己寫代碼的最高紀錄是一天一萬多行吧。當時是把一個算法用EXCEL算出所有的結果,再用公式拼成一萬多行代碼。邏輯部分不到十行,其餘都是數據。看出來那個算法就是一組固定數據的集合,用靜態數據結構代替了動態邏輯運算,有點投機取巧了。

還有比我更快的。一個朋友在某軟開發多年,離職的時候帶走了公司的代碼庫。靠著這套代碼庫出來創業,寫代碼基本靠複製粘貼,他一天的代碼量不能看行數,得看源文件大小,得按MB計算。跟這位大神相比一天3000行勉強算是青銅吧。


日衝信息 黃


首先我們要知道,一個在公司工作的程序員每天平均要寫多少行代碼?我們再來看一天寫3000行。到底是什麼樣水平?

平均一天100行有效代碼我就覺得對得起自己了。這是純手工寫C++。這是一種還有另外一種。

做web的報表系統,人家寫好了一張報表,拿來照著套“生產”其它報表,連html估計一天能幹個上萬行,幾十張報表就這麼幹……

其實寫不難就是關鍵是花在思考和查資料上的時間比敲代碼多得多。

代碼這種東西,從來都不是越多越好。行數並非判斷代碼質量的標準。只是想說,我做一個旁觀者閱讀一些外包公司代碼時發現下面的代碼(變量名的修改),當時覺得很奇怪,為什麼IsAdult方法寫這麼麻煩(沒有評論註釋是原始的,是我重寫),然後突然醒來時,該公司很可能是基於行代碼與甲方接收錢。對於軟件公司來說,評估程序員性能的標準之一是它會導致代碼的拖拉和運行。

內行看門,業餘的看熱鬧。雖然代碼,每個寫代碼或看到代碼的人都能說幾句話,但是別人,我不知道別人為什麼發表這些數據,增加別人有什麼意思。這種數據很好,即使人們看了,“哦,我是這樣的……”至於是否要嘗試“雙重生產代碼”或“努力簡化代碼”,這是他們自己的問題。

自己的一些泛泛之談,參考就好。

可以這樣理解:

以我現在的水平,每天寫的原始代碼大概是1200行。需要用相同多的時間來調試,再需要相同多的時間來優化,還需要相同多的時間來編譯測試,算下來每天能寫300行有效代碼。

讓我寫一個windows的話,需要10W天=273.97年

其實編碼只是整個軟件開發過程裡面的一小部分。我想大家知道了吧厲不厲害





極光配晨曦


首先我們要知道,一個在公司工作的程序員每天平均要寫多少行代碼?我們再來看一天寫3000行。到底是什麼樣水平?

平均一天100行有效代碼我就覺得對得起自己了。這是純手工寫C++。這是一種還有另外一種。

做web的報表系統,人家寫好了一張報表,拿來照著套“生產”其它報表,連html估計一天能幹個上萬行,幾十張報表就這麼幹……

其實寫不難就是關鍵是花在思考和查資料上的時間比敲代碼多得多。

代碼這種東西,從來都不是越多越好。行數並非判斷代碼質量的標準。只是想說,我做一個旁觀者閱讀一些外包公司代碼時發現下面的代碼(變量名的修改),當時覺得很奇怪,為什麼IsAdult方法寫這麼麻煩(沒有評論註釋是原始的,是我重寫),然後突然醒來時,該公司很可能是基於行代碼與甲方接收錢。對於軟件公司來說,評估程序員性能的標準之一是它會導致代碼的拖拉和運行。

內行看門,業餘的看熱鬧。雖然代碼,每個寫代碼或看到代碼的人都能說幾句話,但是別人,我不知道別人為什麼發表這些數據,增加別人有什麼意思。這種數據很好,即使人們看了,“哦,我是這樣的……”至於是否要嘗試“雙重生產代碼”或“努力簡化代碼”,這是他們自己的問題。

自己的一些泛泛之談,參考就好。

可以這樣理解:

以我現在的水平,每天寫的原始代碼大概是1200行。需要用相同多的時間來調試,再需要相同多的時間來優化,還需要相同多的時間來編譯測試,算下來每天能寫300行有效代碼。

讓我寫一個windows的話,需要10W天=273.97年

其實編碼只是整個軟件開發過程裡面的一小部分。我想大家知道了吧厲不厲害


MSN魚Mr


每天寫3000行代碼在當前的IT行業內是很難想象的,即使很多早期從事外包開發的程序員也很難有這樣的工作效率,大部分程序員每天的代碼量都在幾百行左右,研發級程序員一天的代碼量通常不會超過300行,應用級程序員的代碼量也很少能夠突破500行。從業多年以來,只有在工作初期,面對較為簡單的應用級開發時,每天的代碼量會相對多一些,但是即使加班到凌晨,代碼量也很難會超過1000行。

代碼的編寫通常需要經過三個階段,第一個階段是邏輯設計,這個過程涉及到算法設計、數據結構定義和技術選型等過程,這個過程往往是比較耗費時間的,通常在採用一個新技術之前,還需要進行應用場景驗證,這通常還需要多人配合才能夠完成。如果是研發級任務,這個過程會佔據大部分的工作時間,真正的代碼編寫時間並不長,代碼量也不會很多。實際上,很多容器的核心代碼也不過萬餘行左右,但是通常也需要多人的開發團隊開發數月才能完成。

第二個階段是代碼編寫,如果是應用級程序員,代碼編寫會佔據更多的時間,因為應用級開發往往已經有了比較清晰的規劃,只要按照架構師的設計方案進行編寫就可以了,但是即使是應用級程序員,代碼的編寫也需要一個思考和驗證的過程。實際上,隨著當前雲計算(PaaS)在開發領域的廣泛使用,目前應用級程序員的代碼量得到了較大幅度的下降。

第三個階段是調試,這個階段往往也會佔用較多的時間,尤其是在新場景開發的初期,調試會佔用更多的時間。按照歷史經驗來看,程序員的開發經驗對於調試時間有較大的影響,程序員開發經驗越多則調試速度也會越快。

我從事互聯網行業多年,目前也在帶計算機專業的研究生,主要的研究方向集中在大數據和人工智能領域,我會陸續寫一些關於互聯網技術方面的文章,感興趣的朋友可以關注我,相信一定會有所收穫。

如果有互聯網、大數據、人工智能等方面的問題,或者是考研方面的問題,都可以在評論區留言,或者私信我!


IT人劉俊明


我感覺題主有一個誤區。寫的代碼行數多少能夠決定技術水平麼?其實,每天寫代碼的行數跟技術水平其實沒有任何關係。

代碼行數跟技術水平相關聯的話,就跟老闆用代碼行數來考察一個人的 KPI 一樣不靠譜。


代碼行數,跟個人水平沒有關係

你想想,一個人每天敲代碼行數即使是 1 萬行,又能怎麼著?如果他天天干的活,敲定的代碼,都是非常簡單的業務邏輯,每天的工作幾乎都跟複製粘貼一樣, ctrl + c 和 ctrl + v 。其實毫無技術含量。

可能一個資深的架構師,每天敲的代碼行數連 300 行都沒有,但是這並不妨礙人家成為資深架構師。


所以代碼行數和個人能力水平其實沒有什麼關係的。


另外,接下來會給大家普及一下概念,其實,你真實的有效代碼行數根本就沒有 3000 行。


什麼是有效代碼行數?

有效代碼行數統計必須遵循了代碼一致的存放規則。主線、分支、標籤,必須按照劃分好的規則和目錄存放。代碼在提交到主線之前,必須經過嚴格的代碼審查。而開發人員用來做 debug 的 code 必須要單獨存放,拉出去的 branch 也要嚴格區分。只有確認提交到主線的 code,才能真正在主線裡出現。這不只對於項目代碼規模統計有意義,也對項目代碼的規範管理帶來積極的影響。在統計代碼時候,如果只統計主幹的有效代碼,必然會提高代碼統計的精確性。對於不同子項目的私有代碼和公用代碼必須區分清楚,並能很方便的統計出來。開發人員也需注意的是,必須及時提交自己的代碼,否則未提交代碼肯定是無法被統計在內的。

大多數 QA 在統計有效代碼行數的時會排除以下代碼:

  1. 自動生成代碼(開發環境生成或自己開發的生成工具生成)

  2. 格式需要的空行或分隔符不算

  3. 要有相應的註釋但註釋本身不算行數。


所以,你說拋出去工具自動生成的代碼,以及空行和分隔符,以及換行的大括號,以及註釋等,你其實一天的代碼行數,根本就不會達到 3000 行的。


是不是這篇回答,給大家普及知識了?如果感覺學到知識了,記得給我的回答點個贊哦!點個贊哦!或者留個言哦,咱們一起交流探討。

非著名程序員


日寫3000行什麼水平?菜鳥一天也寫不了這麼多吧。如果真的一天寫3000行代碼,我勸你趁早轉行吧,不適合寫代碼[淚奔]這個不是以代碼行數越多就是越好的,在保證功能的前提下,代碼越簡潔越好,日後也方便維護或拓展




24號傳奇小飛俠


回答問題之前,我先猜測一下,能夠問出這個問題的同學,應該不會是個程序員或者根本沒有在IT這個領域幹過。

為什麼說不會是個程序員或者不是個IT人呢?

我們先把程序員分一下類,一般來說,程序員包括前端工程師、後端工程師、嵌入式工程師、算法工程師、IOS/Android工程師等等 。

再來簡單看看每個不同崗位的程序員工作是如何的。

對於前端工程師來說,主要使用的語言就是JavaScript,其餘就是和HTML、CSS打交道。對於一個比較初級的前端工程師來說,每天有效的代碼行數能夠超過100行,基本就算是及格了,對於比較資深的前端來說,能夠達到300-500行,也算是不錯的了。

再說說後端工程師,我們現在最主流的研發語言就是Java,其實做後端和做前端只是考慮的業務面不一樣,前端主要想的是人機交互,後端主要是數據和業務的處理。因此,對於一個後端工程師來說,每天能夠150行左右的代碼算是及格了,資深一點的也就是300-500行的這個範圍。

而算法工程師嚴格意義上來說其實也算是後端,所以可以和後端工程師同樣看待。而IOS/Android和前端類似,所以計算代碼行數,可以參考前端。

不同的就是嵌入式工程師了,嵌入式工程師主要是面向芯片、面向硬件控制,代碼量不會太大,一個嵌入式工程師,一天能夠有幾十百把行代碼已經算是不錯的了。

OK,我們大概瞭解了情況以後,再言歸正傳,每天寫3000行代碼的程序員是什麼水平?

我只能說,這個高度只要是個程序員,都不可能達到。就別說程序員了,寫網絡小說的專業寫手也寫不到這個水平。

一個寫網絡小說的作家,一天兩章更新算是比較普通了。如果熬個夜,勤奮點,可以做到三章更新。一章差不多就3000字,一行大概30個字左右,差不多就是100行。一個專業的寫手也就是200-300行每天的碼字量而已。

程序員就和專業寫手一樣,只是碼的是代碼,寫完代碼以後照樣要檢查一遍,如果出點什麼bug,還需要debug一下,造點數據跑下流程。還需要溝通業務,瞭解需求,有時候遇到技術難題,還需要一起攻關一下。每天真正用在碼代碼的時間估計只有3分支2不到,3000行的代碼,那不是人能夠幹出來的事。


會技術的葛大爺


一個頂尖Google工程師每天產生的代碼大概在100-150行!而一個合格的頂尖工程師從來都不是用代碼行數來衡量自己的工作成就,一個優秀的工程師應該是要儘可能多的產生高質量代碼。

用代碼行數評價程序員是不公平的

早些年在傳統軟件公司存在一種用代碼行數來衡量工作質量的方式,當然在傳統軟件企業這個工作是有一定合理性的。傳統軟件企業需求變動小,所有的產品迭代都有一個相對確定的週期,大家都是按部就班的按照工作計劃來工作,工作量好衡量,不過在互聯網企業這一點完全不一樣。

互聯網需求變動極其頻繁,昨天的代碼今天可能就不行了,相對於傳統軟件同時實用導致的併發壓力小不同,互聯網軟件動輒上千萬、上億,甚至上十億的用戶在使用同一個產品同一個功能,一旦用戶上億,技術難度遠超過業務本身的難度,需要解決的問題將變得非常複雜,每一行代碼可能都需要經過非常多的思考、推演,背後的工作量其實是極大的,這是代碼行數不能直接體現的。大家想想愛因斯坦質能公式多簡單,可是背後愛因斯坦付出了多少艱辛很多人都不理解。

傳統軟件公司通常是“項目經理+技術經理+工程師”為主幹架構,而項目leader往往就是這個項目最大的項目經理,互聯網公司則更多的變成了“產品經理+算法工程師+研發工程師”的主幹架構,項目leader往往就是這個項目最大的產品經理,互聯網很難像傳統軟件企業管理項目那樣去管理項目,這也導致了你不能用代碼行數來衡量其工作質量。

一大半時間在思考、你做的產品給很多人帶來便捷才是你真正的價值

硅谷的工程師跟國內的工程師其實還是存在比較大的差異的,在硅谷沒有像國內這麼明確的分工,基本上入職的崗位都叫做研發工程師,大家都要寫代碼,都要參與業務,都要研究算法,即使是很多做到了科學家級別,也要寫一些代碼。

好的程序員,一半以上的時間都在思考,在想著如何更好的設計,你的價值更多的取決於你對於這個項目的影響,而這些影響往往都不是直接的。移動短信到真正徹底被即時通訊軟件所取代,花了接近20年的時間;支付寶從一個支付中間工具到真正上線快捷支付也長達十年時間;同時有數萬、數十萬用戶點外賣或者打車,這對於技術又是多麼大的挑戰。

互聯網就是這樣,一旦你實現了一個功能,很有可能有上億的用戶會使用,這就是你的價值,你寫的每一行代碼都可能影響到每一個用戶的日常生活。還是回到數學例子,就好像最簡單的圓的面積公式,極其美觀簡潔,可是這背後經歷了上千年的不斷探索,思考的過程遠遠比結果要曲折得多。


分享到:


相關文章: