程序软件的版本发布也会导致内卷化? - GeePawHill

21-05-10 banq

由中央高智能部门协调和控制软件的大批量发布经常会失败,其原因是由于数学NP问题以及人类之间的弱相互影响。

大多数公司以某种命令和控制方法开始软件版本发布,这是一种中央智能组织推动和控制工作流程,批量大小为N的发布策略是问题所在。

 

首先是数学上行不通,像很多问题一样,我们可以使用N(在我们的案例中为故事总数,依赖项数量,受影响的模块数量,“合并冲突”的数量之和)作为这个问题的输入数量的粗略指标。随着N的增加,大多数问题都变得更难解决。

我们可以使用采用N的某种表达式来表达他们要付出多少努力。如果该表达式是多项式,则称为P问题。如果不是,则称为NP问题。

这个问题就变成了计算机中复杂性的问题:NP Complete问题(NP完全问题),就是说即使N的增加很少,也会使难度增加到惊人的大。

直觉是,可靠地交付批次大小为N的发行版的问题是NP complete(完全问题),这是一种软件的包装,是确切的。

人与机器始终以小N来解决NP完全问题的特定情况。关键:并不是每次实例都是不可解决的。确切地说,N的微小增加会迅速导致此类问题“在宇宙热死之前无法可靠地解决”。

“可靠地”这个词很重要。您会看到,在解决NP完全问题时,可以通过生成候选解决方案并进行尝试来实现。如果问题有解决方案,那么您可能会在第一次尝试时就找到它。

 

这使我想到了第二个令人着迷的方面:团队可以花很长时间*经历*这个问题的NP完全问题,而没有意识到它。在这场比赛中,我们成功了一段时间,也许十分之一。但是我们失败了十分之九。但是我们更容易记住成功:“我们*几乎*做到了!”

几个小小的发行问题并不难解决,但是我们花了几个小时疯狂地奔波,急于捆绑新发现的遗漏的API端点,重建我们的应用程序,然后重新部署它。或者,在糟糕的日子里,我们沮丧地流着泪回去。

我们每个回合都会遇到一个或两个问题?他们每次都是不同的小问题:例如忘记了此链接、没有打开功能标志、不知道该功能依赖于我们删除的字段,每次碰到的问题都是小的狗屎,但是不同的狗屎。

我们没有在问题中看到模式,因为它不是模式,而是元模式:由于组合函数抛出了太多细节供我们考虑,因此出现了问题。我们的N开始启动使我们的问题无法可靠地解决。

 

第三个令人着迷的方面:软件发布还经常运转顺利。这些偶然的胜利彻底使水变得浑浊,因为它们确实只是组合运气。但是他们使我们相信,*每次*都有可能幸运。

可以肯定的是,人们可以采取措施改善自己的运气。在游戏中,这称为作弊。在计算机科学中,这确实是非常聪明。但是你不能消除运气。它内置于我们解决NP完整问题的性质中。

 

内卷化

因此,当我们失败时,我们会做两件事:

  • 1)指责我们缺乏努力和意志,
  • 2)增加更多规则,门槛和检查。

“我们只是没有尽力而为。” “我们需要将其添加到我们要检查的事物列表中。”我们提高了发布活动的严肃性,确保每个人都知道真正尝试,花时间,认真思考,避免犯下愚蠢错误的重要性。我们变得,我在这里不是在开玩笑,非常*忧郁*,皱着眉头,若有所思地点头。

我们只有少数几个人,我们要求他们协调所有这些工作,并每次都坚持工作,直到发布完成为止。我们奖励他们,但我们也要求他们在高压力下长时间工作,要求他们英勇。我们升级了流程。有新的签收。有清单。通过通用的自动化代码质量系统有强制性通行证。有一个正式的滚动时间表,每个人都签署了每个任务。

奇怪的是,尽管这些调整旨在帮助我们控制N个批次,但它们往往具有使N变大的实际效果,因为现在它会将这些额外的过程元素合并到问题中。

提高严肃性和赌注以后,也加剧了紧张局势。我们越来越发展到以责备为中心(内卷化)。我们更加了解所谓的“长杆”政治,没有人愿意成为帐篷中的长杆。我们生气了。

 

所有这一切都在发生,因为我们的N已经增长到足以破坏我们的算法的程度。我们已经达到了一个问题的新的复杂层面,该问题太大了以至于无法解决。

我们已经隐式或显式地假设:1批10个的大小与10批每批大小1个是完全相同,甚至更少,但是NP完整性说那是不对的。批量大小为10的组合杀手会杀死我们。

 

发布关键技术

发布关键技术包括:

  • 1)pull & swarm:程序员拉取一个版本的源码,以该源码为中心,作为一个整体进行“交付”。我们使用整体编程,或成对,甚至只是坐在一起。一次一个故事,一路走过去。

  • 2)测试驱动的开发:在编写代码之前进行测试比在编写代码之后进行测试更快,更便宜。但事实是,它只有在测试代码编写完成后才更“有效”。这是我们自以为是的基本一线安全网。

  • 3)基于主干的开发:我们不使用复杂的源分支策略来驱动N。相反,我们从主干拉取代码,推向主干,从主干测试,从主干交付。

  • 4)注重路径的故事和代码设计:我们对故事和代码的设计不仅要着眼于最终的工作,还必须着重于它们可以被发布,而又仍然小到可以容纳它们的路径,这将涉及根本的风格变化。

  • 5)稳定且值得信赖的自动化:希望该过程的每个环节都能实现自动化。自动化需要坚如磐石,甚至比应用程序本身更坚固。必须对其进行维护并将其扩展到我们的最高水平。

这五种技术中的每一种都需要学习和实践,并且不能通过一道命令圣旨来立即开启其中的任何一种。我和其他人中的一些人已经撰写了广泛的文章,并提出了各种方法来迈出小步。

 

总结

随着N的增长,问题变得更加困难,以至于我们的所有进展都将停滞不前。这不是意志的失败,也不是规则的不足,而是简单的组合数学问题。

中央智能部门可以将某个NP完整问题的大批量发布发布到某个N,但不能超出此范围。否则它将会失败,更加频繁失败。对于成长中的组织而言,看到这一点并采取相应的措施是一项严峻的挑战。

 

1
猜你喜欢