请不要在回答技术问题时复制粘贴 AI 生成的内容 #Wrapper { background-color: #e2e2e2; background-image: url("/static/img/shadow_light.png"), url("//cdn.v2ex.com/assets/bgs/circuit.png"); background-repeat: repeat-x, repeat-x; } #Wrapper.Night { background-color: #1f2e3d; background-image: url("/static/img/shadow.png"), url("//cdn.v2ex.com/assets/bgs/circuit_night.png"); background-repeat: repeat-x, repeat-x; background-size: 20px 20px, 162.5px 162.5px; }
发现公司项目里有个类的名字拼错了，要改吗？
langzizx39 2015-12-11 13:24:08 +08:00 9181 次点击
这是一个创建于 3591 天前的主题，其中的信息可能已经有所发展或是发生改变。
在加一个功能时发现这个类（不是我写的）的名字拼错了两个字母，但这个类牵扯到的东西很多（前后端都有），我要修改吗？还是将错就错？
 | 1 loshine1992 2015-12-11 13:26:13 +08:00 用可以一次性替换所有的 IDE 来改不就可以了。。 |
 | 2 lizhenda 2015-12-11 13:33:17 +08:00 我觉你最好先问问写这个人，和他说一下，看他的态度在决定，不然不声不响就改了别人的东西实在不是很好 |
 | 3 ys0290 2015-12-11 13:38:32 +08:00 via iPhone 不就是个名字么，错了就错了 |
 | 4 offer 2015-12-11 14:07:21 +08:00 改个 jb 不改。 |
 | 5 k9982874 2015-12-11 14:08:32 +08:00 有时间就改，也能熟悉一下项目各个关节。不过要做好背锅的准备。 |
 | 6 orFish 2015-12-11 14:10:15 +08:00 不改 |
 | 7 SourceMan 2015-12-11 14:11:05 +08:00 你看懂没？看懂了就不要改了。 |
 | 8 lyragosa 2015-12-11 14:12:19 +08:00  5 将另一个类设置为这个类的引用 你自己用这个新的，不影响其他人。 |
 | 9 tonyVex 2015-12-11 14:16:38 +08:00 和写的人商量下，全局 正则替换掉。 |
 | 10 hahastudio 2015-12-11 14:16:55 +08:00 因为会涉及很多组件，所以我的建议是这样的： 如果你们处在发布期，那就先将错就错吧，但是把这个问题先记下来。 然后等到有时间的时候，跟组里其他人沟通一下，然后再改。因为你改完肯定得有大规模的测试，虽然不用很细致= = |
 | 11 ioioj5 2015-12-11 14:17:38 +08:00 不改, 改了之后就会出现各种莫名其妙的问题 |
 | 12 vanxining 2015-12-11 14:20:25 +08:00 via Android 3 不改。比如 Unix 的一个系统调用： creat 。 |
 | 13 xbb7766 2015-12-11 14:22:27 +08:00 要改的话最好 IDE 能支持自动替换，不然会很惨。 没重大歧义就算了。 除非是类似于把 SendEmail() 写成 ReceiveEmail() 这样差十万八千里的。 |
 | 14 superbear 2015-12-11 14:26:38 +08:00 不知道有多少使用方，贸然改会出问题。 |
 | 15 icewent 2015-12-11 14:27:07 +08:00 想到 Googol 。拼错了也可以将错就错，多年后未尽不是一段佳话。 |
 | 17 vitovan 2015-12-11 14:36:21 +08:00 1  看这命名，何止是单词拼错。 号都不连，逼死人。 |
 | 18 Wangxf 2015-12-11 14:38:28 +08:00 用 ide ，或者 sublime 都用这个功能 sublime 是 shift ＋ command ＋ f |
 | 19 yuankui 2015-12-11 14:43:42 +08:00 SystemFiels reg.regist(xxx) Modlue... 太多了.. |
 | 20 curiousjude 2015-12-11 14:57:23 +08:00 这个我个人的看法是，除非错得离谱或没有 100%的把握，还是不要改了。很多人觉得拼错了没什么大不了，我是很鄙视的，因为拼写错误而花大时间 debug 是很让人吐血的。 有很多很懒的人，明明一开始就发现错误了，因为懒就是不改，后面日积月累，不断坑人。 |
