看到这个标题，很多程序员朋友会一脸尴尬，因为相当一部分程序员的公司没有这种开发流程。在一些公司，程序员开发的代码提交后会得到团队成员的称赞。只有被表扬后，经过组长审核，才能并入代码骨干。很多人觉得这个现象挺搞笑的。本来就是一份工作，怎么会像被朋友夸了一样？最近，一个华为员工发了一个类似的帖子。
这个华为员工的帖子标题是:“提交代码之前，有人来赞一下。哪个领导想出来的？”看这个标题，就说明这个网友对这个开发过程很不满意。从帖子的正文可以看出，这位华为员工把表扬的意思理解为“改善组织氛围”，那么真的像他理解的那样吗？在表达个人观点之前，我们先来看看其他网友怎么说！
网友1:还有一个规定:不能合并自己提交的代码。似乎有道理。有没有想过实际情况？一个微服务一个人写代码，还要查代码，真是扯淡！
作者:这位网友又抱怨其他规则，我就不多提了。直接看下一个。
网友:上有政策，下有对策。微信上有一个“点赞群”，我们可以在Espace上创建一个“代码点赞群”。
作者:显然，这位网友的做法是违背初衷的，说明他没有理解赞的用意。
网友:这不正常吗？
作者:是的，我很同意这位网友的说法，但我希望你能给我一个正常的理由。为什么没有下文？
网友:18级还看不懂这个机制要干什么？唉
作者:是的，很多人不了解这个机制，这个误解挺深的。
网友:去图书馆前还是要查的。旧代码不熟悉，新业务不精通，交付进度紧，容易出错。
点评:是的，如果你对这个机制有透彻的理解，你就可以紧张有序的交付代码。
网友:赞有问题。
点评:一个不知道乱喷机理的群众。
网友:感觉楼主是个伪程序员，发现我这个南国先生再也混不下去了。
作者:没必要这么说。你可以和他适当沟通，也许你会理解。这可能是对这个机制的误解！
网友:想法很美，但现实是这种骨感的方法只适合环境宽松，业务压力不大的部门。对于一些想把RD人员当牲口的部门来说，纯粹是增加了大家的负担，因为没人有时间给你审核，你只能画个赞组，省了不少力气。董世孝闭门造车。
点评:我同意里面的一些观点。对于同一套机制，我们应该根据RD团队的情况重点实施，而不应该为了实施而实施！
下面是我个人的发展经历和体会。我来说说这个赞的用意。其实这个赞并不等同于朋友圈的赞。是很严肃的行为，就像你的请假条上领导签的字。点这个赞有两层意思。首先，它意味着你已经阅读了这段代码。其次，这意味着您看不到这段代码有任何问题。如果有问题，你需要评论这段代码的问题，而不是表扬它。在我之前的公司，一般RD的人员在提交代码后都要邀请这个项目组的成员来表扬。表扬这种行为不是很随意。至少，如果你不得不看了代码，发现没有问题，你不看代码，还称赞它，这是一种非常不负责任的行为。如果代码出现了明显的错误，但你却表扬了，那么被表扬的人在领导中的印象就会大打折扣。这种赞机制就是鼓励大家去查这个人的代码。毕竟多双眼睛多份安全。最后，RD团队领导在审查代码时会查看表扬情况。如果项目组所有人都喜欢，说明项目组所有人都查过这个代码，他心里会有数。他会做一个简单的检查，然后合并这段代码。只有这个机制后的合并代码才有保障，你说呢？
大家好，我是“上辈子是朵花”。有什么好的见解或看法，可以在评论区一展身手，互动交流。如果你想更了解我，那就关注我吧！
