分享一个我判断程序员代码实力的方法

[baskice]

根据我的观察，程序员的实力可以根据 代码量：bugs 数量 的增长函数来鉴别。

刚入门的新人通常在代码量较少时 bugs 的数量也少，但当项目复杂程度增长后 bug 数量会指数式爆发增长
（团队没有培养能力的话尽可能不要招这个水平还自身没有很强学习动力的人）

普通水平的程序员自己写代码时 bugs 数量和代码量呈稳定线性增长趋势
（合作项目就难说了，更看管理者合作能力好不好）（这个程度薪水已经能够保证了，但替代性依旧很强，老板可能一言不合炒人）

高级程序员 bug 量几乎不随代码量增长而增长。到这个阶段如果还有一定管理能力，脑子正常的老板已经不敢随意开除了。



代码量 /bug 比可以从 GitHub 的公开项目获得。当然这种鉴别方法也可以对抗，比如新人尽量不写复杂大项目以期混入普通程序员中。
或者干脆不给 GitHub 这些过往代码给你看。只靠面试看走眼的几率还是很高的。

[jedrek]

除此之外，还有性能指标

[voocel]

感觉有些道理

[hjc4869]

too young

[ZhaoMiing]

简单说就是架构能力

[fcka]

github 不可信，面试更可信。

[xujinkai]

架构能力... 有人讲讲这方面能力怎么提高么，除了多写代码

[df4VW]

@xujinkai 学习成熟的框架的做法和他们背后的哲学，这也是 react 的 flux 构架现在这么火的原因之一。好的框架和设计思路最大限度的帮助了你去避免和减少一些不该有的错误

[corona]

对前端来说，组件化开发也是一个判断条件，组件化封装的好，可以很大程度上减少问题的产生

[mcfog]

这个指标到中级以上就没意义了吧。中高级慢慢开始承担的职责无论是架构设计 /优化也好，业务建模 /分析也好，进度拆分 /预估 /分配也好，还有团队管理啊研发质量提升啊，运维体系建设啊等等等等都很难通过 bug 体现的。说这个指标就是架构能力的我无法赞同，研发质量问题和架构问题根本不在一个维度上

[yidinghe]

这个。。。前提是有足够的代码量和关注量和 issue 量可供参考。就算是公司内的代码，也必须在公司待足够长的时间。我猜不到 20%的程序员适用这种方法。我希望半小时内能看出任何一个刚见面的程序员的大致水平。

[darklowly]

@mcfog 完全赞成，
我从 20 岁开始，写代码 BUG 率就非常低。
但是很明显，我 20 岁的时候，不懂架构。
只是写的更用心，更仔细而已。

[k9982874]

现在这年头能把设计模式说明白的就是好程序员

[facetest]

lz 你觉 dos 的 bug 多，还是 win95 的 bug 多？

[whileFalse]

你怎么判断 bug 数呢。

[liyu4]

全宇宙我 bug 最多

[HarrisonZ]

一个要求，实践 TDD

[Sanko]

哎，整天写 bug

[mrsatangel]

bug 大王瑟瑟发抖

[Lucups]

对于编码实力这事，我觉得单指标的衡量标准肯定不靠谱。。。

我觉得一个程序员的编码实力至少跟以下属性 /能力相关：
1. 技术视野，在遇到问题时能够快速定位问题;
2. 搜索能力，能够快速找到想要的资料；
3. 英语能力，毕竟很多新东西首先出来的都是英文版；
4. 手速；
5. 等等等。

还是需要一个综合的打分，光看 bug 率肯定不靠谱，毕竟项目与项目之间差异太大。

[sampeng]

光看 bug。你会被无敌产品逻辑坑的屎都不知道怎么屎的

[ThatIsFine]

@Lucups 你是个程序员?你确定吗?

[Lucups]

@ThatIsFine 我是产品经理，谢谢。

[JacksonBond]

自以为是曹操，其实是蒋干

[woshixiaohao1982]

@k9982874 #12 一言以蔽之 隔离变化

[woshixiaohao1982]

@k9982874 #12 设计模式本身其实是次要的，不懂业务 对需求分析没有前瞻性，就算你把设计模式背得滚管烂熟 依旧毫无用途

[hellojl]

看变量名，看方法复杂度，可复用程度等等，才能看出代码实力吧

[k9982874]

@woshixiaohao1982 设计模式是对编程方法的总结。你所说的需求分析前瞻性，都是经验的总结，都可以归结到设计模式中来，并非主次要的关系。

