重构

前言: 做开发多年，对于技术债的问题也深有体会。此文描述了一般情况，值得记录。 方案：紧急重要、紧急不重要、重要不紧急、不重要不紧急的划分。随着业务的推进不断偿还债务。 价值收益角度:“继续维护的收益”和“重写的收益”哪个更大？ ----------------------------------------------------------------------------------------------------------- 近日，Reddit 上有关 技术债务 的话题再次引起程序员的广泛讨论，面对由错误的或不理想的技术决策所累积的债务，程序员到底是该继续维护还是推倒重写，这个决定应该依据哪些因素来最终决定？如何避免在技术债务上浪费过多时间？本文，InfoQ 针对这一话题采访了多位国内技术从业者，试图对这一问题进行深入剖析。 你在写技术资产还是技术债务？ 技术债务 是由 Ward Cunningham 在 1992 年的报告中创造的比喻，被定义为当我们有意或无意地做了错误的或不理想的技术决策所累积的债务。简单来说就是为了快速解决问题而采取的不规范方案，比如开发工程师将某个判断条件写死、测试工程师未进行深入自动化测试、架构师运用了一个即将过时的框架。 对任何一家公司而言，在不断发展的过程中会出现很多“技术遗产”，这其中的部分遗产没有文档，甚至连注释都语焉不详

什么样的代码才是美的代码？一千个coders可能会给出一千个答案。今天，让我从一个简单的角度来谈谈对于代码之美的理解。 可读性高的代码才有可能是美的代码 相信大家都有过这样的经历：接手一个项目要修复bug或者开发新功能的时候，发现代码可读性非常差。哪怕是在有说明文档的情况下，都不太敢提交代码，唯恐引入新的bug或者直接导致系统崩溃。 软件系统在代码方面的成本分为两部分，第一部分是开发成本，第二部分是维护成本。 开发成本很好理解，就是把一个系统开发出来需要支付的各种成本，其中最大一块很可能是人力成本。任何一个大型软件系统都不可能没有bug。系统开始运作之后，这些bug可能会导致业务出错、运行缓慢，甚至是宕机，需要程序员找出漏洞并且修复上线。在这一阶段的成本，我们称之为维护成本。 运维成本往往会超过开发成本。我毕业后的第一份工作是在一家ERP公司做二次开发，最早的代码注释时间有十几年前的，常年从事维护开发工作的人员超过十个人。开发需要的时间远比维护的时间要短得多，维护人员的数量并不会比开发人员的数量要少太多。 如果适当增加开发成本可以大幅减少维护成本，那么对节省整体成本有着极大的帮助。 在进入到互联网时代的今天，像ERP这样开发完成之后变化不大的“重”系统已经不多了，模块化、服务化的“轻”系统已经占到绝大多数。这些现代软件系统强调的是迭代开发，以月或者周为单位更新版本