是的. 除非有完善的测试用例, 否则就是做砸的节奏.

分人吧。

我是看不懂别人的代码。

我领导是个看谁的代码都能很快看明白的一个神...

如果是简单的修改某个功能，我基本上不去了解整个项目架构，有些东西看看就知道了，如果是接手整个项目，那就会化大倍的时间去了解架构，需求等等

对原来的代码一知半解就想自己来重新来过，我觉得是不负责任的表现，甚至缺乏职业道德，因为原来的代码是老板投入的产出。

有的不需要理解，但如果要改动就必须去理解了，如果业务太复杂还不如试着去读懂原来的代码的，读懂后再改就轻松多了，再写一套可不是那么容易的，我是说时间上。

要真是归你负责, 还是及早的硬着头皮读读的好. 其实 看别人代码写的也挺有意思的. 尤其是那种用了N年的老系统,千万别提什么推倒重来. 小心驶得万年船.

我很少会在看不懂代码的时候去改bug，这个问题我在我的帖子里面说过了。说实在的，我认为因为看不懂所以推倒重来就是智商不够的表现。什么，不承认智商不够？那好吧，那就是懒到了乐意牺牲自己的前程的表现。

话说，在没有搞明白所有代码之前动手，是可以很快地写出解决当前问题的代码来，省下很多阅读那些看起来稀奇古怪甚至乱七八糟的代码的时间。但是，后面花在擦屁股上面的时间会远远超出你省下来的时间。很多时候人们有一个误区，那就是以为用新的简单的方式去实现，会比重构少犯错误——毕竟全新的嘛。然而现实是，很多你没看明白的代码，其实背后都是有一个个血淋林的场景在那里的。你的实现简单，很可能只是忽略了这种场景而已。“完整”的测试用例，在某些方面确实可以减少这种问题发生的几率，但是测试毕竟不是对一个问题的完整描述，有些问题用测试来描述是很困难的。读懂代码（并猜测背后的用意），其实是从另一个角度来达到“测试用例”相同的目的。

纯粹依靠测试用例来改Bug，在看不懂原有代码的情况下动手，其实跟我吐槽过的散弹枪思维本质上是一致的：先轰一枪，看看打中了些什么，然后再说。当然了，有测试案例在保障，能看到打中或者不该打中的东西，比用人肉眼来看是强太多了。或者打个比方，那就是用一只猩猩来改分头式导弹的导航系统，通过看是否打中地面的那几个目标（测试用例嘛），来看这只猩猩是否改对了导航系统。至于这只猩猩是否真的会改，啊，对不起，这不是重点。当然了，后面别人再来改的时候，一定会记恨你的。

无论有多难，总得搞清楚，否则苦难就像阴影一样，如影随形

重构的第一步是设计测试用例 第二部是给先有代码加上注释 即透彻理解现有代码的功能 所以看懂先有代码是重构必要的一步。