校对中

校对中

translated/talk/20160826 Forget Technical Debt —Here'sHowtoBuild Technical Wealth.MD

@@ -9,52 +9,52 @@
 
 ### 反思遗留代码
 
-关于遗留代码最广泛的定义由Michael Feathers在他的著作[修改代码的艺术][56][][55]一书中提出：遗留代码就是没有被测试的代码。这个定义比大多数人所认为的——遗留代码仅指那些古老陈旧的系统这个说法要妥当得多。但是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所说的那样迷失在遗留代码里，你会发现每一次的沟通交流过程都会变得像那条鲜为人知的[康威定律][54]所描述的一样。
+如果你像 Goulet 所说的那样迷失在遗留代码里，你会发现每一次的沟通交流过程都会变得像那条[<ruby>康威定律<rt>Conway’s Law</rt></ruby>][54]所描述的一样。
 
-Goulet说：“这个定律认为系统的基础架构能反映出你们整个公司的组织沟通结构，如果你想修复你们公司的遗留代码而没有一个好的组织沟通方式是不可能完成的。那是很多人都没注意到的一个重要环节。”
+Goulet 说：“这个定律认为系统的基础架构能反映出整个公司的组织沟通结构，如果想修复公司的遗留代码，而没有一个好的组织沟通方式是不可能完成的。那是很多人都没注意到的一个重要环节。”
 
-Goulet和她的团队成员更像是考古学家一样来研究遗留系统项目。他们根据前开发者写的代码构件相关的线索来推断出他们的思想意图。然后再根据这些构件之间的关系来作出新的决策。
+Goulet 和她的团队成员更像是考古学家一样来研究遗留系统项目。他们根据前开发者写的代码构件相关的线索来推断出他们的思想意图。然后再根据这些构件之间的关系来做出新的决策。
 
-最重要的代码构件是什么呢？良好的代码结构、清晰的思想意图、整洁的代码。例如，如果你使用了通用的名称如”foo“或”bar“来命名一个变量，半年后你再返回来看这段代码时，你根本就看不出这个变量的用途是什么。
+最重要的代码是什么样子呢？**良好的代码结构、清晰的思想意图、整洁的代码**。例如，如果使用通用的名称如 “foo” 或 “bar” 来命名一个变量，半年后再返回来看这段代码时，根本就看不出这个变量的用途是什么。
 
-如果代码读起来很困难，可以使用源代码控制系统，这是一个非常有用的构件，因为从该构件可以看出代码的历史修改信息，这为软件开发者写明他们作出本次修改的原因提供一个很好的途径。
+如果代码读起来很困难，可以使用源代码控制系统，这是一个非常有用的工具，因为它可以提供代码的历史修改信息，并允许软件开发者写明他们作出本次修改的原因。
 
-Goulet说：”我一个朋友认为对于代码注释的信息，如有需要，每一个概要部分的内容应该有推文的一半多，而代码的描述信息应该有一篇博客那么长。你得用这个方式来为你修改的代码写一个合理的说明。这也不会浪费太多的时间，并且给后期的项目开发者提供更多有用的信息，但是让人惊讶的是没人会这么做。我们经常听到一些很沮丧的开发人员在调试一段代码的过程中报怨这是谁写的这烂代码，最后发现还不是他们自己写的。“
+Goulet 说：“我一个朋友认为提交代码时附带的信息，如需要，每一个概要部分的内容应该有推文的一半多，而代码的描述信息应该有一篇博客那么长。你得用这个方式来为你修改的代码写一个合理的说明。这不会浪费太多额外的时间，并且能给后期的项目开发者提供非常多的有用的信息，但是让人惊讶的是很少有人会这么做。我们经常听到一些开发人员在调试代码的过程中，很沮丧的报怨这是谁写的这烂代码，最后发现还不是他们自己写的。”
 
-使用自动化测试对于理解程序的流程非常有用。Goulet解释道：“很多人都比较认可Michael Feathers提出的关于遗留代码的定义，尤其是我们与[行为驱动开发模式][53]相结合的过程中使用测试套件，比如编写测试场景，这对于理解开发者的意图来说是非常有用的工具。
+使用自动化测试对于理解程序的流程非常有用。Goulet 解释道：“很多人都比较认可 Michael Feathers 提出的关于遗留代码的定义。测试套件对于理解开发者的意图来说是非常有用的工具，尤其当用来与[<ruby>行为驱动开发模式<rt>Behavior Driven Development</rt></ruby>][53]相结合时，比如编写测试场景。”
 
-理由很简单，如果你想把遗留代码的程度降到最低，你得多注意下代码的易理解性以及将来回顾该代码的一些细节上。编写并运行单元程序、接受、认可，并且进行集成测试，写清楚注释的内容。方便以后你自己或是别人来理解你写的代码。
+理由很简单，如果你想利用好遗留代码，你得多注意使代码在将来易于理解和工作的一些细节上。编写并运行单元程序、接受、认可，并且进行集成测试，写清楚注释的内容。方便以后你自己或是别人来理解你写的代码。
 
 尽管如此，由于很多已知的和不可意料的原因，遗留代码仍然会发生。
 
