如何安全友善地优化本组Codebase?

大家好，我最近工作中遇到了一个疑惑，想听一下更有经验的网友们的见解。

context:
1. 楼主本身：从一家技术比较强的独角兽科技公司在职跳槽到某金融公司，目前在我司工作六个多月已经度过实习期。年轻人工作没几年所以入职时给了一个还可以的职位，尴尬地既不是junior也并没有到Senior。
2. 代码ownership: 所在的大组对于每个team ownership并没有明确的划分。
3. 代码审核：小组每次merge request 并没有严格的审核制度，基本上提交代码没有人详细review。
4. 测试成熟度：我们组并没有非常成熟的testing pipeline, 从dev 到 prod, release 过程中很多已有代码即使是重要的组件也并没有充分的于不同环境中的各种tests。
5. monitoring 详细度：我们组并没有非常详细的dashboard，很多科技公司检测的细节其实都没有被包括进去。每次上线新做的东西，楼主都非常紧张，同时因为4的原因，我们基本上monitoring 靠dependent 组的人或者内部用户反馈。

问题：
原来待过的公司有严格的code review，导致我现在看codebase 经常觉得有很多地方应该是最初被review的时候就挑出来而不是直接merge进去。
其实自己做project也比较忙，可是我觉得种种应该被优化的代码影响了我的效率，人为制造了很多complexity。楼主就很想顺手改。
所以这个问题更是，我该如何操作，又或者如何采取合理心态认知。

描述一下问题代码的类型与大小:
小型: 10-15行的问题或者一个method写200行为什么不分成好几个写增加可读性的问题, 这类问题非常多，我认为主要是因为2，3。
中型: 逻辑上不同旧代码层层堆积其实可以简化更容易也更清楚的问题，又或是一些class的结构性的问题。它们造成了一些模糊，不确定性以及难扩展的问题，其实是完全可以被修好的。
大型: 公司原本自己语言写在老旧编辑环境里和现在依赖它的代码库读取可以优化的问题，这个即使是一个email service，预估了一下，想要彻底分离旧与‘新’改起来也非常大非常麻烦。

问题代码主要作者来源如下：
a）一些前员工的遗留代码其实他们写的时候比较赶时间，肉眼可见的仓促，没有doc，没有注释，没有现有员工十分了解，理解这部分代码只能靠自己看它和debug。
b）也有一些属于现有老员工（老员工定义为5-7年+）的代码其实写的也比较着急，或者原本他们是学别的专业的并不是强计算机背景，但是人家已经升职为级别比较高的老板。
c) 还有一些代码是从另一个比较老的代码库migrate过来的，基本难以知道原作者是谁，很可能是待得时间最长的大老板噢～


我很想了解安全且友善地优化代码库的方法或者经验。
从技术方面，因为上述2-5，楼主担心自己改的东西能不能足够安全的bring the change i want。毕竟现在在我看来十分应该被优化的部分，其实只要人人都避开绕着走装看不见它的缺点，也是用了这么久没出什么大问题的。
从打造自己reputation的角度讲，精力也许应该在做新项目上，这样才能有impact, 对于升职有帮助，以后即使跳槽也能简历好看。很大精力改一个已有的东西，付出的努力根本没法讲难以量化啊。
从人际关系角度，对于a类authors根本没有人讨论到底这个地方是否有什么深意故意写成某种，也没有文档。对于b/c类authors, 就是不想得罪上级了，因为不知道对方是否会足够open mindset不介意后辈提出修改意见。
这几点看，优化已有代码库，似乎是个得不偿失的事，费时费力影响自己主要的精力投放地点，还可能会对上级评价有影响...

但是！看到一些地方它目前的已经存在的问题以及未来必然出现的问题, 我每天上班都有一种很强的ownership mindset 想要去改好!!!
我觉得这个代码库是我的，那我要维护好它，有不好的地方被我发现了我就要尽力把它修好，以后新加入的人也可以更加高效地添加的代码，总之它健康又快乐地成长我就高兴。
之前和大老板聊过他对大组的长期目标，其实我是buy the idea的，可是不尽早地解决问题代码大量存在的问题，怎么可能完成长期目标呢？
事实上我甚至认为我们需要现解决的是4，可是我对挖个深坑做observability没什么兴趣lols
就很着急==现有的seniors貌似对这些问题代码并不在意....我觉得这个可能也和2有关。而4，5 的缺乏更是让绝大多数人不敢动:p 毕竟人人都想升职加薪过得开心。

wdyt？可以是结合自己的经验如何操作，也可以是鼓励我或者劝我别这样做。
感谢大家的建议 : )
. 1point 3acres

感觉楼主是个很聪明，很有想法，也很take ownership的人，你们公司能招到你是你们公司的幸运😁

我接触过科技公司，也接触过各种大中小型的金融机构（主要是银行），我的感受是：很不一样。银行里大家更普遍的想法是live and let live，保住稳定的工作就好，做好自己被ask的份内事，所以很多根本性的改变很难推进，即使大家都知道这些改变长期来讲是对的。周围也会有很多各怀心思、一言难尽的队友和领导，做出很多本质上也没有大“错”但是各种细节问题质量很低无法scale的东西，然后交到你手上，根本原因还是技术和意识落后，短视，项目也没有足够的资源，大家被逼着在规定时间内deliver（金融机构现在都是勒紧裤腰带过日子，budget能省则省，一旦批下来很难改，如果做到一半发现做错了或者scope上需要扩张，基本没有回旋余地，只能硬着头皮糊弄过去）。当然到头来，像楼主说的，经过一番cover up, 这些东西还是work的，就像纽约的地铁，摇摇欲坠，哪里坏了加班修一下，倒也养活一帮人。如果一切都做到完美，自动化，代码清晰，那很多靠嘴皮子吃饭的人是不是就要失业了。

但是话说回来，我还是支持楼主在不overwelm自己的情况下去do the right thing的。首先这是个文化上top down的事情，楼主最好能找到跟自己想法一致、技术出身的同僚、领导，统一战线，春风化雨。然后像楼主自己说的，你要能证明impact，能showcase你的改进能带来怎么样的切实的好处，比如现状已经造成了多少的issue，cost了多少resource去修，简单讲就是画饼，往夸张了说，当然这点挺难的，很多impact很难具体化。可以挑一个相对容易改进且重要的模块做一个pilot。然后就是不管做了什么一定要有visibility 不要自己默默做了，改了，email了就完了，要follow up，要开会讨论，要check in大家force大家adopt。

这种codebase干起活来太痛苦了，看你们领导怎么说吧，有没有更重要的事儿让你做。不过如果别人依然是那个烂调调，你优化后估计很快又惨不忍睹了

建议lz和自己的老板、TL先讨论一下，有上面背书了再干这事情。否则很可能吃力不讨好。
在一个大refactor之后，组员们都得重新熟悉code base的。很可能一些本来闭着眼睛都能找得到的代码被移到不知道哪里去了。总遇到这种事情其实还是挺烦的。