发现公司项目里有个类的名字拼错了，要改吗？

[langzizx39]

在加一个功能时发现这个类（不是我写的）的名字拼错了两个字母，但这个类牵扯到的东西很多（前后端都有），我要修改吗？还是将错就错？

[loshine1992]

用可以一次性替换所有的 IDE 来改不就可以了。。

[lizhenda]

我觉你最好先问问写这个人，和他说一下，看他的态度在决定，不然不声不响就改了别人的东西实在不是很好

[ys0290]

不就是个名字么，错了就错了

[offer]

改个 jb 不改。

[k9982874]

有时间就改，也能熟悉一下项目各个关节。不过要做好背锅的准备。

[orFish]

不改🌚

[SourceMan]

你看懂没？看懂了就不要改了。

[lyragosa]

将另一个类设置为这个类的引用

你自己用这个新的，不影响其他人。

[tonyVex]

和写的人商量下，全局 正则替换掉。

[hahastudio]

因为会涉及很多组件，所以我的建议是这样的：
如果你们处在发布期，那就先将错就错吧，但是把这个问题先记下来。
然后等到有时间的时候，跟组里其他人沟通一下，然后再改。因为你改完肯定得有大规模的测试，虽然不用很细致= =

[ioioj5]

不改, 改了之后就会出现各种莫名其妙的问题

[vanxining]

不改。比如 Unix 的一个系统调用： creat 。

[xbb7766]

要改的话最好 IDE 能支持自动替换，不然会很惨。
没重大歧义就算了。
除非是类似于把 SendEmail() 写成 ReceiveEmail() 这样差十万八千里的。

[superbear]

不知道有多少使用方，贸然改会出问题。

[icewent]

想到 Googol 。拼错了也可以将错就错，多年后未尽不是一段佳话。

[icewent]

@icewent 未必

[vitovan]

看这命名，何止是单词拼错。
号都不连，逼死人。

[Wangxf]

用 ide ，或者 sublime 都用这个功能 sublime 是 shift ＋ command ＋ f

[yuankui]

SystemFiels

reg.regist(xxx)

Modlue...

太多了..

[curiousjude]

这个我个人的看法是，除非错得离谱或没有 100%的把握，还是不要改了。很多人觉得拼错了没什么大不了，我是很鄙视的，因为拼写错误而花大时间 debug 是很让人吐血的。

有很多很懒的人，明明一开始就发现错误了，因为懒就是不改，后面日积月累，不断坑人。

[curiousjude]

r#20 @curiousjude fix ：或有 100%的把握。

[cloudzhy]

改，趁机熟悉系统

[500miles]

你可以加上个注释, 指出 "可能存在 typo error"

千万不要私自去改 毕竟这并不属于 bug

我的看法.

[loryyang]

最好不要改，除非你很熟悉这个东西
拼错很正常，有些时候手误，下次发现时为了安全也不会再改了，能看懂，不会误解就行

[hcymk2]

https://imququ.com/post/referrer-or-referer.html?utm_source=tuicool&utm_medium=referral

[paicha]

[fogisland]

@paicha 哈哈，很贴切

[cxbig]

Typo 看情况吧，成本不高的话，有 IDE 之类的辅助，真要改不难。

[langzizx39]

@paicha 密集恐惧症患者表示吓尿了，不改了。。

[jydeng]

@paicha 哈哈，目测改了以后就要爆炸。

[EthanZhu]

乱读也很烦心，同事都把 sql 读成 circle

[Owenjia]

记得之前 QZone 有处 javascript 这个词拼错了，然后那个功能用不了，好久都没修。

[lution]

@EthanZhu 正确的读法是什么？

[davidli]

weight -> wight ...

[EthanZhu]

@lution 直接读 3 个字母或者 /ˈsiːkwəl/

[domty]

不是你的代码尽量不要改
用了有一段时间的代码不要改

说实话如果不能分析有多少处地方用就贸然去改绝对是作死的行为。

[dong3580]

@paicha
太恶心了,密集恐惧症,受不鸟你了,

[kurtzhong]

don't 改

除非這個項目你一個人维护，并且你能一个人 Hold 住整个项目。

[ixiaozhi]

@EthanZhu 每一次知道是这么读 学习了

[jhaohai]

不改，留给后人讲故事

[liujiangbei]

为什么大家都建议不改，毫无疑问，跟写这个代码的人（如果还在）简单沟通一下果断要改。

[sacuba]