嘴上说会做分析，做过无数项目的开发，不可能不懂设计模式，即使说不出专有名词，也会讲清自己所设计的模式。

反之设计模式背得滚瓜烂熟没有实际项目经验，让他说一下怎么把设计模式应用到项目中，举个具体用例，绝对说的吞吞吐吐。

高下立判。

看你用户名也是老程序，不应该理解不了。

[ThatIsFine]

@Lucups 所以你不知道如何判别真正好的程序员

[TuSDK]

@hjc4869 too simple

[woshixiaohao1982]

@k9982874 #27 所以功夫在诗外嘛，发现变化 创建抽象才是重点

[leekafai]

bug 是指
达不到程序开发者的预期
还是
达不到 pm 或者老板的预期

[Lucups]

@ThatIsFine 那你来教教我怎么判别真正好的程序员？

急，在线等。

[GuuJiang]

自从公司实施了这个考核标准以后，我一行代码不写，bug 量始终保持零，稳居全公司实力第一

[ThatIsFine]

@Lucups 写程序不是玩星际, 手速快慢不能作为程序员优秀与否的评判标准之一. 你提的其他的点, 也不多说.

工作中偶尔遇到同事用大量代码解决一个小问题, 代码很快敲好入库, 而引起其他的大问题. 而交给经验丰富的同事却只用了几行代码.

同样的, 有的同事因为找不到根本原因而引入大量代码来规避问题, 而这个问题在几个同事轮番规避后未果. 大量无用的修改投入. 最后却只是一个"||" 前后调换一下顺序解决.

其实楼主说的很对, 如果 1000 行只有两三个 BUG, 这样的一般都比较优秀. 不过还是要看解决的问题难易程度.

估计非技术出身的 PM 也不好理解程序好在哪里, 只能看谁在在当前开发及解决问题的效率.所以就说这么多.

[solomaster]

曾经以前公司有一个牛人做的总是复杂的项目，另一个水货懒人分到的大概率总是简单的项目。结果懒人做的又快又好，牛人的 bug 比懒人还多。这个你怎么算？只有我们程序员知道自己的东西难度系数。别人是不知道的，甚至有时候脱离一线的领导都不知道。
还有，不同的 bug 性质不一样，比如这懒人出个问题，都是比较严重的 bug。牛人出的 bug 都是小问题。这个又怎么算？

[solomaster]

两人写同样的东西，然后比 bug 数，这样当然是可以判断程序员水平的。但不是全部。新手程序员可以通过很臃肿的代码来规避很多出问题的地方，而老手反而可能试图用复杂的设计方案反而更有概率出问题。
任何通过某个数据的方式来判断程序员水平都不正确的。判断程序员真实实力是需要一个长期的过程，通过不断的产出来综合判断。你和一个人共事久了，自然之道。

另外提一个观点，欢迎拍砖：任何可用物质系统或者可用虚拟系统，其出 bug 的机率跟系统复杂度成正比例相关，不会因为参与者水平引起巨大的波动。因为可用系统复杂到一定程度，自然会淘汰低于此系统水平的程序员。也就是说，能参与这个程度系统的程序员本身就是满足一定水平条件的，不满足的自然根本参与不进来。

[Lucups]

@ThatIsFine

看你写了这么多字，最终还是没有回答 『怎么判别真正好的程序员』这个问题啊。

另外，我说手速是『编码实力』之一有什么问题？相同条件的两个人，一个手速快，一个手速慢，手快的自然有优势啊。你一指禅比得过人家十个手指头？

[ThatIsFine]

@Lucups 你没看明白, 我的意思就是懒得和你解释吗?你真的是"产品经理"?

[wangjxxx]

手速我只符 eclipse+vim

[Lucups]

@ThatIsFine 撕不过开始耍赖啦？ 哈哈哈！本来这个话题就是娱乐娱乐而已，你非要认真。我跟你认真起来你又开始耍赖，没意思。

[fumichael]

根据我的观察，只招高级程序员就可以了。

[ThatIsFine]

@Lucups "估计非技术出身的 PM 也不好理解程序好在哪里, 只能看谁在在当前开发及解决问题的效率"
这句话的意思就是说了你也看不懂.

前面两个例子就是两个手速一般的, 年年拿 A 的同事. 你看懂了吗?

[loveCoding]

看他研究源码 , 对于大多数人来说 , 要想提高提高代码水平, 悟是悟不出来的 , 唯手熟尔.

[Lucups]

@ThatIsFine

既然你回应了，我不回你也不礼貌。下面开撕。

