【代码重构（Refectoring）系列教程 基本概念一】干净的代码（Clean Code)和技术债（Technical debt）

干净的代码

  重构的主要目的就是为了消除科技债。代码重构会将一团乱的代码变得干净，使代码的设计结构变得简单。
  不错！但是，到底什么是干净的代码呢？它具有以下的特点。

🌝干净的代码对于其它程序员是清晰的
  这里并不是针对与非常复杂的算法而言。糟糕的变量命名，臃肿的类和方法，奇怪的数字等等，这些你能想到各种地方都会让代码变得臃肿且难以理解。

🌝干净的代码不该包含重复段
  只要你需要对某一处重复的地方进行修改，你就要对它每一个重复的其它的地方进行相同的修改。这增加了认知负载，并且减慢了开发的进程。

🌝干净的代码拥有最少的类以及其它可移动部分
  更少的代码意味着要记住更少的东西。更少的代码意味着更少的维护。更少的代码意味着更少的bugs。代码就意味着责任，尽量让它简短且简单。

🌝干净的代码可以通过所有的测试用例
  你知道的，当你的只通过了95%的测试用例的时候，你的代码就是不干净的；当你测试覆盖范围只有0%的时候，事情就被搞砸了。

🌝干净的代码更加简单，更加易于维护。

技术债

  每个人最开始就会努力写优秀的代码。可能没有任何一个程序员会故意写出不干净的代码来搞坏他的项目。那什么时候干净的代码会变成不干净的呢？
  Ward Cunningham是最早使用技术债来隐喻不干净的代码的人。
  如果你向银行贷款，这会让你更快能购买你想要的东西。但是你要为此付出额外的代价：你不光要归还本金，还要偿还贷款所带来的利息。毋庸置疑，你甚至可能累计过多的利息，这些利息超过了你的收入，使你的无法还清贷款。
  相同的事情可以发生在代码上。你可以暂时通过不对新的需求编写测试用例来加速你的编码速度。但在你最终编写好测试用例来偿还你的技术债之前，你每一天都会被技术债拖慢你的进度。

技术债产生的原因

🌚业务压力
  有时业务环境的压力会迫使你在还没完全开发完新的需求的时候就推出它。在这种情况下，代码中会使用补丁包和组装软件去掩盖项目中未完成的部分。

🌚没有意识到科技债可能产生的后果
  有时你的老板可能意识不到科技宅的后果，因为随着时间的发展，科技债对开发进度的阻碍才会逐渐加剧。这就会导致管理者很难给开发团队分配用于代码重构的时间，因为他们看不到代码重构所带来的价值。

🌚无法抵御组件间严格的相关性
  这种情况发生在整个项目更像一个整体而不是单个模块的产物。在这种情况下，任何一个部分的改变都会影响到其它地方。团队协作的开发又使得将任务分配给不同的人变成了一件很难的事。

🌚缺少测试
  编程时缺少及时反馈会导致快速的，但存在风险的变通或者拼凑。最差的情况是，某些改动在没有任何测试的情况下就被执行和部署了。这样做的后果是灾难性的。比如，一个看似无辜的程序修复可能会给上千的顾客发送邮件，甚至覆覆盖或者毁掉了整个数据库。

🌚缺少文档
  这会拖慢项目新成员熟悉这个项目的过程。并且当项目核心成员离开项目的时候，会使得整个项目陷入停滞。

🌚项目间成员缺少沟通
  如果项目的基础知识没有在公司内部得到传播，那么项目成员最后会在缺少对项目流程的理解以及项目的基本知识的情况下工作。当新的开发者受到了他们倒是不正确的引导时，这种情况会被加剧。

🌚长期同时对几个分支进行维护
  这种情况会导致科技债的堆积，在改动被合入的时候科技债会被加剧。被单独开发的改动越多，科技债会越严重。

🌚被推迟的重构
  项目的需求经常会被改动。显而易见，某些部分的代码在某些情况下变得繁杂，需要被遗弃，并且必须被重新设计来满足新的需求。
  另一方面，项目的开发人员每天都会在存在着要被淘汰的代码的项目中编写新的代码。因此，要被重写所依赖的代码会随着重构的推迟而越来越多。

🌚缺乏规范性监管
  这经常发生在当项目的每一个成员都按照他们自己认为合适的方式（比如他们开发上一个项目的方法）进行开发的时候。

🌚能力不足
  开发人员不知道如何写出规范得体的代码。