关于Gerrit的疑虑

正在搭建用于code reviewe平台。

多年项目经理的经历，让我事事都反复考虑目的的合理性。

项目经理，往往只需要实现项目目标，但作为需求组一员，也有权力对需求的合理性提出质疑。尽管绝大多数时候，不会，只去执行就是了。

代码审查，这是一件事，意味着有主语，就是一个人对另一个人审查。

这里暗示这位专家，更加有经验。成本也更高，但是这种成本和低效是否是有意义的？是否有利于提升用户的满意度？

所以，这里有一个关键的问题：我们每个人做事，最终的目标是为了代码的好看吗？

虽然这件事，有许多合理的理由，但实际在执行中，是站不住脚的。

因为最终的目标是需求，是用户，是让用户掏钱。不是什么代码的整洁性。因为一名合格的程序员，写出整洁的代码是其天职，这种事情也要人来监督，这个公司管理成本有多高呢？这种管理成本能反映在为用户实现的需求上吗？

--------------------------------------

所以，带着这些问题，我联系了之前的几个已去互联网公司的徒弟，证实了我的观点：他们不做review.

我要开公司也肯定不会。除了效率，我认为，出了问题，是专家的责任还是员工的？我最不能容忍的是推锅，但在工作中，这种事情天天时时刻刻要面对。这没什么好玩的，能把一个项目拖黄，我发现，只要没有用户参与，每个员工推锅才是最大的任务。不求有功，但求无过嘛。

他说原因是因为版本升级速度太快，没有时间来review。之前也有的。

在我看来，他只是说了现象。他的意思是，由于这种现象，他的公司，不得不这样。

但我认为，本质也是必须要这样。

那些正在走下坡路的传统公司，问题出在哪里呢？他们还是更加尊从于权威式的金子塔管理体系，而不注重用户需求，不从流程上就要求程序员直接向用户负责。有人审核，他就有处推锅。波音，IBM等等这些老牌子公司，正在走向末落。不可不察。
--------------------------------------

另外，年前的CICD开发，我发现一个基本问题，就是什么是CICD，为什么要CICD.

可能DevOps更加准确。

CICD的发起者是一名普通的研发人员，这次push的发起，是由于某个任务，如bug或cr，那么，他本人而言，就理所应当地应当全面负责。

这是一个基本任务。

当然，还没开始，就会遇到许多困难。一些不合格的管理者，会想出两种可能办法：

1。 片面要求员工能力超强，能够全流程保证从分析，设计，编码，测试，提交，所有过程的完美与合规。片面要求员工能解决一切问题（还好我们现在的领导不是这种人）。这种逻辑，稍思考一下，就发现是不对的。因为员工的成本会很高，而且员工们的心理压力也一直会非常大，很快他就会走人。

2。 请来专家，做审核。注意，是审核，而不是帮员工解决问题。结果也很不好。专家往往不能了解所有的需求带来的问题，某一方面他是专家，但另一方面他不是。专家的专字，绝不是在用户的需求上，而是在技能上，这对于项目来讲，是不好的，非常不好的。不说是灾难性的，也差不多。因为只有那些天天面对具体需求的一线人员，最清楚是怎么回事。

当然，反方的人，可以列出一大堆问题，你这么说，是不是又要说扁平化？是不是要屁股决定脑袋？员工们各自为政，是不是会变成一盘散沙？

这是另一个问题，是你公司是否建成了良好的系统，就象人体一样，每个细胞是很自由，但它是在系统中的一个具体位置。

作为管理者，不能忘了这一点：系统是前提，不是员工的职责范围。

------------------------------

那么解决方案是什么？我是指在员工的角度。

我们需要开发一系列帮助员工的工具。这是本文的要点。

之前我开发CICD的过程，发现，如果平台的测试过程，能够保证需求的完备性，那么开发者提交后，就不需要管理，因为系统会帮他测试，测试所有的需求点，是否符合预期。

所以，与其投入巨大在研发方面，不如投入到如何将需求落实到测试。

这是我非常认同公司现在的思路的地方——投入大量人力，整理测试的体系。

-------------------------------------------

这样一来，开发者，改完码后，可以毫无压力的提交。平台会自动对他的任务进行测试，如果测不过，也只有他自己知道，他自己负责，这很好。好在： 1＞ 提交后不用管：launch-and-leave。好处是，开发者，提交后，立即可以去关注下一下问题了。2＞ 开发者压力小，这点很重要。很重要。3＞ 没有占用管理者或者专家的时间。这显然是好事。4。 一切以用户的需求为目标。

也就是实现第三方管理。用户可是不会打折扣的，他可不会接受自己不想接受的事情，这是最好的管理，因为不花钱。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

当然，凡事都有不好的一面。

有人说，cicd与自动测试不同， cicd是在开发者自己的分支上，一切OK后，才会归并。这是好事，因为整 个开发过程，开发者是没有可能往外推锅的。自然负任人，跑者跑不掉（管理体系总是很关注这一点，责任的唯一性，如果不能确定，就得占用管理体系的管理成本，可能会很高ou）。

但是，但是，如果merge到主分支，再出现编不过，测试出问题的情况怎么办呢？

这是一个要点。

我认为，归并后，要立即regression test，尽管可能成本很高，但这总比调动管理成本好。这样的好处是，一次merge一次regression,责任还是由自动化系统确定。

反反复复我啰嗦这么多，一方面，是说cicd是对的，但管理者下放的权力，也无形中大大增加了每个具体的开发者的责任与负担，那么一名良好的管理者，更要注重如何为具体的开发者减负。

良好的管理者，永远都会把如何为最底层员工减负和开发提升效率的工具，为最公司的最最重要的要务。

没有第二个。

尽管大多数管理者完全没有意识到这一点。

因为，不论多么好的流程改进，如果在最底层无法持久地可执行，都是空谈。

再者，任何公司，普通员工是最多的，他们的能力和成本和效率，直接决定公司的生与死，而不是你雇拥什么超级CEO。

所以，如何开发有效工具，永远都是最重要的。

====================================

补充：在主分支的CI过程，不是DevOps是瞎胡搞。有人提到CI，就是买服务器，一次测试能解决的，就100测试，这种除了费电有什么用呢？一切的管理目标，就是为了保证负任分明，这个负任就是向用户负责。就是如此简单。

公司研发在主分支几百台服务器昼夜不停轮询测试，试问，这种测试有什么意义？测试用例是向用户负责吗？是否某个bug或CR负责吗？测出的问题，能自动指向相关的责任人吗？显然不能，发现的问题，还要发给相关的领导，这就是瞎搞。

没有向用户负责，没有帮助研发的员工，什么都没干，除了浪费了大量的运算资源。什么都没干。

====================================

总结一下：

1。 CICD是对的，因为在没有管理者参与的条件下，开发者自行向最终用户负责。不需要专家参与，不需要管理成本。

而且，由于工具的协助对象就是开发者，所以，开发者在CICD的条件下，责任更大，反而心理压力更小。因为有专门的团队开发测试系统，当然，如何保证测试系统自动向变化的需求适应，是另一个课题，我的工硕论文写的就是这个事情的一个方面。

2。 在此前提下，codereview是不需要的。尽管我现在正在建设这样的平台。