今天读到一篇很有意思的文章

    你永远不应该做的事

    对于重写,这个词可能是我听到过最多开发以及经理在遇见项目瓶颈时提到的.

    当作为旁观者经历过几个项目的起落之后

    我越来越深刻的感觉到程序员以及经理提到重写是基于以下几个理由

    1.对完全理解原有代码的恐惧

    2.作为拖延项目完成时间的借口

    3.希望表现自己的能力,觉得自己重新写比修复别人的工作更有挑战性与创造性

    4.不了解重构

    而上级能够采纳重写意见一般是基于

    1.原有项目时间拖延太长,修改难度越来越高,修复时间似乎是非线性增长的.

    2.所有程序员都建议重新再来,没人愿意进行修复原有代码的工作

    问题在于

    当你不能够理解以及改善破败代码的时候

    你凭什么能够认为能够写出一个功能一致并且更清晰的软件呢?

    首先你认为原来的代码已经是破败不堪,散发着腐败的臭味

    你不能够靠读他去理解他,因为写的太烂了

    但是你如果不读他.你又如何能理解他干了什么呢?

    凭借着从头开始进行复制策划文档

    你又可能忽略多少隐藏在破败代码沟壑中的细节点呢?

    这些细节点必然会复现,直到你重新遇见问题.找到它,修补它

    当你没有能力修整一个破败代码的话

    你修补这些细节之后的代码也会是破败的.

    当你无法理解别人破败代码

    最终你也无法理解你自己写出来的破败代码

    重构不是什么高深的技艺.但它需要磨练

    但是我遇到很多人.都不会去修炼这项技能

    迫于项目压力或者惰性

    以及古老工匠守则的规劝:”当一个事物运行正常的时候,不要碰它”

    和测试一样,至今程序员都没有把测试行为和代码结合在一起来做.

    手工作坊式的做法至今仍在.

    当然作坊式的手法有其优点

    不过既然你已经是靠手艺吃饭

    那么重构的手艺以及测试的手艺才是我们需要加强的

    而不是继续锻炼靠运气编程的手艺

建议继续学习：

1. 抵制代码重写    (阅读：4246)
2. 如何避免重构带来的危险    (阅读：3703)
3. 什么是重构，什么不是重构    (阅读：3481)
4. 前端重构实践（一） —— 性能优化    (阅读：3171)
5. 实践中的重构    (阅读：3036)
6. 网站重构到底是什么，网站重构到底要多久    (阅读：2916)
7. 重构发现：指针操作问题    (阅读：2389)
8. 网页重构应该避免的10大 CSS 糟糕用法    (阅读：2237)
9. 实战遗留代码    (阅读：1785)
10. 代码重构方向原则指导    (阅读：1626)