程序员的-多做多错，少做少错，不做不错

#欢迎光临我的随便说

记得多年前公司里一个大项目出了重大问题，大领导震怒，于是我们一帮子leader被分配去各个组做check review。

重灾区是一个财务模块，据说这个模块是整个项目最难、最复杂的模块，用到了各种各样的非常复杂的算法，负责人和开发人员天天加班，既要赶工又要修bug，每天忙得人仰马翻，而且后来因为出了严重bug而受到领导批评，以及一帮子领导的特殊关照。

我check的是一个比较简单的小组，整个小组任务按时完成，没有bug，我经常在5点半左右过去check，发现有时候我过去时他们当天的任务已经全部完成，都在等下班，整个组很是和谐。

后来到了年终评价，据说我check的小组的领导升职了，小组里也有好几个人升职加薪比其他组要好，而最差的就是财务模块的小组，甚至有人离开了。

说实话，我check的小组，我认为管理及小组成员都很不错，他们的任务清晰明确，每个人也都各司其职，也许他们的内容也确实是相对简单的，但是我也见过简单却一团糟的项目。那时我也曾经短暂支持过另一个小组的check，每次我都是最后check那个小组，但是每次到时，他们的任务列表都没有弄，有时候我到了，组长才开始填内容，有的说的不清楚，细问时责任人一脸懵的状态。

但是，不同组难度及工作量是不同的，不同的人负责的内容难度及工作量也是不同的，越是难的东西越是容易出问题，负责的工作越多，出现的问题自然也就越多，所以那时很多人都觉得财务小组的人很冤枉，做得最多，却得到的最少。

后来公司里开始出现了多做多错，少做少错，不做不错的声音。

其实换位思考一下，我也会觉得很冤枉，很憋屈，很郁闷，但是，世间很多事都是以结果为导向的，出了问题就要承担后果，没有人会去关心你们为什么会出问题，反而可能会怪罪你在遇到困难时为何不事先解决，虽然你可能会在心里想“马后炮，我事先提出问题时你们支持解决了吗？”

但是如果因此就把“多做多错，少做少错，不做不错”作为至理名言，我认为那恐怕就真的大错特错了。虽然多做多错了，可能有时候还会因此损失一些什么，但是，多做就意味着你多学会了更多东西，就意味着你随着时间的积累，能够获得比别人多得多的知识与能力，那么你也就有了上升的资本，而那个不做不错的人，到了某个时候，也要付出代价。

当然，我这里也不是支持什么事情都抢着做，或者去默默做了别人该做的事情，多做是针对我们该做的事情，我们应该认真对待，不该我们做得，就还是该谁做谁做去吧。

推荐文章
10 分钟教会你 Spring Boot 集成 Thymeleaf、MyBatis 完成产品的增删改查

【高阶用法】一个实例学会 Spring Cloud 的注册中心 Eureka的使用

Spring Cloud gateway与注册中心Eureka的完美集成