专案要不要重构，因专案规模、时机、文化而异。
以下是根据我个人开发经验的观点：
我认为重构需要考量三个要点：动机、时机、理由。
1. 动机：为什么需要重构
代码毕竟是工具，不是文学，能带来效益最重要。
要构成需求的强力条件是，安全性和耦合性。
当有具体新增功能需求的时候，修改原代码容易导致错误风险提高。
当功能需要删减的时候，原代码无法快速拆分，且预期有多处时。
需要多方协作，而原代码无法有效拆解，严重影响协同开放时。
代码过于复杂导致难以维护。
代码规模已经导致效能低落。
这些原因都是直接导致产品需求无法实现。
2. 时机：什么时候该做
不为太远的未来，而为不久的将来。
重构是为了可预见的功能拓展而做，不是为了不存在的以后而做。
当有功能拓展的可能性的时候，要规划重构，避免技术债累积。
当产品需求和定位还不确定的时候，以最有效率开发的方式做。
举例来说，开放解一元二次方程式的功能好了，
如果只是算法的一个步骤，直接一个函式搞定。
如果专案是要制作一个数学工具，那可重构可解N次的工具。
但如果动机是前者，却去重构成后者，就不是对的时机。
3. 理由：巧立名目
重构的特点是不改变原本功能，所以通常不具功劳。
所以要配合具体产品需求再做。例如：
需要增删改功能，需要重构不然做不到。
产品要做效能提升，需要重构不然会卡死。
专案需要开启合作，需要重构不然无法协作。
专案需要交接给营运，需要重构不然难以维护。
不过通常交接了谁跟你重构，吃力不讨好。
说白了，重构本质上是利他行为，愿意做的都是好人。
好处不在增加功劳，而是提升管理效率这种隐藏成本，
也没有一定要重构，而是取决于动机和时机，
取得一个有用和好维护的平衡。
至于要不要因为好读或好看而重构，我觉得不值得。
代码的原则归原则、模式归模式，满足很好，只要不影响开发效率。

不改没事，一改出事，才是真的麻烦！

推 讲得清楚

有经验的都知道改了超容易出事 一般底层别乱搞这种事情高层改出错可以主导整个重构事件找出问题 低层改出错高层只会觉得案子这么赶了你还在给我找麻烦

推

推

觉得解N次方程式的例子不错

确实 不论是改上层还是底层 只要不是同一个人写的就很容易出错 不过我想这可以是另一个主题了XD

先把旧code增加测试如何

楼上说得好，那么谁来提供测资例子

推推

测资当然是想重构的人想办法

重构成一坨 也可以再重构一次 工作永动机

呃...要改的东西太多了，那就改天吧

不是所有人都精通的，有重构专业的不一定有测资专业呀

真的要做好重构很精实 但是事倍功半 只是自己的修行

推

推