嗨，哥们。这问题太真实了，我估计一半以上的技术合伙人都遇到过。你这还算好的，起码是想重构，有的可能直接就想重写了（开个玩笑）。
这事儿处理起来得讲究点方法，毕竟对方是合伙人，不是普通同事，关系更重要。直接说“你代码太烂”肯定不行，伤感情。自己偷偷改了，更像是在搞背后袭击，也不行。
给你几个建议，你可以试试：
第一步：先冷静判断一下，是“看不惯”还是“真不行”？
- 只是“看不惯”？ 比如，他的代码风格、命名习惯、实现逻辑跟你不一样，但功能正常、也没啥性能问题。如果是这种情况，我劝你“忍”。创业初期，活下来最重要，产品能跑、能快速迭代就行。风格不统一是小事，以后有空再慢慢统一。
- 真的“不行”？ 比如，代码里有明显的逻辑漏洞、存在性能瓶颈（用户一多就卡死）、或者扩展性极差（加个小功能就得改十几个文件，还容易出错）。如果是这种情况，那就必须得改，不然就是给公司埋雷。
第二步：如果“真的不行”，那就找个“正当理由”去沟通。
关键是对事不对人。不要把矛头指向你的合伙人，而是指向代码本身带来的“问题”。
- 借着修 Bug 的机会： “哎，我发现最近线上那个 XXX 问题，根源好像在这块代码。你看，如果我们把它结构调整一下，不仅能彻底修复，以后还能避免类似问题。”
- 借着上新功能的机会： “下个版本不是要做那个 YYY 功能吗？我看了下现在的代码，直接加会很别扭，而且容易搞出新 Bug。我们不如花点时间把这块重构一下，给未来铺铺路，你看怎么样？”
- 借着性能优化的机会： “最近感觉后台那个接口有点慢，我分析了一下，瓶颈主要在这里。我有个想法，可以把它改成 XXX 模式，性能估计能提上来不少。”
看到没？全程聊的都是“产品的问题”、“未来的规划”，而不是“你的代码有问题”。这样对方就更容易接受。
第三步：用事实说话，小范围“秀一下肌肉”。
光说不练假把式。你可以自己先在自己的分支上，把一小块关键代码按你的想法重构了。然后拿着结果去找他，比如：
“你看，我把这块代码按新思路改了下，代码行数少了 30%，单元测试覆盖率提到了 90%，而且跑起来还快了 20%。要不我们后面就按这个方向来？”
当他看到实实在在的好处（更稳定、更快、更易维护），是个讲道理的工程师都很难拒绝。
第四步：着眼未来，建立“团队规则”。
这是最重要的一步，能从根源上解决问题。可以找个时间，心平气和地一起聊聊：
“为了以后我们俩协作更顺畅，也为了以后万一有新同事加入能快速上手，我们要不要一起定个‘代码规范’？比如，统一用一个代码格式化工具（像 Prettier、Black），约定好一些基本的命名规则、目录结构。这样，以后谁写的代码看起来都像一个人写的，维护起来也方便。”
把“你的风格”和“我的风格”之争，上升到“团队的工程标准”层面。这样就不是个人矛盾了，而是为了公司好。一旦定了标准，以后大家就都按标准来，谁也别说谁。
总结一下：
创业搭伙，人永远比代码重要。处理这种问题的核心思想就是：对事不对人，沟通大于天，团结压倒一切。 别因为几行代码，伤了兄弟的和气，那才是最大的损失。