TranslateProject/published/20160826 Forget Technical Debt —Here'sHowtoBuild Technical Wealth.MD

忘记技术债务 —— 教你如何创造技术财富
===============

电视里正播放着《老屋》节目，[Andrea Goulet][58] 和她的商业合作伙伴正悠闲地坐在客厅里，商讨着他们的战略计划。那正是大家思想的火花碰撞出创新事物的时刻。他们正在寻求一种能够实现自身价值的方式 —— 为其它公司清理<ruby>遗留代码<rt>legacy code</rt></ruby>及科技债务。他们此刻的情景，像极了电视里的场景。（LCTT 译注：《老屋》电视节目提供专业的家装、家庭改建、重新装饰、创意等等信息，与软件的改造有异曲同工之处）。

“我们意识到我们现在做的工作不仅仅是清理遗留代码，实际上我们是在用重建老屋的方式来重构软件，让系统运行更持久、更稳定、更高效，”Goulet 说。“这让我开始思考公司如何花钱来改善他们的代码，以便让他们的系统运行更高效。就好比为了让屋子变得更有价值，你不得不使用一个全新的屋顶。这并不吸引人，但却是至关重要的，然而很多人都搞错了。“

如今，她是 [Corgibytes][57] 公司的 CEO —— 这是一家提高软件现代化和进行系统重构方面的咨询公司。她曾经见过各种各样糟糕的系统、遗留代码，以及严重的科技债务事件。Goulet 认为**创业公司需要转变思维模式，不是偿还债务，而是创造科技财富，不是要铲除旧代码，而是要逐步修复代码**。她解释了这种新的方法，以及如何完成这些看似不可能完成的事情 —— 实际上是聘用优秀的工程师来完成这些工作。

### 反思遗留代码

关于遗留代码最常见的定义是由 Michael Feathers 在他的著作[<ruby>《高效利用遗留代码》<rt>Working Effectively with Legacy Code</rt></ruby>][56]一书中提出：遗留代码就是没有被测试所覆盖的代码。这个定义比大多数人所认为的 —— 遗留代码仅指那些古老、陈旧的系统这个说法要妥当得多。但是 Goulet 认为这两种定义都不够明确。“遗留代码与软件的年头儿毫无关系。一个两年的应用程序，其代码可能已经进入遗留状态了，”她说。“**关键要看软件质量提高的难易程度。**”

这意味着写得不够清楚、缺少解释说明的代码，是没有包含任何关于代码构思和决策制定的流程的成果。单元测试就是这样的一种成果，但它并没有包括了写那部分代码的原因以及逻辑推理相关的所有文档。如果想要提升代码，但没办法搞清楚原开发者的意图 —— 那些代码就属于遗留代码了。

> **遗留代码不是技术问题，而是沟通上的问题。**

