背景
由于Q2马上就要结束了，刚好抽点时间整理了一下这个季度做的需求，然后很尴尬的发现，技改一栏里面，没啥可填的，想了想好像这个季度的确没做啥技改需求，上一次说到技改相关的东西还是两个半月前跟产品提了一个快捷登录的功能，方便切换账号后不用重复手输账号密码，然后被产品问了一堆为什么后，绕到其他问题上了，这件事情也就逐渐被人遗忘，我们这里建需求必须由产品建，所以做啥事情必须先要让产品知道，但是技改需求往往会被产品贴上"没啥用"的标签，所以很难实施
这不是个例。其实回顾过去两年，我在别的公司也遇到类似的情况：技改需求被无限后置，或者直接消失 。上头的管理层大佬都很默契的遵循着一个原则：活下去比活得舒服更重要。经常会听到这样的争论，一方集中在产品，管理层，他们觉得：
技改是程序员的自我满足，所谓重构不过是把能跑的代码重写一遍，本质是浪费公司资源。
另一方则是我们这些程序员牛马：
不还技术债，代码到最后就不可维护了，到时候谁都没法交付
双方都有道理，但也都有点太绝对了，那么这篇文章讨论的话题来了：技改需求如今究竟该不该做？
说的技改需求到底是啥
讨论之前我们想一下什么样的需求可以称作技改需求，咱做个区分，个人观点，技改需求分为四种，而它们的投入产出是不一样的
架构升级
典型例子包括从MVP改到MVVM,从传统View改到Compose,模块化，组件化这样的需求，这样的需求往往要花的时间比较长，大概半年或者一年，之前在某金融公司，五个人搞组件化，花了一年才做完，这中间还好都意志坚定，不然很有可能半路就不做了，这也就是此类需求的最大风险，容易中途夭折
基建优化
最常见的有CI/CD提速，单元测试，搞监控告警这样的需求，相对上面的需求来讲，这些需求时间比较短，而且效果也能马上能看见，所以风险相对来讲比较小
代码洁癖
每个团队都有自己的代码规范，隔三差五都会要求检查一下自己的代码是否变量命名不规范、大小驼峰、三元表达式改if-else，这种需求几乎没啥收益，虽说没啥风险，但没啥必要去做
性能/稳定性
这个应该是做的最多的，比如ANR治理、内存优化、启动速度，这些需求都是可以量化显性的，虽然也有一定风险，改个ANR问题结果把一个偶现改成必现了，但是的确有投入人力的价值
综上所述，我觉得前两个需要做，像第三个代码洁癖可以顺手做但不要专门建需求做，现在很多团队都在代码提交的时候，用一个hook去检查代码是否规范，这个是比较正确的做法，最后一个可以放到业务开发中做。
为什么现在技改被砍成了常态？
上面我把常见技改需求分了类，可以看到不是所有技改需求都没意义的，有些还是值得做的，但是目前的行情下，为什么遇到看到技改需求被砍的例子呢
大环境不一样了
想想2020年之前，移动互联网处于扩张期。大厂的做法是：先做业务，欠债没问题，后面利用流量红利再慢慢还，是不是这样的？这是一个正向循环，业务增长带来的收益覆盖了技改的成本。
但是到了后面，大概在2022年之后，行情在那年开始逐渐变差，流量见顶，收入增长放缓甚至下降。之前靠业务增长覆盖成本的套路失效了。那个时候，当老板再次看到某个技改需求投入5个人花了3个月才做完，而带来的收益是代码可维护性提升30%，而不是老板想看到的收入提升30%，这种需求正常老板都想砍
很多技改确实没有产出
老实地说，如果回忆一下自己当初被砍的技改需求，自己摸着良心问问自己，该不该被砍
- 说是重构页面，其实就是把Activity改成Fragment，换个壳，里面逻辑照抄过来，技改需求是做好了，但实际没啥用，搞不好还会弄个线上crash出来
- 只是想练练手，比如想学Hilt,想学协程，把一些稳定的代码重新写一遍，把新框架引入进来，实实在在增加了其他开发伙伴的学习成本以及测试回归成本
- 无限扩张需求，开始只是想优化一下登录逻辑，最后去改底层存储结构了，越改捅出来的窟窿越大，上线后领导直接骂街
管理者开始懂技术衡量了
过去跟老板只要说上一些代码质量，架构合理性，可维护性这样的词汇，基本老板就点头同意了，现在越来越多管理者学会了看数据：
- 你说重构后维护成本降低，请给出具体降低了多少成本的数据
- 代码质量跟用户转化率，哪个比较重要？
- 这次重构预计减少多少线上ANR？具体到哪个场景？
当很多技改需求衡量标准从定性改到定量之后，很多技改估计提都不好意思提了，这个是好事，促使我们去做一些真正有意义的技改
今后的技改需求应该怎么做
技改是技术团队自己的事情，不用跟业务抢时间
就跟我上面举的例子一样，很多团队做技改？先跟产品提需求，跟业务需求抢排期资源。你是产品的话你怎么看，后面业务方天天催你呢，排期都不够用，怎么会在乎你那所谓的可维护性，可扩展性，不用衡量，技改天然就输了，公司的视角，业务需求KPI明确，技改KPI模糊，你抢不过的。
我认为正确的做法是：技改是技术团队内部的事情，就像我们家里定期打扫房间、每天固定时间铲猫屎一样，不需要跟外人申请
技改应该分期做，不要一次全做完
像我之前适配16kb的那个需求，总估时要26个人日，我也不是26天只做这个，我是拆分成好几个小需求，做一点测一点再上一点，这种分期的做法虽然慢，但是不会出现做到一半被叫停，或者一堆问题堆在一起最后被发现
AI时代的到来，需要重新定义技改需求
我们现在天天用AI开发，这对技改意味着什么？
好的方面
- 用AI写代码、写单元测试、写文档，可以提升技改效率
- 用AI重构，拆模块、迁移 API、改命名，这种以前人要花至少几天的事情，AI可以半天就做完
- 那些耗费大人力的活，有了AI提效，老板也就睁一只眼闭一只眼了
需要关注的方面
- AI生成的代码质量参差不齐，需要增加code review和测试的成本，也可能引入新的技术债
- 不要因为AI好用就大肆技改，不然上线了会有惊喜～
总的来说，AI让基建类和性能方面的技改需求，有了存活的空间
简单总结一下
职场人，为了每个月那几两碎银，何必做那么多吃力不讨好的事情，巧劲儿搬砖才是王道，以上都是个人观点，仅供参考，不喜勿喷