@liujiangbei 牵扯很多的话，几乎没人愿意去改的，毕竟无关大雅 我觉得 易懂简练有规则的命名方式就是好的命名，拼错了个单词无伤大雅

[xinyewdz]

改完之后,是要背黑锅的.

[yoa1q7y]

最好别动，多一事不如少一事

[merlinran]

一个连改名都担心背黑锅的地方，代码只会越来越糟糕，还值得呆么？版本管理、自动化测试和构建，轻而易举就可以防住可能的风险。

[jsfaint]

@vanxining unix 时代 creat 是故意简写的，后来 Ken 大爷后悔了，再写 go 的时候亲自改成了 create

[xiaowei4895]

当然改啊，改个名字都搞不定，你还能干点啥？

[liberize]

不作死就不会。。。

[young]

之前碰到过一个表中某个字段 channel 写成了 channle
就这样用了很长时间... 没人敢动

[crayygy]

适配器或者外观模式？

[server]

这事干过 一个常量名错了，改了很多地方。
知道错了不该，以后慢慢的也成这样了。

[new_bee]

同为代码洁癖者表示不能忍。不过哥们吃过这个亏。建议大项目慎重，要及时和其他人沟通，不要相信 IDE 自动化重构。可以 wrapper 或另写。当然小项目随意。

[bdbai]

@vanxining 还有 HTTP Referer

[akagi]

除非作者授意，或者项目特简单，不然两个月之后的某一天，也许你就要开启一个满是 error 的平行世界……

[luoluoluo]

It doesn't matter at all.

[n6DD1A640]

这是一个深坑， LZ 请三思。。

[incompatible]

不要改。原因见 26 楼。

另外，如果觉得用 IDE 的重构功能改可以高枕无忧，那就太 naive 了。
@loshine1992
@xbb7766
@Wangxf
@cxbig
你永远不会知道是否有人通过反射调用了这个类的某个方法，你也不知道是否有人把这个代码的源码或者编译结果作为依赖引入他自己的工程。这些都是无法通过 IDE 的 AST 检测出来的。

[jukka]

我以前给 label 写成 lable 一直到项目上线俩月大家才发现。。。。。要知道基本上每个 UI 文件里都出现了这个单词啊。

[sagnitude]

要慎重，我们在 model 里改动变量名字或者增删一个变量有时候会需要提前一周通知，相关开发人员一起动手改，新功能暂停开发，所有项目同时更改同时上线。
除非你的所有项目都有完备的自动化测试和构建体系，否则一定要慎重。

服务端改动一个 model 的变量名， iOS ， javascript ， Android ， Java 桌面端，所有的项目都要改，
尤其是前端！ javascript 这种语言，服务端改动 model 之后，前端页面里不跑到特定的代码那里根本不知道会出错

我们有很多小项目，半年或者一两年没维护，基本都是跑不了的，因为其他的公共代码修改了，哪怕只是修改了一两个域，也很难查。基本要用的时候都需要安排人修复

[virusdefender]

Java 或者 c 语言系列的，相信 ide 估计可以都自动改过来， Python 或者 js 类的，很可能改不全。

[xbb7766]

@vitovan 第一眼看成:setup, 再想想难道是 step?

.201511051109 这个后缀更坑，“ 11 月 5 号到 9 号”？还是“ 11 月 5 号 11 点 09 分”……

[run2]

除非测试 100% code coverage 的代码加 CI ，不然还是加 todo 以后重构的时候改的好

[zander]

同 ＃ 8 ，不要改，但是可以把正确名字的坑占了，然后引用原类。
你可以用正确的，他们用旧的也好新的也好无所谓。

[ming2050]

改完没准问题就大了，将错就错吧

[lmaq]

使用没有问题的话最好不要改

[cxbig]

@incompatible 在我看来只是成本问题
修正 typo 以前看看有多少关联，有多复杂，评估一下。至于怕漏掉反射调用之类，基于人员素质的问题，都是可以纳入成本核算的。

[incompatible]

@cxbig 抱歉，没有仔细读清楚你的观点就 @了你
你说的对，这个事情的关键点是成本。 IDE 只是降低成本的必要手段。

[yjxjn]

按照系统 risk 的方面来考虑。不改，为啥呢，如果这个系统你非常熟悉架构，调查之后，能 100%确保那些地方用这个类了，就改，如果不确定，那就 no zuo no die 吧，放着吧。不碍事的。

[ibireme]

我自己的代码，作死也要改。
公司项目中遇到的话，看心情了。。

[yjxjn]

