最近案子快收尾在收敛bug
身为救援大队长的老人我被指派到维护一个很老的API
老API的设计已经无法满足扩充需求
新的扩充功能造成BUG
于是我花了大量时间甚至debug到天亮甚至请无薪假
新的API经过我反复测试各种case都完美无缺
但是code review却被质疑:
1. 是不是没找到root cause
2. 干嘛改动如此大? 只不过新加一点点功能干嘛改架构?
心中五味杂陈...
好歹我也是coding master，我说该重构了就是该开始还技术债了
更上头还是希望用最鸵鸟的方法继续用旧架构一堆workaound当作root cause
是该离职了吗? QwQ

维护的是你，不是他们。所以他们只想安全牌。不会管技术债换人厚，会多难接。一堆不知所以然的code。

code直接丢github开源全世界共享 然后特休全压放老人自己去解root cause啊 这还要教？

钱给到位吗 有成长空间吗 都没有就走人XD

公司:能动最重要，你有看过医院那些名医看小病就要开刀的吗??XD特别是老人家，没事就别乱开刀了万一有纠纷理由一大堆不用当真

一堆公司都这样 能动就好改这么大做什么 出问题你扛得住吗

可以重构啊，你不会等案子结束再重构？

问题是你重构完 上头买单?其他人接手会用会改？要多少时间熟悉你的code以上这只针对公司老人

可能只是不想要欠这种人情 也不想花钱请你重构 所以才这样回

很久以前我也跟你一样 后来看开了 拿多少钱做多少事除非上头有交代不然这些重构还是新东西自己改改玩玩 不会放台面上，顶多找面试拿来讲讲

那你就新旧都兼容啊 你的 pr 应该只有增加的行数没有砍旧逻辑

专案要先把责任切开 大杂烩下 对专案的风险感就会混杂

程式已经乱到flag乱跳...可读性0..

老人还被质疑喔...

是说派你去救火的人 又不满意你的方案吗==

他钱有给到你舍不得离职吗 XD

上面还有更老的的人啊...

M有要你重构？如果没有，你要重构，不应该先跟他讨论?y说到底 IC 也只是 M 的资源，资源怎么用是M的职责和权力事情发生后，建议可以去找M聊，解决问题 而不是想着离职

coding master是什么鬼

如果你不确定这个决定会不会被靠腰，你可以找比你懂公司状况的人或者主管讨论，而不是自己做决定

那你就真扩充而不是顺手重构 看行数最快

除非你是决策者否则要重构要看大家意见 这不是技术好不好

我有遇到遇到跟你一样的状况。明明团队 wiki 有前人留下 guide line，写童子军原则：顺手改掉周围的烂code。结果 review 后被要求全部 revert 回去，因为 reviewer 觉得跟需求无关的变动太多，造成他的负担。

顺手要能改前提是有测试吧 不然应该是先补测试

这是重写，不是重构

推一楼~都到master了,讲的话还没人信喔@@...

原始任务是解bug。要开新任务（重构），请先和派任务的人沟通。

上线前：乱一点没关系先把东西赶出来我们再回头重构/ 上线后：好好的你改它干嘛？

你的好意可能是他人的灾难 有些东西还是要讨论一下再决定 不要做无效工作 忙的要死得了一个非预期的结果 自己很挫折无意义

让你认清现实这间公司是来甩锅的不是来贡献的

我只觉得coding是你 testing也是你 是一件很奇怪的事情

这件事的问题是 事前沟通。没说服就做 浪费彼此时间

你这也不是一天的工作吧 中间没人反应？？

该离职了

重构前稍微跟别人提一下吧…

看过一些沟通方面的书籍，原PO上层还有决策者的话，要先说服或告知决策者，让他们心里有预期，看起来你做的和决策者的预期有所出入，才会被打枪

没先沟通好的问题

原始任务是除错对吗？ 这样的话，设计烂做不了就回报吧不然把除错做成更花资源且异动更大的重构人家也不领情说重构可能还客气了。如果直接变成新API，那算是改写或重新设计……这样如果人家不收其实也不令人非常意外