![](https://s3.amazonaws.com/marquee-test-akiaisur2rgicbmpehea/H4y9x4gQj61G9aK4v8Kp_Screen%20Shot%202016-08-11%20at%209.16.38%20AM.png)

如果你像 Goulet 所说的那样迷失在遗留代码里，你会发现每一次的沟通交流过程都会变得像那条[<ruby>康威定律<rt>Conway’s Law</rt></ruby>][54]所描述的一样。

Goulet 说：“这个定律认为你的代码能反映出整个公司的组织沟通结构，如果想修复公司的遗留代码，而没有一个好的组织沟通方式是不可能完成的。那是很多人都没注意到的一个重要环节。”

Goulet 和她的团队成员更像是考古学家一样来研究遗留系统项目。他们根据前开发者写的代码构件相关的线索来推断出他们的思想意图。然后再根据这些构件之间的关系来做出新的决策。

代码构件最重要的什么呢？**良好的代码结构、清晰的思想意图、整洁的代码**。例如，如果使用通用的名称如 “foo” 或 “bar” 来命名一个变量，半年后再返回来看这段代码时，根本就看不出这个变量的用途是什么。

如果代码读起来很困难，可以使用源代码控制系统，这是一个非常有用的工具，因为它可以提供代码的历史修改信息，并允许软件开发者写明他们作出本次修改的原因。

Goulet 说：“我一个朋友认为提交代码时附带的信息，每一个概要部分的内容应该有半条推文那么长（几十个字），如需要的话，代码的描述信息应该有一篇博客那么长。你得用这个方式来为你修改的代码写一个合理的说明。这不会浪费太多额外的时间，并且能给后期的项目开发者提供非常多的有用信息，但是让人惊讶的是很少有人会这么做。我们经常能看到一些开发人员在被一段代码激怒之后，要用 `git blame` 扒代码库找出这些垃圾是谁干的，结果最后发现是他们自己干的。”

使用自动化测试对于理解程序的流程非常有用。Goulet 解释道：“很多人都比较认可 Michael Feathers 提出的关于遗留代码的定义。测试套件对于理解开发者的意图来说是非常有用的工具，尤其当用来与[<ruby>行为驱动开发模式<rt>Behavior Driven Development</rt></ruby>][53]相结合时，比如编写测试场景。”

理由很简单，如果你想将遗留代码限制在一定程度下，注意到这些细节将使代码更易于理解，便于在以后也能工作。编写并运行一个代码单元，接受、认可，并且集成测试。写清楚注释的内容，方便以后你自己或是别人来理解你写的代码。

尽管如此，由于很多已知的和不可意料的原因，遗留代码仍然会出现。

在创业公司刚成立初期，公司经常会急于推出很多新的功能。开发人员在巨大的交付压力下，测试常常半途而废。Corgibytes 团队就遇到过好多公司很多年都懒得对系统做详细的测试了。

确实如此，当你急于开发出系统原型的时候，强制性地去做太多的测试也许意义不大。但是，一旦产品开发完成并投入使用后，你就需要投入时间精力来维护及完善系统了。Goulet 说：“很多人说，‘别在维护上费心思，重要的是功能！’ **如果真这样，当系统规模到一定程序的时候，就很难再扩展了。同时也就失去市场竞争力了。**”

最后才明白过来，原来热力学第二定律对代码也同样适用：**你所面临的一切将向熵增的方向发展。**你需要与混乱无序的技术债务进行一场无休无止的战斗。随着时间的推移，遗留代码也逐渐变成一种债务。

她说：“我们再次拿家来做比喻。你必须坚持每天收拾餐具、打扫卫生、倒垃圾。如果你不这么做，情况将来越来越糟糕，直到有一天你不得不向 HazMat 团队求助。”（LCTT 译注：HazMat 团队，危害物质专队) 

就跟这种情况一样，Corgibytes 团队接到很多公司 CEO 的求助电话，比如 Features 公司的 CEO 在电话里抱怨道：“现在我们公司的开发团队工作效率太低了，三年前只需要两个星期就完成的工作，现在却要花费12个星期。”

> **技术债务往往反映出公司运作上的问题。**

很多公司的 CTO 明知会发生技术债务的问题，但是他们很难说服其它同事相信花钱来修复那些已经存在的问题是值得的。这看起来像是在走回头路，很乏味，也不是新的产品。有些公司直到系统已经严重影响了日常工作效率时，才着手去处理这些技术债务方面的问题，那时付出的代价就太高了。

### 忘记债务，创造技术财富

如果你想把[<ruby>重构技术债务<rt>reframe your technical debt</rt></ruby>][52]  — [敏捷开发讲师 Declan Whelan 最近造出的一个术语][51] — 作为一个积累技术财富的机会，你很可能要先说服你们公司的 CEO、投资者和其它的股东接受并为之共同努力。

“我们没必要把技术债务想像得很可怕。当产品处于开发设计初期，技术债务反而变得非常有用，”Goulet 说。“当你解决一些系统遗留的技术问题时，你会充满成就感。例如，当你在自己家里安装新窗户时，你确实会花费一笔不少的钱，但是之后你每个月就可以节省 100 美元的电费。程序代码亦是如此。虽然暂时没有提高工作效率，但随时时间推移将提高生产力。”

