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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 2681 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

程序员

代码

Bugs

代码量

61 条回复 • 2019-10-30 18:53:13 +08:00

jedrek

2017-08-22 01:34:44 +08:00

除此之外，还有性能指标

voocel

2017-08-22 01:36:50 +08:00 via Android

感觉有些道理

hjc4869

2017-08-22 01:44:48 +08:00 via Android

too young

ZhaoMiing

2017-08-22 01:45:49 +08:00

简单说就是架构能力

fcka

2017-08-22 01:53:41 +08:00 via Android

github 不可信，面试更可信。

xujinkai

2017-08-22 04:49:42 +08:00 via Android

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

df4VW

2017-08-22 04:54:45 +08:00

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

corona

2017-08-22 07:33:54 +08:00 via iPhone

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

mcfog

2017-08-22 07:46:20 +08:00 via Android

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

yidinghe

2017-08-22 07:58:12 +08:00 via Android

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

darklowly

2017-08-22 08:00:42 +08:00

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

k9982874

2017-08-22 08:09:10 +08:00 via iPad

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

facetest

2017-08-22 08:58:15 +08:00 via Android

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

whileFalse

2017-08-22 09:23:45 +08:00

你怎么判断 bug 数呢。

liyu4

2017-08-22 09:41:40 +08:00

全宇宙我 bug 最多

HarrisonZ

2017-08-22 10:00:23 +08:00

一个要求，实践 TDD

Sanko

2017-08-22 10:01:42 +08:00 via Android

哎，整天写 bug

mrsatangel

2017-08-22 10:02:45 +08:00

bug 大王瑟瑟发抖

Lucups

2017-08-22 10:16:27 +08:00

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

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

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

sampeng

2017-08-22 10:47:00 +08:00

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

ThatIsFine

2017-08-22 11:30:50 +08:00

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

Lucups

2017-08-22 12:40:23 +08:00

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

JacksonBond

2017-08-22 13:04:38 +08:00

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

woshixiaohao1982

2017-08-22 13:05:16 +08:00

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

woshixiaohao1982

2017-08-22 13:06:57 +08:00

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

hellojl

2017-08-22 13:28:19 +08:00

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

k9982874

2017-08-22 13:35:57 +08:00

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

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

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

高下立判。

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

ThatIsFine

2017-08-22 13:43:14 +08:00

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

TuSDK

2017-08-22 13:46:40 +08:00

@hjc4869 too simple

woshixiaohao1982

2017-08-22 13:49:57 +08:00

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

leekafai

2017-08-22 14:17:43 +08:00 via Android

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

Lucups

2017-08-22 14:57:17 +08:00

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

急，在线等。

GuuJiang

2017-08-22 15:29:19 +08:00 via iPhone

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

ThatIsFine

2017-08-22 15:39:16 +08:00

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

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

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

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

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

solomaster

2017-08-22 15:50:11 +08:00

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

solomaster

2017-08-22 15:59:09 +08:00

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

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

Lucups

2017-08-22 16:21:40 +08:00

@ThatIsFine

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

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

ThatIsFine

2017-08-22 16:31:13 +08:00

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

wangjxxx

2017-08-22 16:38:50 +08:00

手速我只符 eclipse+vim

Lucups

2017-08-22 16:40:58 +08:00

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

fumichael

2017-08-22 16:48:42 +08:00

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

ThatIsFine

2017-08-22 16:52:13 +08:00

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

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

loveCoding

2017-08-22 17:28:15 +08:00

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

Lucups

2017-08-22 17:39:56 +08:00

@ThatIsFine

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

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

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

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

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

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

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

Lucups

2017-08-22 17:46:55 +08:00

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

以下省略 500 字。。。

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

hellojl

2017-08-22 17:54:58 +08:00

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