改 legacy code 改到想吐

简单，看不懂的代码给他删了

@lvdb #19 痛苦啊~~~~

自己写的代码, 当然知道怎么改. 好歹思路能相通, 大体规律自己心里有底.
但是读别人写的代码就不一样了, 看着难受是真的难受, 改不动的是真改不动...

总结起来就是不写注释就是坑. 就算代码写得再好、命名再规范再语义化, 读别人的代码时, 都会面临减智 30%的 debuff 的...

@lvdb 😂 有画面感了。地铁老人手机

我没见过哪个项目因为重构而复活的，要么中途放弃了，要么项目本身已经不行了，重构也没屌用甚至会把最后一口气给折腾没了

"新人和老人的区别就是面对一坨屎山，新人会大吃一斤。老人会贤淑的避开最臭的那部分屎，然后灵巧的在保证屎山不垮的情况下把自己的屎再拉一层上去"

最应该做的是最小代价修改

但我做不到，强迫症，只要我用过的代码肯定是一路重构过去，哪怕看到自己之前的代码，也会想：写的是什么玩意，明明可以更简单

改不动就跑呗，形成屎山的最大原因还不是这群领导不做代码审阅

我发现领导都有个共性，就是改改旧代码，工程就能以最低成本研发出来。

但是副作用，就是代码太长，日后很不好维护。

有时候自己写代码，会提醒自己要非常克制，尽量解耦。让简单代码变复杂，只需要无脑写就可以了。而让复杂代码变简单，那就是很困难的事情。

引用一句话：聪明的程序员，如果改不动现在 BUG ，就创造出一个没有 BUG 的新世界。

大部分(包括我自己)所谓重构就是堆新的屎山，这没什么稀奇的。但是自己拉的屎自己闻着香。

@wangtian2020 #6 修改前人写得烂尾项目，里面是漏洞百出的代码，同时给他修各种千奇百怪的 Bug ，这种工作意义究竟在哪？
别人问你工作是干什么，绝大多数人羞于说出口，因为实际上是给老板和他前员工生产的劣质产品做修修补补的，这种工作原本就不应该存在才对。

@sampeng 让自己和别人读着都舒服，都容易懂，这么难么

劝跑路的都是哥们儿~

我也在改
操了。

六年前的代码
估计是当时大环境问题
第三方接口返回都不判断 code

目前也在搞屎山，感觉一般是重写比改快……

一般要保证屎山能用，至少要同一个组里至少几个人审过看过。
这样至少是一堆人都能接受的屎，而不是一个人的屎。

新手才想着怎么去重构，老手只想着在不动屎山的前提下在上面再拉一泡屎

@7gugu @keepeye @JDog @zxjunz

各位说的都是不做大改，尽量保证不影响之前的，在巧妙地加新代码。说说我的分析。
这样做，肯定会导致越来越改不动，越是后人日子就越难过；不做大改，终将拖死大家。
如果在拖死大家之前，项目就因为别的原因黄了，那不用做大改，都一样。
如果是因为改不动，迭代太慢或者 bug 百出而导致项目黄，那就要考虑做大改了。
如果是因为开始大改，然后把自己改死，项目黄了，那只能说大改做得太晚了。
都劝我不大改，因为各方面都过硬，能坚持到最后的项目太少了。久经考验的项目没几个。