| 21 curiousjude 2015-12-11 14:57:56 +08:00 r#20 @curiousjude fix ：或有 100%的把握。 |
 | 22 cloudzhy 2015-12-11 15:00:12 +08:00 改，趁机熟悉系统 |
 | 23 500miles 2015-12-11 15:06:52 +08:00 你可以加上个注释, 指出 "可能存在 typo error" 千万不要私自去改 毕竟这并不属于 bug 我的看法. |
 | 24 loryyang 2015-12-11 15:08:53 +08:00 最好不要改，除非你很熟悉这个东西 拼错很正常，有些时候手误，下次发现时为了安全也不会再改了，能看懂，不会误解就行 |
 | 25 hcymk2 2015-12-11 15:11:46 +08:00 |
 | 26 paicha PRO 21  |
 | 28 cxbig 2015-12-11 15:33:32 +08:00 Typo 看情况吧，成本不高的话，有 IDE 之类的辅助，真要改不难。 |
 | 29 langzizx39 OP @paicha 密集恐惧症患者表示吓尿了，不改了。。 |
 | 31 EthanZhu 2015-12-11 15:55:36 +08:00 乱读也很烦心，同事都把 sql 读成 circle |
 | 32 Owenjia 2015-12-11 15:56:35 +08:00 记得之前 QZone 有处 Javascript 这个词拼错了，然后那个功能用不了，好久都没修。 |
 | 34 davidli 2015-12-11 16:09:57 +08:00 weight -> wight ... |
 | 36 domty 2015-12-11 16:20:08 +08:00 不是你的代码尽量不要改 用了有一段时间的代码不要改 说实话如果不能分析有多少处地方用就贸然去改绝对是作死的行为。 |
 | 38 kurtzhong 2015-12-11 16:25:48 +08:00 don't 改 除非目你一人维护，并且你能一个人 Hold 住整个项目。 |
 | 40 jhaohai 2015-12-11 16:43:37 +08:00 via iPhone 不改，留给后人讲故事 |
 | 41 liujiangbei 2015-12-11 16:46:17 +08:00 为什么大家都建议不改，毫无疑问，跟写这个代码的人（如果还在）简单沟通一下果断要改。 |
 | 42 sacuba 2015-12-11 16:52:13 +08:00 1 @liujiangbei 牵扯很多的话，几乎没人愿意去改的，毕竟无关大雅 我觉得 易懂简练有规则的命名方式就是好的命名，拼错了个单词无伤大雅 |
 | 43 xinyewdz 2015-12-11 16:58:15 +08:00 改完之后,是要背黑锅的. |
 | 44 yoa1q7y 2015-12-11 17:08:23 +08:00 最好别动，多一事不如少一事 |
 | 45 merlinran 2015-12-11 17:13:10 +08:00 3 一个连改名都担心背黑锅的地方，代码只会越来越糟糕，还值得呆么？版本管理、自动化测试和构建，轻而易举就可以防住可能的风险。 |
 | 46 jsfaint 2015-12-11 17:21:16 +08:00 @vanxining unix 时代 creat 是故意简写的，后来 Ken 大爷后悔了，再写 go 的时候亲自改成了 create |
 | 47 xiaowei4895 2015-12-11 17:32:32 +08:00 当然改啊，改个名字都搞不定，你还能干点啥？ |
 | 48 liberize 2015-12-11 17:38:09 +08:00 via iPhone 不作死就不会。。。 |
 | 49 young 2015-12-11 17:40:08 +08:00 之前碰到过一个表中某个字段 channel 写成了 channle 就这样用了很长时间... 没人敢动 |
 | 50 crayygy 2015-12-11 17:46:53 +08:00 适配器或者外观模式？ |
 | 51 server 2015-12-11 17:52:20 +08:00 这事干过 一个常量名错了，改了很多地方。 知道错了不该，以后慢慢的也成这样了。 |
 | 52 new_bee 2015-12-11 18:06:03 +08:00 同为代码洁癖者表示不能忍。不过哥们吃过这个亏。建议大项目慎重，要及时和其他人沟通，不要相信 IDE 自动化重构。可以 wrapper 或另写。当然小项目随意。 |
 | 54 akagi 2015-12-11 19:40:41 +08:00 除非作者授意，或者项目特简单，不然两个月之后的某一天，也许你就要开启一个满是 error 的平行世界…… |
 | 55 luoluoluo 2015-12-11 20:00:06 +08:00 It doesn't matter at all. |
 | 56 n6DD1A640 2015-12-11 20:18:32 +08:00 这是一个深坑， LZ 请三思。。 |
 | 57 incompatible 2015-12-11 20:25:49 +08:00 不要改。原因见 26 楼。 另外，如果觉得用 IDE 的重构功能改可以高枕无忧，那就太 naive 了。 @loshine1992 @xbb7766 @Wangxf @cxbig 你永远不会知道是否有人通过反射调用了这个类的某个方法，你也不知道是否有人把这个代码的源码或者编译结果作为依赖引入他自己的工程。这些都是无法通过 IDE 的 AST 检测出来的。 |
 | 58 jukka 2015-12-11 20:33:06 +08:00 我以前给 label 写成 lable 一直到项目上线俩月大家才发现。。。。。要知道基本上每个 UI 文件里都出现了这个单词啊。 |
 | 59 sagnitude 2015-12-11 20:40:35 +08:00 要慎重，我们在 model 里改动变量名字或者增删一个变量有时候会需要提前一周通知，相关开发人员一起动手改，新功能暂停开发，所有项目同时更改同时上线。 除非你的所有项目都有完备的自动化测试和构建体系，否则一定要慎重。 服务端改动一个 model 的变量名， iOS ， Javascript ， Android ， Java 桌面端，所有的项目都要改， 尤其是前端！ Javascript 这种语言，服务端改动 model 之后，前端页面里不跑到特定的代码那里根本不知道会出错 我们有很多小项目，半年或者一两年没维护，基本都是跑不了的，因为其他的公共代码修改了，哪怕只是修改了一两个域，也很难查。基本要用的时候都需要安排人修复 |
 | 60 virusdefender 2015-12-11 20:43:04 +08:00 Java 或者 c 语言系列的，相信 ide 估计可以都自动改过来， Python 或者 js 类的，很可能改不全。 |
