程序員代碼量過20萬行，是一種什么體驗？如果一個獨立的項目由一個人維護超過20W，那真的很難?？梢哉f是重復重構(gòu)、分解模塊、提取公共庫、進行分層處理，以及引入工具來使用lint工具進行代碼。當代碼量超過

程序員代碼量過20萬行，是一種什么體驗？

如果一個獨立的項目由一個人維護超過20W，那真的很難?？梢哉f是重復重構(gòu)、分解模塊、提取公共庫、進行分層處理，以及引入工具來使用lint工具進行代碼。當代碼量超過5萬條時，他們開始注意命名規(guī)則、文檔、注釋、模塊的初步劃分，并熟練使用調(diào)試工具和命令。但有時他們不得不尋找使用方法。寫日志有點武斷。

當代碼達到100000行時，模塊劃分完成，系統(tǒng)分層開始。同時介紹了代碼掃描工具。同時，調(diào)試級別完善，崩潰時生成核心文件，便于分析。日志非常標準和完整。同時，開始做代碼檢查。提供各種接口文檔。并開始了解操作系統(tǒng)和虛擬機，以及編程語言和各種庫的底層細節(jié)。他已經(jīng)是某個領(lǐng)域的資深人士了。

涉及到200000行時，有代碼規(guī)范、日志規(guī)范、架構(gòu)設(shè)計、性能指標、硬件要求、異常處理、數(shù)據(jù)描述、接口描述、數(shù)據(jù)流圖、配置表、數(shù)據(jù)字典、歷史異常摘要等文檔。同時，它涉及到網(wǎng)絡(luò)、文件、操作系統(tǒng)、腳本和語言。在這個階段，維護代碼，做一個小改動都嚇壞了。是個專家。

如果程序員以代碼行數(shù)領(lǐng)工資會怎么樣？

1. 大括號是否需要另起一行的問題終于得到了有效的解決。畢竟，另一行可以賺更多的錢。不需要所有的標準庫、包和第三方庫，每個人都選擇重寫它們。像Babel這樣的轉(zhuǎn)碼器會增加函數(shù)并自動擴展程序，而不會影響語法和編譯

4。你會發(fā)現(xiàn)很多網(wǎng)頁無法打開的問題，因為程序員不斷增加網(wǎng)頁文件中的代碼

5。1t硬盤很容易用光。隨著代碼行數(shù)的增加，程序員的硬盤空間猛增

6。許多軟件公司破產(chǎn)是因為他們付不起錢。畢竟，程序員很難寫更少的代碼，但是寫更多的代碼不是很容易嗎？

7. 你不需要為語句和函數(shù)編寫代碼，只要自己編寫就可以了。匯編語言很受程序員的歡迎，而PHP不再是最好的語言了。生活是艱苦的，我用蟒蛇

10。許多程序員寫代碼就像我現(xiàn)在寫答案一樣。即使我想不出第十點，我也要想辦法算出

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)是個什么水平？

自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ǔ)，這是毋庸置疑的。

一個程序員的代碼編寫量，能否決定他的編程水平？

績效考核是對每個部門和員工工作數(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)略的有效性！