楼主，一根筋这种解法是不存在的，没有永动轮。
反倒是，只用轮子，不了解轮子，最终会导致技术水平原地踏步。
解决问题的核心是熟练运用编程语言的各种特性，了解优劣，才能选择最佳方案。
想清楚这点，就明白为什么会有“低质量的代码”，以及为何需要重构了。

首先优化的前提是基于现有的业务和现有的瓶颈，但是业务是不断变化的，你不可能优化正在变化的业务，很多时候你觉得现在合理的事情，也就现在合理，日后并不合理。后来人根据后来的情况再看你现在“已经基于现状优化好的代码”，情况也会有所不同。

所以，一般来说，业务优化都是当业务沉淀了一段时间后，再回过头来看，哪些地方不合理，哪些地方需要变得合理。在大多数情况下（请注意，是大多数情况下），现在看起来低质量业务的代码，不是前人的技术问题，而是当时的最优解。因为对于软件工程来说，项目完成时间永远是第一考量，其它指标靠后。

V2 的老帖子有一句名言：“这是一个创建于 xxx 天前的主题，其中的信息可能已经有所发展或是发生改变。”