什么啊，这种人你也给加分，看来你们公司也是不咋样。
就楼主的情况，无非三种：
一是两个函数以后会分离，也就是凑巧初始功能差不多，但面对的是不同的调用逻辑和业务，则这种情况，根本无需注释，因为未来分岔后汇不到一起，谁也不影响谁。
二是功能强相关，面对的是同样的逻辑和业务，只是有人提了个新的需求，导致不得不增加这么一个接口，但是这个需求是扯淡的，那么就怼回去，让他们把需求理清楚，这样反而能帮助业务线产品经理或上层调用方码农更好地纠正错误的逻辑，提升他们的水平。
三是需求确实是合理的，那么增加接口函数的时候就应该共用相同的逻辑，将共用代码分离出来。而函数外自然也不需要额外的注释。
反正不管哪种情况，就楼主提到的，都不应该发生，这无非就是那个码农水平烂，或想甩锅。

【 在 syssky 的大作中提到: 】
: 我看到下属有这种注释，反而会是对他极大的加分项。
: 首先是有责任心，这是最重要的。
: 第二没有瞎jb重构，用最小的代价就达到了需求。
: ...................
--
FROM 112.17.238.*

看来你确实没干过了
【 在 song023 的大作中提到: 】
: 搞的好像做工程项目就要慎小慎微，你是写了几亿行代码的大项目，windows操作系统？
: 现在的互联网真实项目，很多都是微服务，中等服务，一个进程代码就几千行， 这种简单的重构还有谨小慎微？ 那啥也别干了。
: 除非你干的是操作系统。
--
FROM 112.96.135.*

要是干黄了2个，那确实厉害。算是个玩笑吧

但如果不清楚上下游情况，就去重构了，现实生产中确实不够谨慎。
很多业务不是纯粹的技术，比如这个项目在你手停留3个月，你要不要去重构？

【 在 song023 的大作中提到: 】
: 搞笑，bat我干过两个
--
FROM 111.206.87.*

吹捧至失真，属实不可取
技术人应该有技术上的进取心
- 来自 水木社区APP v3.5.5
【 在 song023 的大作中提到: 】
: 重构肯定要在理解透彻的情况下。 理解不透彻不敢重构可以理解。写注释也是个很好的过渡方法。但是拿这个不停的吹捧，还要踩一下重构的人应该多反思是不是自己比较无能。
: - 来自 水木社区APP v3.5.6
--
FROM 120.244.218.*