一旦你意识到项目团队工作不再富有成效时，就需要确认下是哪些技术债务在拖后腿了。

“我跟很多不惜一切代价招募英才的初创公司交流过，他们高薪聘请一些工程师来只为了完成更多的工作。”她说。“与此相反，他们应该找出如何让原有的每个工程师能更高效率工作的方法。你需要去解决什么样的技术债务以增加额外的生产率？”

如果你改变自己的观点并且专注于创造技术财富，你将会看到产能过剩的现象，然后重新把多余的产能投入到修复更多的技术债务和遗留代码的良性循环中。你们的产品将会走得更远，发展得更好。

> **别把你们公司的软件当作一个项目来看。从现在起，把它想象成一栋自己要长久居住的房子。**

“这是一个极其重要的思想观念的转变，”Goulet 说。“这将带你走出短浅的思维模式，并让你比之前更加关注产品的维护工作。”

这就像对一栋房子，要实现其现代化及维护的方式有两种：小动作，表面上的更改（“我买了一块新的小地毯！”）和大改造，需要很多年才能偿还所有债务（“我想我们应替换掉所有的管道...”)。你必须考虑好两者，才能让你们已有的产品和整个团队顺利地运作起来。

这还需要提前预算好 —— 否则那些较大的花销将会是硬伤。定期维护是最基本的预期费用。让人震惊的是，很多公司都没把维护当成商务成本预算进来。

这就是 Goulet 提出“**<ruby>软件重构<rt>software remodeling</rt></ruby>**”这个术语的原因。当你房子里的一些东西损坏的时候，你并不是铲除整个房子，从头开始重建。同样的，当你们公司出现老的、损坏的代码时，重写代码通常不是最明智的选择。

下面是 Corgibytes 公司在重构客户代码用到的一些方法：

* 把大型的应用系统分解成轻量级的更易于维护的微服务。
* 让功能模块彼此解耦以便于扩展。
* 更新形象和提升用户前端界面体验。
* 集合自动化测试来检查代码可用性。
* 代码库可以让重构或者修改更易于操作。

系统重构也进入到 DevOps 领域。比如，Corgibytes 公司经常推荐新客户使用 [Docker][50]，以便简单快速的部署新的开发环境。当你们团队有 30 个工程师的时候，把初始化配置时间从 10 小时减少到 10 分钟对完成更多的工作很有帮助。系统重构不仅仅是应用于软件开发本身，也包括如何进行系统重构。

如果你知道做些什么能让你们的代码管理起来更容易更高效，就应该把这它们写入到每年或季度的项目规划中。别指望它们会自动呈现出来。但是也别给自己太大的压力来马上实施它们。Goulets 看到很多公司从一开始就致力于 100% 测试覆盖率而陷入困境。

**具体来说，每个公司都应该把以下三种类型的重构工作规划到项目建设中来：**

*   自动测试
*   持续交付
*   文化提升

咱们来深入的了解下每一项内容。

#### 自动测试

 “有一位客户即将进行第二轮融资，但是他们没办法在短期内招聘到足够的人才。我们帮助他们引进了一种自动化测试框架，这让他们的团队在 3 个月的时间内工作效率翻了一倍，”Goulets 说。“这样他们就可以在他们的投资人面前自豪的说，‘我们一个精英团队完成的任务比两个普通的团队要多。’”

自动化测试从根本上来讲就是单个测试的组合，就是可以再次检查某一行代码的单元测试。可以使用集成测试来确保系统的不同部分都正常运行。还可以使用验收性测试来检验系统的功能特性是否跟你想像的一样。当你把这些测试写成测试脚本后，你只需要简单地用鼠标点一下按钮就可以让系统自行检验了，而不用手工的去梳理并检查每一项功能。

