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

[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。你会被无敌产品逻辑坑的屎都不知道怎么屎的