我反对楼上说拿 ide 一次性替换的！ too young ！你除非系统特别小。。。。业务量支撑非常大的系统，成本是非常重要的，无论是经济成本还是时间成本。
我就说说我组怎么做一个完整的 devops 。
1.做设计书，确定各个变量名啊，方法名，接口之类的。
2.做详细设计书，把流，处理等等写好。
3.开始 coding ， coding 之后，将设计书和详细设计的内容比较一番，看有没有漏的，再自己测试一下。最后团队的大拿来 review 。。。。然后定版，并且把每一步的开发和测试 log 留好，
4.user access test 俗称 UAT 测试，每发现一个问题，提一个 ticket ，然后 track 问题。
5.uat 没啥问题了，直接上 prod 测试。测完之后，留测试 log ，最后把设计书改一改，完成最终版本。

[googlefans]

先搞清楚不改对你的影响大吗？

[monkeymonkey]

这种错误写的时候就该避免，装一个 Spell Checker 插件吧。
不只是 typo ，连单词是否合适都应该首先考虑清楚再写。

[knightdf]

我还把项目名写错过呢 - -， 还好项目名只是个名字，改改没事

[BigDecimal]

第一，因为不是你写的，所以改后可能存在潜在的未知问题。
第二，因为这不算 bug ，改后可能会造出新的 bug ，所以最好不要冒这个风险。
第三，如果实在想改，那么改完之后就得把这个类所涉及到的功能都统统测试一遍，以确保没有造成新的 bug ，这是没事找事的做法。


综上所述，还是将错就错，不改为妙。

[FrankFang128]

破窗理论

[POPOEVER]

维护一个 typo 文档吧

[bbx]

dependency 太多，搞了就等着背锅吧

[letv]

遇到同样的情况，用 vs 看了下，只有两处引用，所以改了。。。

[pynix]

能改的时候尽快改了吧。再不改就等着成为历史遗留问题吧。。。。

[happyz90]

反正要混淆掉。。。

[vitovan]

r#61 @xbb7766 那是 step ，日期那个我也没搞懂，不过不重要了。

[mgcnrx11]

@monkeymonkey 终于看到有人提到 Spell Check 了。看到过太多 Success 多了一个 s ，复数不考虑变体直接加 s 的拼写。其实加一个插件就能发现的了。看来定团队规范也必须要有 Spell Check 。

[ilotuo]

有 git 又有各种工具。为什么不改
一个类名而已 对自己能力是有多不自信

[inmyfree]

@vitovan 看到有种蛋蛋的忧伤...

[iaigcfun]

intellj Shirt+ F6

[bugsnail]

不要改!!

IDE 把这单词加到字典就可以避免拼写警告（处女座建议）

[iaigcfun]

@armysheng 哈哈哈

[Reficul]

想到了 “ If it ain't broke, don't fix it “😂

[luzjoy]

看到了糟心 要是我就非得改了

[wizardforcel]

如果所用的编程语言支持别名 在自己文件里起个别名就好了。

[angryRabbit]

不改。不改，这个错误是别人的，改了这个错误就是你的。不是你撞的你为什么扶？
当然我也改过别人的拼写错误，是在保证 100%不出麻烦的情况

[coronanimo]

看影响。。。。 不确定不要改。。。

[hrong]

通过反射调用什么的， IDE 的自动批量更改不起作用。这种情况得批量替换文本，所以有风险的。。。。

[xiangace]

只说一句话改的太轻松了, 不负责任 或者 业务线访问量就很小, 价值不大的场景......

1. 如果属于底层基础库, 修改类似以下的规则. 如果仅仅是单个业务层的代码, 调用少可以替换再部署上线.
2. 根据你的编程语言, eg: py 类就加新的类名, 然后 B = A 引用赋值.
3. 根据你熟悉的业务场景依次修改并观察线上日志收集平台, 注意是否有涉及接口的 error 信息
4. 如果是快废弃的代码, 真的没必要再操心.
5. 保证业务运行正常是首要的.

[msg7086]

绝对不要改。
就算你测试全过，也可能会遇到一些 edge case 。
最典型的就是序列化反序列化的时候记录的类名不符。这种是要出大事的。轻则 Cookie 报废，重则系统崩掉数据丢失。

[azuginnen]

@armysheng 小胖你 iphone 修好了没

[iaigcfun]

@azuginnen 没有，上次去修没带发票，后来就没时间，现在在家。。回去再修

[azuginnen]

@armysheng 因为又看见你用锤子发便签了，哈