打工人手册 #91 重构1/3
打工人手册 #91 重构1/3
重构1/3，不变1/3，删除1/3
这才是最好的重构方式，如果一上来就想重写。你大概率会陷入泥沼。
历史的代码里面，有很多精华。边界条件，已经深入优化过的逻辑，一步步迭代得到的符合用户需要的功能。
很多公司都在重写的路程中死掉了。例如最著名的网景公司，他们当时和IE争夺市场，但是他们觉得之前太多代码已经不符合需要，架构也很陈旧。于是他们决定重写整个系统。结果就是，他们永远的输掉了IE的战争。
很多重写是因为，开发人员就是不愿意花时间看代码，而更愿意自己造一个新的东西。
你看不惯旧代码，于是想要打造一个新的，但是很快就会发现，你打造的这个新的，很多时候也没有那么快，没有那么好。
于是之前的大师总结了一个经验，“永远不应该重新开始写”。
有一篇文章《Rewrite-Refactor-Reinvent》写的特别好。又把这个经验升华到新的高度，告诉你什么时候可以重构，什么时候可以重新发明。
之前我已为自己看懂了这篇文章，但是最近的一个Case告诉我，我其实没有看懂。
这是一个新的领域，不发生在自己上，总觉得OK。总觉得，自己可以重写，自己已经手握魔戒，即将给某一产品带来彻头彻尾的改变。
但是真正写起来，就会发现，前人所言，字字血泪！
重构1/3也不应该一次性重构，而是每次5%，或者更小，一点点，一步步，向你的目的地迁移。
例如现在很流行的，用Rust来重写一些逻辑，那么，你可以将最影响效率的部分，先逐步用Rust替换掉。很有可能当最影响效率的部分已经被替换好后，最核心的问题其实已经被解决了。
这个方法论像是，引入一个新的核心。老的核心不是一下子下掉，而是两者共存，一点点的新核心融入老核心，最后某一天把老核心摘掉。
变飞边换发动机。脚手架。
如果你提前测量过你的程序，这种重构你会做的更好。20%的代码，占据80%的时间。
你的调整就是有的放矢。很快你会发现，你之前想要重写的念头，是多么可笑。因为你把核心部分问题解决后，整个项目看起来不再是那么面目可憎。
项目也有了新的心脏，迸发出新的能量。
而删除1/3则是最后的收尾工作，也就是当老核心发挥越来越小的那一天，你就可以将他全部摘除。这一步主要是为了去除冗余，减少未来的心智负担。
