招考网站开发,cms模板网,友情链接交换统计表,wordpress 3.9 慢如何评价一个程序员是否优秀一直是一个很有争议的话题。
先说一个真实事件#xff0c;国际化项目#xff0c;最开始都是由产品经理在excel中管理翻译#xff0c;迭代过程中如有增删改#xff0c;就把增删改的部分标记出来#xff0c;提供给开发#xff0c;开发再对应更新…如何评价一个程序员是否优秀一直是一个很有争议的话题。
先说一个真实事件国际化项目最开始都是由产品经理在excel中管理翻译迭代过程中如有增删改就把增删改的部分标记出来提供给开发开发再对应更新多语言的资源文件。这个过程中需要产品与开发在中间倒一下手很容易出错和遗漏尤其是频繁更新时。为了方便对多语言翻译进行管理前端同学写了一个多语言管理后台取代了原先的exel表格主要具备两功能
产品经理可以先在test环境改改完提交就生效所见即所得。提供了同步到beta和prod环境的功能不需要每个环境都单独改免得又改的不一致。
前端让测试同学帮助测试并提点建议我提出几点建议
在提交和同步前增加确认环节提示本次增加修改删除的内容经提交人二次确认后再提交如有可能可以做成由第二个人审批同步到beta和prod环境时提供检测功能如果有未翻译的key提示风险或拒绝同步提供备份恢复或简单版本管理功能万一修改后的内容有问题可以快速加回滚
哈哈综合下来感觉越来越像一个配置中心了。
前端同学说你这么一来功能就复杂了啊我是不是还要做个用户管理和权限体系只有指定的用户有权限发布。后来又有后端开发加入讨论最终讨论的结果不谈。主要是中间我提到目前其他兄弟部门的多语言后台管理系统没有同步功能都是各个环境单独修改很容易遗漏导致线上有很多漏翻的问题于是测试同学为了保证多语言质量写了一个检查工具主动扫描线上的多语言资源文件发现了很多漏翻的问题极大的提高了测试效率保证了语言测试的质量。这个同学在完成提效OKR的同时也被提名微创新奖。如果你不实现这个同步功能就会面临和兄弟部门一样的风险那么就需要我去写一个工具来做这个检查反正不是开发做就是由测试来做。然后我想了一下开玩笑说“你还是不要做这个功能了留给我来做吧这样我的OKR上就有东西可以写了如果你把这些都做了不出问题了我的价值何在我只是在这里提了一个建议这个建议的价值或许与我做一个检查工具是等效的但是公司会因为这个建议而给我高的绩效分吗又有谁会知道我曾经提过这个建议”
虽然是一句玩笑话但却是说出了研发过程中的尴尬大家为了OKR为了有亮点有时候明明可做更好却要故意做的烂一点为后续改进留有余地。即使没有问题也要人为制造一点问题出来。如果一个产品线长期没有问题那么这个产品线也基本不需要人再维护了人员都可以优化掉了只有有问题才需要人去解决才会招人才会长期繁荣。从而推理出没有问题的产品不是好产品可不可笑尴不尴尬。
回到测试测试工程师的价值如何体现一个好的测试工程师是将问题扼杀在摇篮里还是事后写工具发现问题
回答当然是两者都有价值只是问题发现的阶段不同而已而且从软件开发项目管理理论上来说问题肯定是发现的越早越好。但是问题的关键在绩效评价上老板都希望用数据说话你说你做的好空口无凭可不行。然后提前发现问题提出建议是不容易被量化的而事后发现的问题bug数量线上故障数量是可以量化的。
说到这里我的结论是啥其实我是没有结论的只能感叹发现一个好的测试工程师真的很难发现千里马需要伯乐大家都说千里马难寻但也有可能是没有伯乐。
引申一下在可以量化的指标中很难通过某一个指标来体现一个程序员的好坏比如
以单位时间内的工作量代码量来区分单位时间写的代码越多就越优秀吗显然不是优秀程序员的十几行代码或许比一个普通程序员的几百行代码更高效。以交付时间同样的任务谁完成任务的快谁就更优秀或许吧但任务按时完成了并不代表代码的质量高和性能好对吧那以质量为指标呢或许是个不错的选择但是如何评价软件的质量呢又是一个头大的问题以bug数量来评价bug少的代码质量就一定高吗万一是测试没测出来呢或者有人代码写的少所以bug就少代码写的越多的人出bug的可能性就更大这样一来程序员都不写代码那也就没bug了是不是质量就最好了呢按照线上故障数如果是前人留下的坑呢你在别人的屎山代码上做的修改结果一上线就报错了你发现了前人留下来的隐患然后那个人早已不在这个公司了锅却留给你来背这时候你是不是想骂街有同学说同行评价啊按口碑这就是360度环评。唉这想法很不错但实践起来也是有很多不足之处。如果大家一团和气一起骗老板怎么办这恐怕是老板最不愿意看到的。另外有的程序员写代码不怎么样但天生会搞人际关系很会拉选票当然这不是贬低他可能适合做管理。而相当多的程序员大牛都非常有个性不希望被束缚所以在人际关系这方面不怎么上心结果就有可能在评比中吃亏。
综合下来评价一个程序员真的是很难要各个方面综合考虑而不能参考某一个指标。
