关于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是不需要的。尽管我现在正在建设这样的平台。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值