陷于业务,无时间做基建和偿还技术债,怎么办?

做业务开发的二柱子每天陷入业务，没有时间做基建，没有时间偿还技术债，项目里充斥着大量的 if-else，改动一个地方就会牵一发而动全身，他很焦虑，觉得这种情况长期下去，对个人发展很不利，发愁出路在哪里？

为什么会这样？

如果是从别的团队交接过来的项目，遗留问题很多，确实很难改，为了不影响现有逻辑，很多人会采用新加接口、逻辑的方式支持新需求的接入，随着需求的不断接入，代码只会越来越臃肿，越难以维护，更别提基建了

如果不是交接过来的，而是自己从0到1起的项目，那可能做方案设计时，没有做好抽象，没有考虑到未来的扩展性，来个需求就做，改着改着，代码就变得难以维护了

毕竟业务方不关注开发如何实现，他们只要系统支持功能，但开发要考虑，开发不考虑就是给自己挖坑了

怎么破？

有的小伙伴可能会说：

业务做起来了，就有办法把债转嫁出去。业务做死了，债还不还也无所谓了。只要可以一直借新还旧维持住不暴雷即可。优先让业务活下去，才有个人发展的方向

好像也很现实，如果业务做死了，也就不用还了，如果做不死，只要能跑不出问题就跑去呗，业务活下去，再谈个人发展

但如果你有一定的代码洁癖或者每次写代码真的痛苦的很，又或者你比较在乎个人的成长，可能需要你多付出一些

一句话，谁痛谁改变

1. 明确问题：有什么影响，影响了效率还是影响了性能?
2. 明确目的：如果改了有哪些好处？开发效率更高了还是性能更好了?
3. 给出方案：打补丁还是重构系统，并简单想一下每种改造方案的改造成本，如果改造成本很高，是否可以分期实现

想好以上三点后，写个技术方案并找领导谈，正常的领导一般都会支持你搞，但是很现实的一点是，可能不会给你留出大片时间搞这个。可以找需求稀疏的时候做，也可以在需求间隙做，但也可能需要你加班，或占用你一些个人时间来做，怎么选还是看你，毕竟躺平还是挤时间的选择权在你

读到这里的你，是否有相同的困惑？或者你是怎么看待和解决这个问题的?
欢迎留言与大家一起讨论！