聚合全网技术文章，根据你的阅读喜好进行个性推荐
来衡量一个程序员工作量， 按照代码量、质量啥的，舍弃，早几年都验证是搞笑的
还有别的稍微合理点的办法吗？
RMB
这类问题，说实话，无解！
一般来说是能完成合理工作量的工作就好了，如果这都不算完成任务，希望贵司程序员早日脱离苦海。
软件开发是艺术，真没啥好法儿量化
非得量化，那就代码行数充数，不求效果
像Scrum的点数，如果团队时间够长，开发进度稳定，可以用来评估产出，但是也只是一个参考指标。不是绝对指标。
任何开发团队，搞KPI指标，从实际实施结果来说，都是作死。
没有很好的方案评估，但大家都知道谁厉害，谁不行。
比如按照代码量算的话，我之前一个同事，写的东西全是废代码，他离职后审查他写的模块，完全不符合需求，全部干掉重写的。
按照bug来说的话，测试老是找我改bug，每次一看bug都不是我写的，产品演示的时候，风风火火解决问题的那个人很大概率是写bug多的人，然后看起来他天天忙的要死，而有的人却闲的不行，实际是写的代码问题太多，偶尔还要加班才能解决。
比较合理的我还是觉得需求评审，大家都对一个需求评估时间，有的人评估2天，有的人评估6天，最后大家投票表决，每次让要时间最长和时间最短的人说出自己的理由，最终达成一个合理的需求完成时间，然后对每个需求得出一个难易度或耗时的表格，最后大家认领需求，做的几次大家都知道了技术的高低，项目离开了谁不能跑，项目的核心是谁再做，完全评估是不可能的也不现实，让高级的去做简单的增删改查也是一种浪费
呆在在工位的时长-离开工位的次数/代码的行数
这是那个城市，属于几线呢？
这个真不好衡量,每次年终总结,写出这一年完成的工作和任务,基本上领导(懂技术的)就清楚了
提问的人更搞笑。
你说一个方法不好，同时你又说不出另一个更好的办法，那么，你就没有资格说之前哪个方法不好。
RMB
这类问题，说实话，无解！
一般来说是能完成合理工作量的工作就好了，如果这都不算完成任务，希望贵司程序员早日脱离苦海。
软件开发是艺术，真没啥好法儿量化
非得量化，那就代码行数充数，不求效果
像Scrum的点数，如果团队时间够长，开发进度稳定，可以用来评估产出，但是也只是一个参考指标。不是绝对指标。
任何开发团队，搞KPI指标，从实际实施结果来说，都是作死。
没有很好的方案评估，但大家都知道谁厉害，谁不行。
比如按照代码量算的话，我之前一个同事，写的东西全是废代码，他离职后审查他写的模块，完全不符合需求，全部干掉重写的。
按照bug来说的话，测试老是找我改bug，每次一看bug都不是我写的，产品演示的时候，风风火火解决问题的那个人很大概率是写bug多的人，然后看起来他天天忙的要死，而有的人却闲的不行，实际是写的代码问题太多，偶尔还要加班才能解决。
比较合理的我还是觉得需求评审，大家都对一个需求评估时间，有的人评估2天，有的人评估6天，最后大家投票表决，每次让要时间最长和时间最短的人说出自己的理由，最终达成一个合理的需求完成时间，然后对每个需求得出一个难易度或耗时的表格，最后大家认领需求，做的几次大家都知道了技术的高低，项目离开了谁不能跑，项目的核心是谁再做，完全评估是不可能的也不现实，让高级的去做简单的增删改查也是一种浪费
呆在在工位的时长-离开工位的次数/代码的行数
这是那个城市，属于几线呢？
这个真不好衡量,每次年终总结,写出这一年完成的工作和任务,基本上领导(懂技术的)就清楚了
提问的人更搞笑。
你说一个方法不好，同时你又说不出另一个更好的办法，那么，你就没有资格说之前哪个方法不好。