| 61 xbb7766 2015-12-11 21:17:28 +08:00 via Android |
 | 62 run2 2015-12-11 21:43:56 +08:00 除非测试 100% code coverage 的代码加 CI ，不然还是加 todo 以后重构的时候改的好 |
 | 63 zander 2015-12-11 21:48:44 +08:00 同 ＃ 8 ，不要改，但是可以把正确名字的坑占了，然后引用原类。 你可以用正确的，他们用旧的也好新的也好无所谓。 |
 | 64 ming2050 2015-12-11 21:53:02 +08:00 改完没准问题就大了，将错就错吧 |
 | 65 lmaq 2015-12-11 21:56:29 +08:00 使用没有问题的话最好不要改 |
| 66 cxbig 2015-12-11 21:57:10 +08:00 @incompatible 在我看来只是成本问题 修正 typo 以前看看有多少关联，有多复杂，评估一下。至于怕漏掉反射调用之类，基于人员素质的问题，都是可以纳入成本核算的。 |
| 67 incompatible 2015-12-11 22:32:26 +08:00 @cxbig 抱歉，没有仔细读清楚你的观点就 @了你 你说的对，这个事情的关键点是成本。 IDE 只是降低成本的必要手段。 |
 | 68 yjxjn 2015-12-11 22:33:54 +08:00 按照系统 risk 的方面来考虑。不改，为啥呢，如果这个系统你非常熟悉架构，调查之后，能 100%确保那些地方用这个类了，就改，如果不确定，那就 no zuo no die 吧，放着吧。不碍事的。 |
 | 69 ibireme 2015-12-11 22:36:54 +08:00 我自己的代码，作死也要改。 公司项目中遇到的话，看心情了。。 |