我说手速一般就不是好程序员了吗？我一开始就强调 『单指标的衡量标准肯定不靠谱』，然后提出了几个指标。你一上来就拿手速说事，其他三项又不说为什么不合理，难道这方面被人伤过？这么敏感？你也说『只能看谁在在当前开发及解决问题的效率』， 你也知道 『效率』二字，手速难道不是『效率』的一种体现吗？虽然成效低，但苍蝇也是肉啊。

你的这句『 你提的其他的点, 也不多说. 』太过于嚣张，如果是新手，我原谅你，毕竟人人都傻逼过；如果是小马甲，那请不要回避这个问题，请阐述一下我提的其他的点哪里不对。

最后你问我 『看懂了吗?』，我当然懂你的话，我只是不懂你为什么回答了一句废话。

用我最初的回复来表达就是：
因为某人
1. 技术视野（广），在遇到问题时能够快速定位问题;
2. 搜索能力（强），能够快速找到想要的资料；
3. 英语能力（强），毕竟很多新东西首先出来的都是英文版；
4. 手速（快）
5. 等等等
所以他 （『开发及解决问题的效率』高，）是一个好程序员。

用你的表达就是：
因为『开发及解决问题的效率』高，所以是一个好程序员。

谁不知道『开发及解决问题的效率』高的程序员是好程序员？这个是结论，不是条件。
你自己逻辑混乱，不说你的条件也就罢了，还来嘲讽我，是小马甲给了你勇气吗？

[Lucups]

@ThatIsFine
Sorry，撕逼心切，最后的回复看错了。下面重新撕。



以下省略 500 字。。。



哎，我真无聊。不撕了。跟一个小马甲较什么劲。。。

[hellojl]

@Lucups 问的是代码实力，你说的这些，跟我作为一个程序员理解的“代码实力”不一样

[robinlovemaggie]

@fcka 购物历史含女装更可信[沉思状]~~

[Erskine]

正在写 bug 的我看到楼主的帖子后，双手离开键盘，拿起了手机

[tagtag]

确实最好的方法就是使用一个结构标准且严格的框架，越灵活的编码方式对程序员的能力要求越高。

[v2666]

感觉老板不关心这些

[Adia]

其实一个项目的架构好不好也会影响 bug 的数量

[darklowly]

@solomaster 好的程序员会化简，既不会用复杂的实现，也不会用复杂的设计，写出来的代码是很简单的，明显没有错误的，而不是没有明显错误

[JamesR]

我写的代码，大约一半都是为了预防各种意外以及 Bug 的。
初级程序员为了省事略掉这部分代码，后期肯定问题会浮出来，“高级程序员 bug 量几乎不随代码量增长而增长”有一定道理的。

[ThatIsFine]

@Lucups 你可以从我的回帖记录发现并非马甲, 看了你的长回复,着急

[Romanticlizhi]

谁不是从初级菜鸟慢慢过渡到高级的，说这个有意思吗，说的像有人一出生就是高级大神一样

[RorschachZZZ]

1 理解能力 2 沟通能力 3 解决问题速度 4 代码性能 5 代码拓展性 6 代码复用率

[darklowly]

@Lucups 你的前几点，都是很外行的说法，因为很空洞，你把前三点的，换成任何一个工种，都是适用的，所以是没有落地的套话。最后一点，手速完全没用，只要不是霍金，正常人的手速，都不是瓶颈。什么苍蝇再小也是肉，是在胡扯，一个产品经理，抓不住重点，毫无作用的细枝末节，却.....

[andy009]

github 是可以伪造的，无论在哪间公司都有极端的例子，有些人甚至能凭借着能说会道的忽悠能力来升级。
说到程序员的不可替代性，最好重复开发轮子，让公司离不开自己的轮子。
一个小时，你跟任何程序员聊一些工作上的细节，都摸清他的实力了。

[cbangchenLL7]

@Lucups 快速定位问题的能力，与技术的深度关系大一点。手速应该和编程的能力完全无关。搜索和英语能力是一个人的综合能力，是有关的。对于你单指标的衡量标准不够客观这个还是同意的。

[Lucups]

@cbangchenLL7

没想到这个帖子还有人回复...

看到很多人反对我的这个手速观点，我理解你们的意思。
我的意思并非说手速越快编程能力越强——我想说的是，你们一定没见过用两根食指敲键盘的程序员。

[cbangchenLL7]

@Lucups 我都没注意这个帖子日期这么旧了。其实我只是想说你说的大部分是对的。