在产品市场尚未打开之前就来制定自动化测试机制有些言之过早。但是一旦你有一款感到满意，并且客户也很依赖的产品，就应该把这件事付诸实施了。

#### 持续交付

这是与自动化交付相关的工作，过去是需要人工完成。目的是当系统部分修改完成时可以迅速进行部署，并且短期内得到反馈。这使公司在其它竞争对手面前有很大的优势，尤其是在客户服务行业。

“比如说你每次部署系统时环境都很复杂。熵值无法有效控制，”Goulets 说。“我们曾经见过花 12 个小时甚至更多的时间来部署一个很大的集群环境。在这种情况下，你不会愿意频繁部署了。因为太折腾人了，你还会推迟系统功能上线的时间。这样，你将落后于其它公司并失去竞争力。”

**在持续性改进的过程中常见的其它自动化任务包括：**

* 在提交完成之后检查构建中断部分。
* 在出现故障时进行回滚操作。
* 自动化审查代码的质量。
* 根据需求增加或减少服务器硬件资源。
* 让开发、测试及生产环境配置简单易懂。

举一个简单的例子，比如说一个客户提交了一个系统 Bug 报告。开发团队越高效解决并修复那个 Bug 越好。对于开发人员来说，修复 Bug 的挑战根本不是个事儿，这本来也是他们的强项，主要是系统设置上不够完善导致他们浪费太多的时间去处理 bug 以外的其它问题。

使用持续改进的方式时，你要严肃地决定决定哪些工作应该让机器去做，哪些交给研发去完成更好。如果机器更擅长，那就使其自动化完成。这样也能让研发愉快地去解决其它有挑战性的问题。同时客户也会很高兴地看到他们报怨的问题被快速处理了。你的待修复的未完成任务数减少了，之后你就可以把更多的时间投入到运用新的方法来提高产品的质量上了。**这是创造科技财富的一种转变。**因为开发人员可以修复 bug 后立即发布新代码，这样他们就有时间和精力做更多事。

“你必须时刻问自己，‘我应该如何为我们的客户改善产品功能？如何做得更好？如何让产品运行更高效？’不过还要不止于此。”Goulets 说。“一旦你回答完这些问题后，你就得询问下自己，如何自动去完成那些需要改善的功能。”

#### 文化提升

Corgibytes 公司每天都会看到同样的问题：一家创业公司建立了一个对开发团队毫无推动的文化环境。公司 CEO 抱着双臂思考着为什么这样的环境对员工没多少改变。然而事实却是公司的企业文化对工作并不利。为了激励工程师，你必须全面地了解他们的工作环境。

为了证明这一点，Goulet 引用了作者 Robert Henry 说过的一段话：

> **目的不是创造艺术，而是在最美妙的状态下让艺术应运而生。**

“你们也要开始这样思考一下你们的软件，”她说。“你们的企业文件就类似那个状态。你们的目标就是创造一个让艺术品应运而生的环境，这件艺术品就是你们公司的代码、一流的售后服务、充满幸福感的开发者、良好的市场预期、盈利能力等等。这些都息息相关。”

优先考虑解决公司的技术债务和遗留代码也是一种文化。那是真正为开发团队清除障碍，以制造影响的方法。同时，这也会让你将来有更多的时间精力去完成更重要的工作。如果你不从根本上改变固有的企业文化环境，你就不可能重构公司产品。改变对产品维护及现代化的投资的态度是开始实施变革的第一步，最理想情况是从公司的 CEO 开始自顶向下转变。

以下是 Goulet 关于建立那种流态文化方面提出的建议：

* 反对公司嘉奖那些加班到深夜的“英雄”。提倡高效率的工作方式。
* 了解协同开发技术，比如 Woody Zuill 提出的[<ruby>合作编程<rt>Mob Programming</rt></ruby>][44]模式。
* 遵从 4 个[现代敏捷开发][42]原则：用户至上、实践及快速学习、把安全放在首位、持续交付价值。
* 每周为研发人员提供项目外的职业发展时间。
* 把[日工作记录][43]作为一种驱动开发团队主动解决问题的方式。
* 把同情心放在第一位。Corgibytes 公司让员工参加 [Brene Brown 勇气工厂][40]的培训是非常有用的。

