你需要的不是重构,而是理清业务逻辑
2013-05-22 13:43
309 查看
首先说明我转这篇文章,不是因为这篇文章说得完全正确,而是对想做重构的人一个很有用的提醒,重构应该根据业务进行重构!
================================================================================
最近我遇到了一位以前公司的同事。他提到了数年前我在那个公司曾经开发过的项目。他说这个项目现在已经变成了“职业杀手”。基本上,任何接触过这个“职业杀手”项目的人最终都会离开这个公司。如果公司想让名下的程序员人数>0,唯一的办法就是花数月时间完全重构这个系统。
对于这事我有两点要说。首先,在我离开这个公司前,这个系统的单元测试覆盖率已经达到了85%,所以,不要责备我。第二,这么大规模的重构?肯定会出问题。
每一个系统里都至少有一个成为人民公敌、让所有人害怕的组件。它承载了太多的任务,它拥有太多状态,太多的其它组件调用它。当时间到了偿还技术债务的时候,人人都会把目光投向这个组件。然而,如果你对这个组件只有一个不全面的理解,你放下所有工作来完全重构它,那你成功的几率会很小。这个组件,就就它表现出来的令人恐怖的程度和复杂相比,它的实际情况会比你想象更复杂,更恐怖。
你认为这个组件是如何发展成这样一个不幸的状态的?是因为公司雇用了一个笨蛋,让他肆无忌惮的往系统里增加复杂度?或是因为这个组件最初设计的太抽象,由于多年来需求的变更,它的责任范围不断的扩大?(出于个人的自尊,我宁愿相信这个“职业杀手”属于后者)。十有八九,这个组件变成如今这个恐怖的状态,都有由“聪明人”的一些“好意”造成的。如果你决定做一次大的重构,你实际是欠下了另一笔技术债务留给后人。
为了能真正的彻底偿还这笔债务,你需要去分解这个系统的复杂度。你需要花时间寻找所有调用这个组件的客户端。你需要花时间跟你的同事交流,了解这个这个组件的历史和它是如何被使用的。你需要简化这个组件的周边环境,看看它是如何运作的。每周,你都需要花更多的时间来更清楚的了解这个组件的业务。只要有足够长的时间跨度,你最终能理清所有复杂的问题。
从实际方法上说,这个问题应该怎么办?与其现在花3个整月的时间做一次完全的重构,不如先用一个季度的时间做清理工作。最后还是要重写,但有了3个月的计划准备,你有了时间去分析和设计。你有了时间来理清业务。
================================================================================
最近我遇到了一位以前公司的同事。他提到了数年前我在那个公司曾经开发过的项目。他说这个项目现在已经变成了“职业杀手”。基本上,任何接触过这个“职业杀手”项目的人最终都会离开这个公司。如果公司想让名下的程序员人数>0,唯一的办法就是花数月时间完全重构这个系统。
对于这事我有两点要说。首先,在我离开这个公司前,这个系统的单元测试覆盖率已经达到了85%,所以,不要责备我。第二,这么大规模的重构?肯定会出问题。
每一个系统里都至少有一个成为人民公敌、让所有人害怕的组件。它承载了太多的任务,它拥有太多状态,太多的其它组件调用它。当时间到了偿还技术债务的时候,人人都会把目光投向这个组件。然而,如果你对这个组件只有一个不全面的理解,你放下所有工作来完全重构它,那你成功的几率会很小。这个组件,就就它表现出来的令人恐怖的程度和复杂相比,它的实际情况会比你想象更复杂,更恐怖。
你认为这个组件是如何发展成这样一个不幸的状态的?是因为公司雇用了一个笨蛋,让他肆无忌惮的往系统里增加复杂度?或是因为这个组件最初设计的太抽象,由于多年来需求的变更,它的责任范围不断的扩大?(出于个人的自尊,我宁愿相信这个“职业杀手”属于后者)。十有八九,这个组件变成如今这个恐怖的状态,都有由“聪明人”的一些“好意”造成的。如果你决定做一次大的重构,你实际是欠下了另一笔技术债务留给后人。
为了能真正的彻底偿还这笔债务,你需要去分解这个系统的复杂度。你需要花时间寻找所有调用这个组件的客户端。你需要花时间跟你的同事交流,了解这个这个组件的历史和它是如何被使用的。你需要简化这个组件的周边环境,看看它是如何运作的。每周,你都需要花更多的时间来更清楚的了解这个组件的业务。只要有足够长的时间跨度,你最终能理清所有复杂的问题。
从实际方法上说,这个问题应该怎么办?与其现在花3个整月的时间做一次完全的重构,不如先用一个季度的时间做清理工作。最后还是要重写,但有了3个月的计划准备,你有了时间去分析和设计。你有了时间来理清业务。
相关文章推荐
- 你需要的不是重构,而是理清业务逻辑
- 你需要的不是重构,而是理清业务逻辑
- 你需要的不是重构,而是理清业务逻辑
- 你需要的不是重构,而是理清业务逻辑
- 你需要的不是重构,而是理清业务逻辑
- 你需要的不是重构,而是理清业务逻辑
- 你需要的不是重构,而是理清业务逻辑
- 你需要的不是重构,而是理清业务逻辑(转)
- 软件开发人员需要的不仅是技术,也不是文档,也不是管理,而是……
- 这个例子看完,发现不是神马代码都需要重构
- Python 最近因开发项目的需要,有一个需求,就是很多SNS网站都有的通过 Email地址 导入好友列表,不过这次要导入的不是Email 列表,而是QQ的好友列表。 实现方式: 通过goog
- 我的Spring之旅(三):重构业务逻辑
- 恋人分手后需要做的不是挽回而是二次吸引
- 专访范钢:重构不是阳春白雪的高端玩意,而是码农编程利器(转)
- 重构不是阳春白雪的高端玩意,而是码农编程利器
- 越来越感觉到一个人越来越感觉到一个人的寂寞了,我需要的不是爱情,而是一个知心人
- Batch Normalization的算法本质是在网络每一层的输入前增加一层BN层(也即归一化层),对数据进行归一化处理,然后再进入网络下一层,但是BN并不是简单的对数据进行求归一化,而是引入了两个参数λ和β去进行数据重构
- 有时间,影响你开发效率的并不是复杂的逻辑,而是你忽略的细节和差的编程习惯
- 恋人分手后需要做的不是挽回而是二次吸引
- UI组件库不是固化的,而是开放性的(需要根据WebApp的独特需要做个性化修改)