这是一个创建于 4290 天前的主题，其中的信息可能已经有所发展或是发生改变。
有的地方已经不得不那样写了。我是跟着烂下去，图省事；还是要慢慢重构。
 |
1
saharabear 2013-02-28 12:24:36 +08:00
给它重构,然后拍屁股走人.
|
 |
2
Js 2013-02-28 12:35:53 +08:00
跟着烂下去
|
 |
3
dreampuf 2013-02-28 12:38:24 +08:00  2
用哪儿改哪。
此外问题如下： - 你确定他真的烂？烂在哪里，团队里的人怎么看？ - 你如何确保你不会给出烂的实现？团队里的人愿意接下并维护你的实现？ - 区分重写和重构，然后再向团队说明是否可接受其代价 |
 |
4
yimity 2013-02-28 12:43:18 +08:00
我的代码也很烂，求指点啊。
|
 |
5
ceyes 2013-02-28 12:45:20 +08:00 1
首先你要确定原来的代码能用不? 能稳定工作的话就不要自找麻烦了.
重构风险很大, 因为1.上司会认为你在用工作时间做没有意义的事情. 2.本来代码就很烂 重构当然很困难. 3.重构必然会带来 bug. so ... 自己斟酌吧 当然最好的方案是 把情况反应给上司 他也觉得不重构 会毁掉项目 然后暂停进度 组织重构。 千万要注意其中的责任区分 必须把问题推给上司 别自己好心办了坏事。 |
 |
6
darasion 2013-02-28 12:47:50 +08:00
那你就应该写更烂的来对付他们.
|
 |
7
summic 2013-02-28 13:02:25 +08:00 via iPhone
在kpi层面算下投入与回报，如果无法全面重构，起码保证你继续写的代码不那么烂，甚至一点一点吞噬烂代码。
能赚钱的代码就不是烂代码 |
 |
8
walleve 2013-02-28 13:13:31 +08:00
低头工作，好好写代码，然后干好自己的活，努力做好。。。拿到相应报酬。不要埋怨
|
 |
9
cubepeng 2013-02-28 13:16:52 +08:00 1
不要尝试去重构，码农的职责就是让程序能正常运行，写的好看不管用！
|
 |
10
hanks315 OP 谢谢回复，基本了解了，我觉得自己是从重写开始，先确保自己的代码好维护
|
 |
12
wenbinwu 2013-02-28 17:08:32 +08:00
把自己新写的代码写好了先
|
 |
13
alexrezit 2013-02-28 17:38:20 +08:00
看烂到什么程度. 如果已经烂到改一个功能都要读半天去理解作者的奇葩逻辑的话还是重写比较好.
|
 |
14
veggie 2013-02-28 18:09:08 +08:00 1
没有冲动去重构的话，说明这个项目不够吸引你，也看不到未来，那就赶紧走人吧
|
 |
15
jkeylu 2013-02-28 18:20:12 +08:00 via Android
保证自己的不烂就行，但是有时候你不得不烂，除非你能够在用新写代码的时间里同时重写你觉得烂的地方并同时也保证正确性，并承担一定风险，不然还是放弃吧，让它继续烂下去
|
 |
16
ewangke 2013-02-28 18:54:58 +08:00
不理解什么是烂，能正确工作可以快速响应需求的代码绝不是烂代码。
不管你重构或重写，都是回归测试吧？成本是团队埋单。 团队>产品>代码，如果代码在你心中是第一位，我建议你调整一下看问题的角度。 建议楼主把问题暴露出来，大家一起想办法，做一个最佳决定。 |
 |
17
greatghoul 2013-02-28 19:04:45 +08:00 1
你重构一下，然后走人。然后后面接手你工作的同学也来这里发一个同样内容的帖子。
|
 |
18
yun77op 2013-02-28 19:58:08 +08:00
该项目还有生命力的话，”破窗理论“ 不要容忍糟糕代码，维护是开发过程中的例行事物，当然要写好测试，保证是可靠的
花多少时间去重构又是另一回事，一般情况下比如抽20%的时间重构，极端情况下上级或团队完全不认可的话就没办法了 |
 |
19
aurorawu 2013-02-28 22:39:38 +08:00
要是刚参加工作的我绝对会自己重构，现在的我只会把自己的工作做好之余再去考虑这些。btw,你是怎么确定代码很烂的？代码写的“烂”的人多了去，你的标准是什么？程序跑起来没有影响就OK啦！
|
 |
20
diib 2013-02-28 23:19:18 +08:00 via Android 1
bug几乎没有，效率又能满足需求，就不能称为烂代码。用心做好自己掌控范围内能做的，多看多想自己范围之外的，但是一定要少说。
|
 |
21
zhuoqun 2013-02-28 23:50:05 +08:00
|
 |
22
dreamtale 2013-03-01 09:28:15 +08:00
先搞清楚之前的需求，还是不要着急重写
|
 |
23
xiluo 2013-03-01 09:49:21 +08:00
如果和refactoring, clean code之类的书有冲突的代码就可以被认为是“烂”，和普遍的编程规范相矛盾的可以叫做“更烂”，写出一天之后自己都无法理解的代码也可以叫“太烂”。
@zhuoqun 君列的文章中说的烂显然不是上述情况。 |
 |
25
fork3rt 2013-03-01 10:36:56 +08:00
废寝忘食一个月去重构吧。。 我就是这样
|
 |
26
yylzcom 2013-03-01 10:44:09 +08:00
如果确定真的很烂……
维护好的同时，进行重构，确保能无缝对接，这是最稳妥的 |
 |
27
wangsd 2020-03-25 14:16:53 +08:00
除非时间真的很充裕很充裕，否则不要轻易去改那些正常跑的代码，代价太大，而且你一开始是不知道这个坑有多深的，别掉进去爬不出来了。
|
Select Language