“如果公司高管和投资者不支持这种升级方式，你得从客户服务的角度去说服他们，”Goulet 说，“告诉他们通过这次调整后，最终产品将如何给公司的大多数客户提高更好的体验。这是你能做的一个很有力的论点。”

### 寻找最具天才的代码重构者

整个行业都认为顶尖的工程师不愿意干修复遗留代码的工作。他们只想着去开发新的东西。大家都说把他们留在维护部门真是太浪费人才了。

**其实这些都是误解。如果你知道去哪里和如何找工程师，并为他们提供一个愉快的工作环境，你就可以找到技术非常精湛的工程师，来帮你解决那些最棘手的技术债务问题。**

“每次在会议上，我们都会问现场的同事‘谁喜欢去在遗留代码上工作？’每次只有不到 10% 的与会者会举手。”Goulet  说。“但是我跟这些人交流后，我发现这些工程师恰好是喜欢最具挑战性工作的人才。”

有一位客户来寻求她的帮助，他们使用国产的数据库，没有任何相关文档，也没有一种有效的方法来弄清楚他们公司的产品架构。她称修理这种情况的一类工程师为“修正者”。在 Corgibytes 公司，她有一支这样的修正者团队由她支配，热衷于通过研究二进制代码来解决技术问题。

![](https://s3.amazonaws.com/marquee-test-akiaisur2rgicbmpehea/BeX5wWrESmCTaJYsuKhW_Screen%20Shot%202016-08-11%20at%209.17.04%20AM.png)

那么，如何才能找到这些技术人才呢？ Goulet 尝试过各种各样的方法，其中有一些方法还是富有成效的。

她创办了一个社区网站 [legacycode.rocks][49] 并且在招聘启示上写道：“长期招聘那些喜欢重构遗留代码的另类开发人员...如果你以从事处理遗留代码的工作为自豪，欢迎加入！”

“我开始收到很多人发来邮件说，‘噢，天呐，我也属于这样的开发人员！’”她说。“只需要发布这条信息，并且告诉他们这份工作是非常有意义的，就吸引了合适的人才。”

在招聘的过程中，她也会使用持续性交付的经验来回答那些另类开发者想知道的信息：包括详细的工作内容以及明确的要求。“我这么做的原因是因为我讨厌重复性工作。如果我收到多封邮件来咨询同一个问题，我会把答案发布在网上，我感觉自己更像是在写说明文档一样。”

但是随着时间的推移，她发现可以重新定义招聘流程来帮助她识别出更出色的候选人。比如说，她在应聘要求中写道，“公司 CEO 将会重新审查你的简历，因此请确保求职信中致意时不用写明性别。所有以‘尊敬的先生’或‘先生’开头的信件将会被当垃圾处理掉”。这些只是她的招聘初期策略。

“我开始这么做是因为很多申请人把我当成男性，因为我是一家软件公司的男性 CEO，我必须是男性！？”Goulet 说。“所以，有一天我想我应该它当作应聘要求放到网上，看有多少人注意到这个问题。令我惊讶的是，这让我过滤掉一些不太严谨的申请人。还突显出了很多擅于从事遗留代码方面工作的人。”

Goulet 想起一个应聘者发邮件给我说，“我查看了你们网站的代码（我喜欢这个网站，这也是我的工作）。你们的网站架构很奇特，好像是用 PHP 写的，但是你们却运行在用 Ruby 语言写的 Jekyll 下。我真的很好奇那是什么呢。”

Goulet 从她的设计师那里得知，原来，在 HTML、CSS 和 JavaScript 文件中有一个未使用的 PHP 类名，她一直想解决这个问题，但是一直没机会。Goulet 的回复是：“你正在找工作吗？”

另外一名候选人注意到她曾经在一篇说明文档中使用 CTO 这个词，但是她的团队里并没有这个头衔（她的合作伙伴是 Chief Code Whisperer）。这些注重细节、充满求知欲、积极主动的候选者更能引起她的注意。

> **代码修正者不仅需要注重细节，而且这也是他们必备的品质。**

让人吃惊的是，Goulet 从来没有为招募最优秀的代码修正者而感到厌烦过。“大多数人都是通过我们的网站直接投递简历，但是当我们想扩大招聘范围的时候，我们会通过 [PowerToFly][48] 和 [WeWorkRemotely][47] 网站进行招聘。我现在确实不需要招募新人马了。他们需要经历一段很艰难的时期才能理解代码修正者的意义是什么。”

如果他们通过首轮面试，Goulet 将会让候选者阅读一篇 Arlo Belshee 写的文章“[<ruby>命名是一个过程<rt>Naming is a Process</rt></ruby>][46]”。它讲的是非常详细的处理遗留代码的的过程。她最经典的指导方法是：“阅读完这段代码并且告诉我，你是怎么理解的。”

她将找出对问题的理解很深刻并且也愿意接受文章里提出的观点的候选者。这对于区分有深刻理解的候选者和仅仅想获得工作的候选者来说，是极其有用的办法。她强烈要求候选者找出一段与他操作相关的代码，来证明他是充满激情的、有主见的及善于分析问题的人。

最后，她会让候选者跟公司里当前的团队成员一起使用 [Exercism.io][45] 工具进行编程。这是一个开源项目，它允许开发者学习如何在不同的编程语言环境下使用一系列的测试驱动开发的练习进行编程。结对编程课程的第一部分允许候选者选择其中一种语言来使用。下一个练习中，面试官可以选择一种语言进行编程。他们总能看到那些人处理异常的方法、随机应便的能力以及是否愿意承认某些自己不了解的技术。

“当一个人真正的从执业者转变为大师的时候，他会毫不犹豫的承认自己不知道的东西，”Goulet说。

让他们使用自己不熟悉的编程语言来写代码，也能衡量其坚韧不拔的毅力。“我们想听到某个人说，‘我会深入研究这个问题直到彻底解决它。’也许第二天他们仍然会跑过来跟我们说，‘我会一直留着这个问题直到我找到答案为止。’那是作为一个成功的修正者表现出来的一种气质。”

> **产品开发人员在我们这个行业很受追捧，因此很多公司也想让他们来做维护工作。这是一个误解。最优秀的维护修正者并不是最好的产品开发工程师。**

如果一个有天赋的修正者在眼前，Goulet 懂得如何让他走向成功。下面是如何让这种类型的开发者感到幸福及高效工作的一些方式：

* 给他们高度的自主权。把问题解释清楚，然后安排他们去完成，但是永不命令他们应该如何去解决问题。
* 如果他们要求升级他们的电脑配置和相关工具，尽管去满足他们。他们明白什么样的需求才能最大限度地提高工作效率。
* 帮助他们[避免分心][39]。他们喜欢全身心投入到某一个任务直至完成。

总之，这些方法已经帮助 Corgibytes 公司培养出二十几位对遗留代码充满激情的专业开发者。

### 稳定期没什么不好

大多数创业公司都都不想跳过他们的成长期。一些公司甚至认为成长期应该是永无止境的。而且，他们觉得也没这个必要跳过成长期，即便他们已经进入到了下一个阶段：稳定期。**完全进入到稳定期意味着你拥有人力资源及管理方法来创造技术财富，同时根据优先权适当支出。**

“在成长期和稳定期之间有个转折点，就是维护人员必须要足够壮大，并且相对于专注新功能的产品开发人员，你开始更公平的对待维护人员，”Goulet 说。“你们公司的产品开发完成了。现在你得让他们更加稳定地运行。”

这就意味着要把公司更多的预算分配到产品维护及现代化方面。“你不应该把产品维护当作是一个不值得关注的项目，”她说。“这必须成为你们公司固有的一种企业文化 —— 这将帮助你们公司将来取得更大的成功。“

最终，你通过这些努力创建的技术财富，将会为你的团队带来一大批全新的开发者：他们就像侦查兵一样，有充足的时间和资源去探索新的领域，挖掘新客户资源并且给公司创造更多的机遇。当你们在新的市场领域做得更广泛并且不断取得进展 —— 那么你们公司已经真正地进入到繁荣发展的状态了。

--------------------------------------------------------------------------------

via: http://firstround.com/review/forget-technical-debt-heres-how-to-build-technical-wealth/

作者：[http://firstround.com/][a]
译者：[rusking](https://github.com/rusking)
校对：[jasminepeng](https://github.com/jasminepeng)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

[a]: http://firstround.com/
[1]:http://corgibytes.com/blog/2016/04/15/inception-layers/
[2]:http://www.courageworks.com/
[3]:http://corgibytes.com/blog/2016/08/02/how-we-use-daily-journals/
[4]:https://www.industriallogic.com/blog/modern-agile/
[5]:http://mobprogramming.org/
[6]:http://exercism.io/
[7]:http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/
[8]:https://weworkremotely.com/
[9]:https://www.powertofly.com/
[10]:http://legacycode.rocks/
[11]:https://www.docker.com/
[12]:http://legacycoderocks.libsyn.com/technical-wealth-with-declan-wheelan
[13]:https://www.agilealliance.org/resources/initiatives/technical-debt/
[14]:https://en.wikipedia.org/wiki/Behavior-driven_development
[15]:https://en.wikipedia.org/wiki/Conway%27s_law
[16]:https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
[17]:http://corgibytes.com/
[18]:https://www.linkedin.com/in/andreamgoulet
[19]:http://corgibytes.com/blog/2016/04/15/inception-layers/
[20]:http://www.courageworks.com/
[21]:http://corgibytes.com/blog/2016/08/02/how-we-use-daily-journals/
[22]:https://www.industriallogic.com/blog/modern-agile/
[23]:http://mobprogramming.org/
[24]:http://mobprogramming.org/
[25]:http://exercism.io/
[26]:http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/
[27]:https://weworkremotely.com/
[28]:https://www.powertofly.com/
[29]:http://legacycode.rocks/
[30]:https://www.docker.com/
[31]:http://legacycoderocks.libsyn.com/technical-wealth-with-declan-wheelan
[32]:https://www.agilealliance.org/resources/initiatives/technical-debt/
[33]:https://en.wikipedia.org/wiki/Behavior-driven_development
[34]:https://en.wikipedia.org/wiki/Conway%27s_law
[35]:https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
[36]:https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
[37]:http://corgibytes.com/
[38]:https://www.linkedin.com/in/andreamgoulet
[39]:http://corgibytes.com/blog/2016/04/15/inception-layers/
[40]:http://www.courageworks.com/
[41]:http://corgibytes.com/blog/2016/08/02/how-we-use-daily-journals/
[42]:https://www.industriallogic.com/blog/modern-agile/
[43]:http://corgibytes.com/blog/2016/08/02/how-we-use-daily-journals/
[44]:http://mobprogramming.org/
[45]:http://exercism.io/
[46]:http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/
[47]:https://weworkremotely.com/
[48]:https://www.powertofly.com/
[49]:http://legacycode.rocks/
[50]:https://www.docker.com/
[51]:http://legacycoderocks.libsyn.com/technical-wealth-with-declan-wheelan
[52]:https://www.agilealliance.org/resources/initiatives/technical-debt/
[53]:https://en.wikipedia.org/wiki/Behavior-driven_development
[54]:https://en.wikipedia.org/wiki/Conway%27s_law
[56]:https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
[57]:http://corgibytes.com/
[58]:https://www.linkedin.com/in/andreamgoulet