原本维护API可以很多人维护，你这一改，只剩你知道了。这样真的是只有自己对吗？ 不一定喔。你有权限负责整个专案，或整个部门的考绩吗？ 没权限的话，这样改。即即使技术没问题，千万不要认为是对的。到任何公司都可能得罪人。

取暖喔 自以为是的重构

傻子才自己在那边重构

通常这种情况代表没实力的怕事装逼仔在上位，会让这种逼洨上去的部门主管方向感也不是很好，如果薪资不是特别好应该可以闪人了不过还是要看规模，如果是一千行以内我都觉得还好。超过一千行就真的要思考了不用屌楼上一堆嘴重构的嫩逼，techjob都是搞硬件的废材，而且科技业95%都是冗员废材，所以留言有95%怕事废材也合理干原来是softjob，那更惨了，大部分都是台湾系新创小规模公司废材，薪水大概半导体业1/2，更不能参考

没人嘴重构好吗。我们嘴的是：重构前，不先沟通。

有共识、排进去时程的重构才比较不会出现这个问题。自己重构通常都是小规模、PR review 容易看懂的规模

怎么有人留言看一看自己破防XDD

你如果这么资深了 东西又有做出来 怎么还会有人在程式码层面质疑你？感觉很怪 是不是有牙膏没挤回到这两个问题都很合理 而且都不难回答吧 你有没有找到根因？修正那个根因需不需要这么大的改动？一百字以内就应该回答清楚的问题 答不出来先去训练表达能力==

你上一位接手可能也是这样想，然后每新来一位每一位都在重构，每次专案的程式码都不一样

问题是review前为啥不暴露一下你要做这件事大家讨论一下有没有价值你就自己单干但是上面觉得没用那就是没用啊

老问题了 你想扛上面不想扛我也遇过就是做ppt跟上面报告一轮

看到debug到天亮就想笑鬼岛惯老板这么多就是你这种人养的

重构要有计画跟目标，而且定期，不是遇到问题重构你这样搞下去有问题怎么知道是新问题还是原问题跟质疑其实也没啥关系，就是其他人听了会觉得很危险

没上头指示干嘛重构，不够忙吧

如果是我，就先做ppt、拉会议安排code review，最终更上面说要怎么做就怎么做，反正我把决策责任丢出去了，不重构我也乐得轻松

资历是老人，思维跟做事方式像社会新鲜人所以同一间待太久也不好

理解原po的无奈，code落到自己头上，为了改得动和长久维护的动，愿意吃亏花时间去重构，但反而被不是在第一线负责维护的reviewer质疑而觉得沮丧。只能说这种情况是政治和文化问题，开发文化是由有话语权和决策权的人说了算，如果沟通无果，要就加入这种文化，要不心里的坎过不去的话，那就好好打算吧

你的实力压不过别戈才会这样

提到老api xxx 看来你这不是重构唷 改api被打枪不是很合理吗

推justaID

开新api就好 旧的标deprecated

这行多的是文人相轻api 改spec 出事一定扛不住

用你的新架构有风险 你要从头维护到底吗 再来你明显不够厉害 找不到root cause以及用最小的改动解决问题

你以为〈只要能动就不要改〉是开玩笑的时候：

做改动前有先向上沟通吗？或是跨组沟通？获得同意才做的还是你就直接做下去了?

这代表你在公司credit还不够吧..够力的话谁会挡...

沟通能力有待加强 美其名想解决问题 其实只是底层码农的美好幻想 在产品先行/功能先行的团队就是这样也不见得要离职啦 可以找其他方式实现自我 参加程式小作坊之类的 不要用工作来实现理想 那是赚钱的地方

完美无缺是你自认为的，隐藏没爆的可能比你想像的多

以前的公司发生过，要求重构→开需求→写完测完→“还能跑就不用换了”，浪费我时间

有给你薪水就没浪费你时间啦，别学原PO没事自干就好

老气 没先确认过就自己改了吗？

如果已经在公司扛这么久，说明清楚后还不被上头信任 我是会直接走人

这种上头的 code review 当耳边风就好，看有没有机会加薪继续忍上头，或升迁为上头，没机会就换了吧