这是一件很简单的小事情，但是我还是想记录一下，因为这两天上下班路上，我进行了很多的思考。
事情发生在一个业务项目中。最近有比较大的版本变动，业务工作量突然增大，于是我也承担了几个业务项目的开发。其中 A 项目已经进入了集成测试期了，这个项目在昨天晚上上线的。B 项目正在测试期中，C 项目正在开发联调中，还没有提测。其中 A 项目本来就比较坎坷，一开始评估的时候，没有评估客户端的工作量，后来发现需要客户端配合，我就临时接手这个项目了，接手的时候，只有 UI 的改动，用不了半天时间就搞定了，结果除了 UI 变动外，还有很多跳转啊，推送啊，断断续续投入了不止两三天的工作量进去。
所以由于这个项目进入开发前的一系列失误，导致后面很被动。特别是客户端，为了保证最后项目可以上线，只能挪用其他项目的时间来填补这个意外的工作量的洞。因为这些跳转啊，推送啊，会影响到具体的业务，我还是忍住了脾气配合完成了。但是到了昨天下午，当天晚上就发包上线了，测试单 Q 我，说有两个 UI 的小改动，问我好改吗，好改的话就改一下。然后被我直接拒绝了。我觉得这是我工作这么长时间来，少有的这样拒绝别人，稍微有点下不去手。
拒绝的原因其实有挺多的。
第一，我手头上有三个项目，我需要在不同的项目来回切换，确实很麻烦。针对我们现在项目的特点，这样的修改，加上找代码，编译，打包，运行，找测试环境，前前后后所有时间加起来，我大概估计这样的修改平均耗时得在一个小时左右。
第二，我平时不做业务项目，这样的修改可能只是一些纯 UI 上的变动，不会出其他问题。但是，万一呢，因为我确实不熟悉这些业务。万一改出个线上 bug 算谁的？本来是来帮忙分担些业务的工作量的，总不能帮倒忙吧～～
第三，提出这两个改动的时候，已经很晚了，集成测试都好几天了，为啥不早点说呢，进集成测试前又不是没有看到这个页面，为啥要在离最后发版的前几个小时来提这样的小改动。不管这是产品提出的，还是测试提出的，我觉得这都不算称职。别的业务方向都回归差不多了，你这个时候再发一个新的包，你让人家怎么办？重新测还是不重新测？重新测就得晚下班，不重新测就要信任你不出幺蛾子，人家凭什么信任你啊。
第四，我觉得我不能做老好人，形成习惯了，他们会变得越来越随意的，什么时候提改动都可以，不着急，只要还没上线就可以。从我个人来说，就是消耗我自己的时间，替别人擦屁股。从我们团队来说，我的小伙伴可能也经常碰见这样的问题，降低的是我们整个团队的效率。每个人需要为自己负责，每个团队也需要为自己团队负责。
所以，我会对我的团队要求，在进入集成期的代码，原则上是需要冻结起来的，制定这样一个小规则，然后去实践这个规则，约束自己，也约束别人。哪怕你手头上只有一个项目，哪怕你很闲，我也希望你把这个时间用在其他地方，不用在这个地方。
当然，这个小规则需要获得认同，当然，我觉得获得认同很容易。我相信的～～
- EOF -
本站文章除注明转载外，均为本站原创或编译。欢迎任何形式的转载，但请务必注明出处，尊重他人劳动。
转载请注明：文章转载自 Binkery 技术博客 [https://binkery.com]
本文标题： 昨天我拒绝了两个小改动
本文地址： https://binkery.com/archives/609.html