-在创业公司刚成立初期，公司经常会急于推出很多新的功能。开发人员在巨大的压力下一边完成项目交付一边测试系统缺陷。Corgibytes团队就遇到过好多公司很多年都懒得对系统做详细的测试了。
+在创业公司刚成立初期，公司经常会急于推出很多新的功能。开发人员在巨大的交付压力下，测试常常半途而废。Corgibytes 团队就遇到过好多公司很多年都懒得对系统做详细的测试了。
 
-确实如此，当你急于开发出系统原型的时候，强制性地去做太多的系统测试也许意义不大。但是，一旦产品开发完成并投入使用后，你就不得投入大量的时间精力来维护及完善系统。“很多人觉得运维没什么好担心的，重要的是产品功能特性上的强大。如果真这样，当系统规模到一定程序的时候，就很难再扩展了。同时也就失去市场竞争力了。
+确实如此，当你急于开发出系统原型的时候，强制性地去做太多的测试也许意义不大。但是，一旦产品开发完成并投入使用后，你就需要投入时间精力来维护及完善系统了。Goulet 说：“很多人觉得运维没什么好担心的，重要的是产品功能特性上的强大。如果真这样，当系统规模到一定程序的时候，就很难再扩展了。同时也就失去市场竞争力了。
 
-最后才明白过来，原来热力学第二定律对你们公司的代码也同样适用：你所面临的一切将向熵增的方向发展。你需要与混乱无序的技术债务进行一场无休无止的战斗。并且随着时间的增长，遗留代码也逐渐变成一种简单类型的债务。
+最后才明白过来，原来热力学第二定律对代码也同样适用：你所面临的一切将向熵增的方向发展。你需要与混乱无序的技术债务进行一场无休无止的战斗。遗留代码随着时间的增长，也逐渐变成一种债务。
 
-她说：“我们再次拿家来做比喻。你必须坚持每天收拾餐具，打扫卫生，倒垃圾。如果你不这么做，情况将来越来越糟糕，直到有一天你不得不向HazMat团队求助。”
+她说：“我们再次拿家来做比喻。你必须坚持每天收拾餐具，打扫卫生，倒垃圾。如果你不这么做，情况将来越来越糟糕，直到有一天你不得不向 HazMat 团队求助。”(译者注：HazMat 团队，危害物质专队) 
 
-就跟这种情况一样，Corgibytes团队接到很多公司CEO的求助电话，比如Features公司的CEO在电话里抱怨道：“现在我们公司的开发团队工作效率太低了，三年前只需要两个星期就完成的工作，现在却要花费12个星期。”
+就跟这种情况一样，Corgibytes 团队接到很多公司 CEO 的求助电话，比如 Features 公司的 CEO 在电话里抱怨道：“现在我们公司的开发团队工作效率太低了，三年前只需要两个星期就完成的工作，现在却要花费12个星期。”
 
-> 技术债务往往反应出公司运作上的问题
+> **技术债务往往反应出公司运作上的问题。**
 
-很多公司的CEO明知会发生技术债务的问题，但是他们也难让其它同事相信花钱来修复那些已经存在的问题是很值的。这看起来像是在走回头路，很乏味或者没有新的产品。有些公司直到系统已经严重的影响了日常工作效率时才着手去处理技术债务方面的问题，那时付出的代价就太高了。
+很多公司的 CTO 明知会发生技术债务的问题，但是他们很难说服其它同事相信，花钱来修复那些已经存在的问题是值得的。这看起来像是在走回头路，很乏味或者没有新的产品。有些公司直到系统已经严重影响了日常工作效率时，才着手去处理这些技术债务方面的问题，那时付出的代价就太高了。
 
 ### 忘记债务，创造技术财富
 
-# 推荐文章
-
 如果你想把[重构技术债务][52]作为一个积累技术财富的机会-[敏捷开发讲师Declan Whelan最近提到的一个术语][51]，你很可能要先说服你们公司的CEO、投资者和其它的股东登上这条财富之船。
+You’re much more likely to get your CEO, investors and other stakeholders on board if you reframe your technical debt as an opportunity to accumulate technical wealth — a term recently coined by agile development coach Declan Whelan.
 
+“We need to stop thinking about debt as evil. Technical debt can be very useful when you’re in the early-stage trenches of designing and building your product,” says Goulet. “And when you resolve some debt, you’re giving yourself momentum. When you install new windows in your home, yes you’re spending a bunch of money, but then you save a hundred dollars a month on your electric bill. The same thing happens with code. Only instead of efficiency, you gain productivity that compounds over time.”
 “我们没必要把技术债务想像得很可怕。当产品处于开发设计初期，技术债务反而变得非常有用，”Goulet说。“当你解决一些系统遗留的技术问题时，你会充满成就感。例如，当你在自己家里安装新窗户时，你确实会花费一笔不少的钱，但是之后你每个月就可以节省100美元的电费。程序代码亦是如此。这虽然暂时没有提高工作效率，但是随时时间地推移将为你们公司创造更多的生产率。“
 
 一旦你意识到项目团队工作不再富有成效时，你必须要确认下是哪些技术债务在拖后腿了。
@@ -277,7 +277,6 @@ via: http://firstround.com/review/forget-technical-debt-heres-how-to-build-techn
 [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
-[55]:https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
 [56]:https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
 [57]:http://corgibytes.com/
 [58]:https://www.linkedin.com/in/andreamgoulet