| 70 yjxjn 2015-12-11 22:43:41 +08:00 我反对楼上说拿 ide 一次性替换的！ too young ！你除非系统特别小。。。。业务量支撑非常大的系统，成本是非常重要的，无论是经济成本还是时间成本。 我就说说我组怎么做一个完整的 devops 。 1.做设计书，确定各个变量名啊，方法名，接口之类的。 2.做详细设计书，把流，处理等等写好。 3.开始 coding ， coding 之后，将设计书和详细设计的内容比较一番，看有没有漏的，再自己测试一下。最后团队的大拿来 review 。。。。然后定版，并且把每一步的开发和测试 log 留好， 4.user access test 俗称 UAT 测试，每发现一个问题，提一个 ticket ，然后 track 问题。 5.uat 没啥问题了，直接上 prod 测试。测完之后，留测试 log ，最后把设计书改一改，完成最终版本。 |
 | 71 googlefans 2015-12-11 22:47:20 +08:00 先搞清楚不改对你的影响大吗？ |
 | 72 monkeymonkey 2015-12-12 00:41:56 +08:00 1 这种错误写的时候就该避免，装一个 Spell Checker 插件吧。 不只是 typo ，连单词是否合适都应该首先考虑清楚再写。 |
 | 73 knightdf 2015-12-12 01:08:17 +08:00 我还把项目名写错过呢 - -， 还好项目名只是个名字，改改没事 |
 | 74 BigDecimal 2015-12-12 02:11:50 +08:00 第一，因为不是你写的，所以改后可能存在潜在的未知问题。 第二，因为这不算 bug ，改后可能会造出新的 bug ，所以最好不要冒这个风险。 第三，如果实在想改，那么改完之后就得把这个类所涉及到的功能都统统测试一遍，以确保没有造成新的 bug ，这是没事找事的做法。 综上所述，还是将错就错，不改为妙。 |
 | 75 FrankFang128 2015-12-12 04:21:45 +08:00 via Android 1 破窗理论 |
 | 76 POPOEVER 2015-12-12 05:23:13 +08:00 维护一个 typo 文档吧 |
 | 77 bbx 2015-12-12 07:47:00 +08:00 dependency 太多，搞了就等着背锅吧 |
 | 78 letv 2015-12-12 08:19:30 +08:00 遇到同样的情况，用 vs 看了下，只有两处引用，所以改了。。。 |
 | 79 pynix 2015-12-12 08:36:13 +08:00 能改的时候尽快改了吧。再不改就等着成为历史遗留问题吧。。。。 |
 | 80 happyz90 2015-12-12 08:53:03 +08:00 via Android 反正要混淆掉。。。 |
 | 82 mgcnrx11 2015-12-12 09:40:12 +08:00 |
 | 83 ilotuo 2015-12-12 09:48:42 +08:00 via Android 有 git 又有各种工具。为什么不改 一个类名而已 对自己能力是有多不自信 |
 | 85 armysheng 2015-12-12 10:40:22 +08:00 intellj Shirt+ F6 |
 | 86 bugsnail 2015-12-12 10:48:38 +08:00 不要改!! IDE 把这单词加到字典就可以避免拼写警告（处女座建议） |
 | 88 Reficul 2015-12-12 12:15:48 +08:00 via Android 想到了 “ If it ain't broke, don't fix it “ |
 | 89 luzjoy 2015-12-12 15:29:37 +08:00 看到了糟心 要是我就非得改了 |
 | 90 wizardforcel &bsp; 2015-12-12 15:38:03 +08:00 via Android 如果所用的编程语言支持别名 在自己文件里起个别名就好了。 |
 | 91 angryRabbit 2015-12-12 21:07:46 +08:00 不改。不改，这个错误是别人的，改了这个错误就是你的。不是你撞的你为什么扶？ 当然我也改过别人的拼写错误，是在保证 100%不出麻烦的情况 |
 | 92 coronanimo 2015-12-13 00:24:30 +08:00 看影响。。。。 不确定不要改。。。 |
 | 93 hrong 2015-12-13 10:52:17 +08:00 通过反射调用什么的， IDE 的自动批量更改不起作用。这种情况得批量替换文本，所以有风险的。。。。 |
 | 94 xiangace 2015-12-13 13:31:28 +08:00 只说一句话改的太轻松了, 不负责任 或者 业务线访问量就很小, 价值不大的场景...... 1. 如果属于底层基础库, 修改类似以下的规则. 如果仅仅是单个业务层的代码, 调用少可以替换再部署上线. 2. 根据你的编程语言, eg: py 类就加新的类名, 然后 B = A 引用赋值. 3. 根据你熟悉的业务场景依次修改并观察线上日志收集平台, 注意是否有涉及接口的 error 信息 4. 如果是快废弃的代码, 真的没必要再操心. 5. 保证业务运行正常是首要的. |
 | 95 msg7086 2015-12-13 16:25:47 +08:00 绝对不要改。 就算你测试全过，也可能会遇到一些 edge case 。 最典型的就是序列化反序列化的时候记录的类名不符。这种是要出大事的。轻则 Cookie 报废，重则系统崩掉数据丢失。 |
Select Language