你的代码值多少钱

老板雇佣程序员来写代码，程序员的薪水是成本，产生的有效代码是产品。或者说老板从程序员那里买代码。程序员每写一行代码究竟能赚多少钱？不妨来推导一下。

我们规定程序员书写、重构、改bug产生的变化行数都算做生产行（Line），把所有生产行分为三个等级：框架（structure）、功能（feature）、逻辑（logic）；将程序员在单位时间内写的三类生产行分别设为L_s、L_f、L_l；每种生产行的权值分别为W_s、W_f、W_l。生产行失效率为P（0到1之间），失效的生产行指在老代码运行过若干次后被重构成了新的代码（在开发阶段快速迭代重构只计算最终的生产行不算失效）或者被验证有bug后改正的代码。则该程序员在单位时间内写的代码的价值为V_t = (L_s×W_s＋L_f×W_f＋L_l×W_l)；有效代码价值V_e = V_t×(1－P)。设该程序员单位时间内的薪水为S，进一步可以得到该程序员的性价比C = V_e / S。

 

公式只有这些，接下来随便假设一些数值代入公式做下计算。设有两个程序员：a（高级）、b（初级），假定a月薪5000，日代码价值50，（按22工作日计算，下同）月代码价值V_t(a) = 50×22 = 1100，则a的性价比为C(a) = V_t(a)×(1－P(a)) / S(a) = 1100×(1－P(a)) / 5000。同理可得b的性价比C(b) = V_t(b)×(1－P(b)) / S(b)。考虑理想情况，a、b的代码失效率都为0即P(a) = P(b) = 0，若要a、b程序员的性价比相同则有C(a) = 1100 / 5000 = V_t(b) / S(b) = C(b)；如果b的日有效代码价值25，月有效代码价值25×22 = 550，月薪2500，则刚好C(a) = C(b)，公司的薪资结构是平衡的。下面说一些你们可能有的问题和一些引申想法。

 

“我看到一些公司拿钱多职位高的写的代码量很少，贡献代码最多的是一些新人，性价比怎么会平衡？”代码行数不直接代表代码价值，这也是三种代码权值W存在的意义，写框架性的代码靠深厚的功底。框架、功能、逻辑的权值是依次递减的即W_s > W_f > W_l。项目初期高级程序员基本全部精力都在写底层框架而几乎不写上层应用，往往是每天想4个小时写2个小时再花2个小时重构，项目中后期在框架实在无事可做时高级程序员又往往在写功能、逻辑时贡献的代码量又是最多的。每天框架代码的生产量可能是很低的但是含金量很高，是整个项目存活与维持的基础。

“高级与初级程序员的性价比真的很理想化的相等吗？”不。理想化的性价比比在实验室里创建高温超导体还困难重重。原因在于很多不确定和随机因素。任何程序员都不可能一辈子一直写出滴水不漏不需要返工的高质量代码。上面的计算已经是把代码失效率当成理想的0来算的了，如果高级程序员更了解代码中的陷阱与欺骗从而能更好的避开，那就能写出失效率更低的代码，也就是说出错率高的新人要写更多的代码才能像高级程序员一样划算。

“行业薪资标准该怎么算？”在求职、入职与人事部门谈论薪资待遇时他们都会说：按掌握的行业统计数据给你的薪资为XXXX。这句话表面意思我非常理解，即行业薪资标准的建立需要大量统计数据。但我不知道各个公司是怎么统计与处理数据的。我想这么算一下：需要统计两样数据，程序员有效代码价值V_e，薪资数目S，这两样数据计算得到的就是上面推导过的性价比C = V_e / S。当有大量数据时我们可以得到性价比的一个行业平均值C_avg（如需做其它分析还要得到最大值、最小值、方差等）。在对一个程序员笔试面试过后可对其生产有效代码价值的能力做个初步评估，在此基础上可以给出该程序员的薪水，如果老板开给公司里大多数程序员的薪水过低，性价比高于C_avg则可能发生频繁跳槽与被挖角现象；如果开的薪水很高性价比过低，那也许能笼络到大量人才，但是那老板真有钱，还很阔绰。想稳稳当当就构建和C_avg持平的性价比即可。

“那身为老板，我为什么不全都雇佣性价比最好的高级程序员？”不可能也没好处。从业人员不可能每个人都有很到位的技术火候。如果老板雇到的全是最顶尖的程序大师却又安排不好这些人员那沟通与管理成本就会上升很多。一个高级程序员带队几个沟通顺畅的人（不管高级还是初级）那么做起事来会很有效率，如果是几个固执的高级程序员聚在一起吵来吵去那么生产效率还不如两个平庸的程序员加一个好的指导思想。此文只说和上面的公式相关的问题，公司内部的管理平衡本文不谈。

“怎样节省成本？”我一向吹嘘的两个程序开发原则是复杂度隔离和代码复用。降低了复杂度，代码阅读修改会变容易，扩展维护成本会变低；书写并使用能充分复用的代码也会减少repeat yourself的机会。发展与使用开源软件也是个好的方法。如果一个管理者成天摧程序团队把某某某功能做出来，那真的该反思一下这种只要尽快看到短期结果不求深谋远虑的施压造成的是什么情况：程序员赶工，效果是快速出来了，但代码经过推敲的时间少了，复杂性可能高了，潜藏的bug可能多了，以后复用的机会非常渺茫了……长远来讲，不如平心静气鼓励程序员写出高质量的可复用代码，使用、参与、投入几个开源项目，甚至鼓励程序员用一定自由时间做自己想写的程序（Google有此一招，每周一天，其若干商业项目起源于员工个人项目），这样公司的成本更低。假设一套代码（自己员工写的可复用代码或现成开源项目）有10万有效代码价值，还是按一个高级程序员1100月代码价值来算，在不出错的理想情况下这套代码可能为老板节省100000 / 1100 = 90.91人月的成本，5个高级程序员也要干18.19个月才能做出来，而老板能节省99.91×5000 = 45.45万元的金钱成本，又省时又省钱，何乐而不为？为什么不拿使用开源项目节省下来的开支给员工多加一些人性化的福利待遇？良好的企业文化不就这么出来了。我想大多数商业游戏引擎都出自国外的原因也就是因为他们不求短期山寨出能骗钱的游戏而是想安下心给程序员一定自由做出非常酷的程序出来，长远来讲，这些公司引领了行业标准，卖引擎就赚翻了。你还会一味盲目压进度吗。

“看你摆了这么一套，我很有收获或启发。我很认真！”认真你就输了！仅靠这种简单粗暴的公式就能量化出价值的程序员都不是将才！任何工程，说白了管理的不是项目而是人。而一个程序员最独特有力的价值可能不在实现某个功能写一篇代码上面，在于很多很杂，比如：能给团队带来什么样的提升，能在众人就某一问题困苦时灵感一现提出创造性的建议，人品极佳能协调好程序团队内外事务……

“身为程序员，我该怎样提高自我价值？”让自己写的代码不容易出错，让自己能从只会写简单代码的初级程序员上升为火候更到位的高级程序员……今天累了，改天再谈。