我们都去过那儿.你已经编写了一些代码和单元测试,测试都通过了,代码也很合适(没有什么是完美的,对吧？).然后,确定他们比你更了解并且决定将代码或接口更改为代码的人只是因为他/她不喜欢你使用的变量/类名.没有"真正的"重构,没有真正的优化,没有真正的改进 - 只是不同的词 - 不一定是更好的词,只是不同.
我真正的问题在于:(a)浪费时间;(b)它首先表现出对编写代码的开发人员的公然不尊重.
我的内心反应是抨击,但这是适得其反的.相反,我认为我可能会怀疑一两段作为项目所采用的"宪章"或"哲学".我想知道是否还有其他人试过这个,如果有的话,是否成功了？
在查看下面的初始评论(感谢)之后,我认为我的问题主要是这个改变打破了已经运行的代码的构建.因此,需要花费时间来修复(在我看来)非增值变更的代码.
- 谢谢
Tim*_*Tim 25
...决定将代码或接口更改为代码,因为他/她不喜欢您使用的变量/类名.
我真正的问题在于:(a)浪费时间;(b)它首先表现出对编写代码的开发人员的公然不尊重.
我的内心反应是抨击......
我在这些陈述中看到了一些非常关注的事情.
你太个人了.
我曾经和一个在我改变"他的"代码时吓坏了的人一起工作过.他的代码太可怕了; 它是马车和不可维护的.他总是熬夜,扑灭火灾和破坏事情 - 基本上是一个消极的贡献者.我在一个周末为一个项目重写了他所有糟糕的代码以获得一个很大的功能,当他星期一回来时有一个非常合适的东西.我并不是说你的东西太可怕了,但也许你需要冷静下来并且更加客观.
不要这么亲自.退一步考虑一下 - 也许"你的"代码需要修复
如果您发布了代码和更改,或者至少通过一两个示例更好地了解情况,我们可能会给出更好的答案.
编辑:在看到代码更改并发现构建被破坏后,我将不得不改变这个答案的基调.我理解史蒂夫的沮丧 - 我同意 - 这不是一个好的改变.它使特定的typedef更加通用,不再具有描述性.
虽然我认为我的一些观点是有效的,但在这种情况下看起来似乎是不合适的.
代码"所有权"的问题是无关紧要的.如果代码更改没用,那么团队中的每个人都应该感到高兴.如果他们是好的变化,那么每个人都应该为此感到高兴.如果存在意见分歧,那么你们都需要找到共同点.
打破构建并不是一件好事.
史蒂夫,对不起,如果我苛刻下来 - 看起来在这种情况下,你的挫折是合理的,但不是因为它是"你的"代码.
Lau*_*ves 17
在这种情况下可能有用的一件事是要求对所有更改进行代码审查.如果其他人必须首先审查它,人们就不太可能做出毫无意义的改变.如果他们真的可以说服另一位开发者他们的改变应该进入那么也许它毕竟不是那么无意义.
Heey,
伙计们!我们都需要谈谈!
只是坐在一起和TALK!总有理由改变,总有理由不这样做.
一起决定!
不要只是去StackOverflow或论坛,然后问这类问题.
新的开发人员做到了 - 他从社区得到的回应可能是正面的(是的,糟糕的代码应该被重构).
目前的开发人员也做到了 - 他也得到了社区的回应:" 白痴可以做出这样的改变! "
其结果是:长期适得其反,具有破坏性,进攻性的环境.
谁想要它？
刚放在桌子上你的论点,就是这样.
新开发也需要一些介绍.
旧开发者需要列出TOO.
这应该是协同工作而不是互相惹恼.
作为团队,共同决定,交谈.
并且......更好地提出诸如"如何更好地重构这个？"之类的问题.
干杯.
| 归档时间： |
|
| 查看次数： |
877 次 |
| 最近记录： |