想当救世主
这种情结在电影电视剧上可能很常见吧。类似你来到一个新公司，这团如淤泥一般的代码，被你接手之后，马上神奇的绽放出光彩，然后你顿时赢得了别人的尊重，但是实际上真实情况是，新人进入一家公司，对老人报以各种不满和怨言，愤世嫉俗，看不惯这个，看不惯那个，觉得这个技术用的搓，那个设计差，然后慢慢的深入理解这个系统，这个新人满满的就会变成老人，开始明白为啥老人会这样。因为你的那点鸟优化，修改出来，影响简直九牛一毛。他们早都想过了，后来他们也是懒的折腾了。
实际的优化是一个很难的过程，没有从业务和技术深入理解一个系统的人，很难做出一个质变的优化，比如你吐槽python运算慢，gil全局锁，单进程不能利用多核，或是其他的，那只能说你从来都没有吐槽到点子上。很多人做事都是自己知道什么做什么，而不是分析当前局势在做，这也就是为什么有些人看着博学其实一事无成，因为他们只能以他们理解的方式去思考问题。
丑陋的代码
要么是你之前为了赶进度，自己写的傻逼代码，然后标识了一个TODO，打算将来做，当然这就是个谎言。
要么就是你看见别人写的傻逼代码，然后忍不住大改一番。
当然你觉得别人的傻逼的代码，很有可能就是pm催着他加需求，然后rd信手拈来的。
那句话怎么说来着，你看众人皆傻逼，众人看你如是乎。你觉得你写程序屌，可能另一个人并不以为然。
实际上很多代码都是因为进度的原因强推上去的，这些看似不合理的代码，其实非常合理。
因为侧重点不一样，你看到github，那些所谓美观的代码，本来就是为了给人看的，那么写起来自然美观大方，结构清晰。但是业务代码本来就是以使用为主的，当然不用太好看。而且对于比较大的工程，比如企业级开发等等，这些项目的主框架设计好了，即使内部代码写的在烂也没有问题，有那个闲工夫优美代码，不如多写单测，提高覆盖度了。看似重构让代码可读性增强使其易维护和提高单测的覆盖度，两者都有用，但是为啥工程代码偏向第二种？因为这种成本低！能够有制定指标和流程化的东西，自然操作起来容易。就像你和一个人比较，你要比他牛逼，那就学生比学习，工作比收入吧，简单粗暴的进行了比较和区分。但是你要是比善良，比性格，比快乐，那特么怎么比。你说你代码写的好，封装的好，这也许能验证，但太难了吧？
还有一个原因是业务代码不好封装，实际上业务这个东西，不像是什么ui，或者标准库，你能把它们标准化，或者是数学化，来把它们建模。如果可以，那ok没问题，你一定能建立良好的抽象和封装，但是业务代码不是让你推倒github上的，不需要美观，也不需要用各种牛逼的装饰器或者元编程，因为看你代码的人，也不是写标准库那群牛逼的人。
如何重构
就算是封装，很多程序员也不会封装，他们打着“封装”的旗号，写了一大堆鸟函数，你从命名上就可以看出，都叫什么”gen_data“, “parser_data”。
那么好的封装是什么？你要进行业务级别的封装啊，这个我之前的博客讨论过了，在不讨论此事。
我来公司接手的一个python项目，动态变量各种包之间引用（我在之前的博客提到过，应该在一个统一的地方初始化这些变量，然后作为单例使用），写一个单测麻烦的要死。所有业务逻辑，一个handler到底，那么我怎么“重构的”？我只挑出了比较容易出错的几个业务（注意不是所有），把他们封装成函数，对于上下文，我怎么做？我把这些上下文都“塞给”一个参数去，然后我就初始化这个参数，然后就写单测了。简单又粗暴。
所以我现在接手的这个项目，基本上没有做什么本质的优化，我只改过一些就是把一些重复的代码移动到一个基础库去了，因为实在是太麻烦了。
在最多就是改改代码结构，能够更快的响应需求，或者发现几个极微小的bug，实质上，就算是优化都是跟业务挂钩的，而非技术本身。
我只能干这些
很多人为什么拿到代码就喜欢修改命名变量，调整代码结构，因为他们只能干这个。
这个甚至类比于某些pm的某些需求，有的人做产品，动不动就换ui，实际上交互设计和ui美观是一个大公司为了提高门槛而做的一件锦上添花的事，不是每个公司都有资本这么做，而且也不一定能做好。
所以其实很多人说的，“我把代码重构了一遍”，他们说的是什么呢?实际上，他们就是把代码重写成为他们能够理解的样子，这样呢，他们维护起来也比较容易方便。仅此而已。所以下一个人来了之后，还要再重构。
也就是说你重构只是为了让自己看上去很忙，在做很多事情而已。实际上却是没有特别的意义。
我理解的重构，最起码要么你重构了，要真实的解决使用上的问题，比如现在的效率慢了，你重构了之后，对于效率提升了一些，或者重构了之后，你在扩展新的功能方便了一些，或者测试起来方便了很多。
当然我见过很多人，来的时候说要大干一场，然后半途而废，有的甚至慌张的就跑了。
怎么说呢，一个系统跑了这么久，本身就有很多的“智慧”在里面，她被qa测过、用户验证过。最起码是稳定的，你想到的那些优化点，别人早都想到了，要么是受益太小，要么是实践太复杂而已
成本博弈
其实那些在公司的老人本身也不愿意把代码写的很好，为什么？因为他们想让问题暴露的时候再改，为什么会这样，因为这样才能体现出价值啊，否则你什么都做得很好，这样只会让别人觉得一切都是理所应当的。从开发成本上考虑，业务系统这么烂是理所应当的。你看数据库，和标准库，这些基本都没bug，为啥，因为他们进行了大量的测试，而且写标准库的这些人，他们对编程都理解的很透彻，数学学的好，代码非常严谨。你看数据库，为了维护数据的一致性。衍生出一大堆复杂的概念，这就是成本和门槛。我们的业务系统之所以动不动数据错了，比如我之前有个限价的服务，动不动限制不住了，原因是什么？就是因为数据不一致。那么如何设计的严谨，照着数据库那一套来设计？呵呵，你考虑过成本么。