读了两篇文章，其中都提到了技术债：
技术债，迟早是要还的 -- 《ScrumMaster精髓》第八章技术债读后感
好文，赞！所谓"出来混，迟早要还的"，欠的技术债，也同样需要还。关注焦点在于技术债怎么还，还债方式，和还债的条件与成本。我从另外几个角度看下这个问题：
一.看产品给用户的价值输出形态：
像商业软件（OA类、OFFICE、ERP之类）或现在的部分云服务模块（开放API，或对外开放的SDK），这种提供给用户的就是以软件或某些模块为载体的形态；他们对于还技术债的诉求很高，这些软件实体或模块一旦项目立项或安装出去，可能开发与升级的周期都比较长，在一段时间内，可能都是稳定的，不需要调整或变化；软件载体本身承载着给用户所输出的价值，必须做到可用、健壮与高可靠；一些提供OA、金融客户端的传统公司对这一点诉求很高(虽然实际产品一样存在问题)；
二.看产品与用户之间的关联关系以及生命周期：toB类的和toC类产品相比，toB类诉求更高。相比toB类长周期的产品而言，互联网化的toC类产品需要不断的跟进当下的趋势与热点，在不断的运营和调整，本身可能会欠更多的技术债（如Mobike单车紧跟热点的运营，忘关锁账户欠费两千万的int整型溢出问题），而toB类的产品可能在很长一段时间里面，不需要做调整；某些功能的生命周期而言，toB类的无疑会更长久，更值得持续性，长期的投入，少欠技术债；
三.看公司与业务阶段成熟度：
（1）对于萌芽期的初创公司或新开辟的业务线而言，往往是在快速冲刺和产品DEMO与商业模型验证阶段，会欠一定的技术债，但换来的结果是公司以极低的成本，快速获取资本支持，并快速试错，验证商业模型，这时候，欠技术债就节省了成本；
（2）对于发展与快速扩张期的公司而言，欠技术债也是正常的，只是不想萌芽期那样债台高筑，而是夯实基础，基础模块层债务已偿还，欠的只是业务条线快速扩张的债务；
（3）再到一定规模，成熟期的时候，往往资源不像之前那么短缺，人手齐全、产品形态与业务模式稳定，这时候，就认真考虑偿还所有债务就显得比较急迫了。当资源具备条件，较大的新需求或设计调整相对较少，产品技术架构与技术选型已经可用，团队成员技术能力栈得到沉淀，人员有一定积累、项目运作模式成熟时，逐渐去调整模块，一点一滴的优化与重构，持续Rebuild、Rework，持续不断地做技术更新；
（4）千里之堤，毁于蚁穴。如果债务欠得太久，利息太多，一直没还，没有跟上行业/市场/用户的需求，那么可能会慢慢就衰落了。
另外，从另一个角度来看，有适度的负债率，也是健康的，不足为惧。企业有负债，个人有负债（大部分人的房贷），技术同样有负债，在一定的环境下，合理的负债，是资源配置的最优方式；
综上，在合理的阶段，做合理的事情，分期付款偿还技术债也是种不错的方式。
补充：
写完前一部分，看到了这篇文章（第八章 技术债：http://www.jianshu.com/p/3e65ab375cb9）
在这篇文章(作者：王子君2017 链接：http://www.jianshu.com/p/3e65ab375cb9)中最后给出的这些指导性方法：
"依托于一套自动化构建系统，以代码提交作为触发条件，触发若干项活动自动进行，如单元测试、全局变量统计分析、圈复杂度统计分析，内存碎片分析等。每项活动进行完毕，构建系统自动在缺陷管理系统中登录相应问题，并用特殊标记标识，促进开发团队解决。以代码提交作为触发条件，把开发团队编写代码的活动与检查代码的活动自然地结合在一起，不成熟的开发者再也不会忘记，也无法敷衍这些活动，从而使技术实践落到实处。"
这个确实是一条方式，而且笔者曾经有过2年多这种实践。基本思路趋同，但细节有差异。总体来看，这种方式有优点，带来的质量提升是显而易见的，而且是可以量化的，但也有一定要求和门槛。当你引入CI之后，在其中获取到这些"单元测试、全局变量统计分析、圈复杂度统计分析"之后，可以通过规则与数据方式，对开发团队的代码质量进行评估，对于基础代码规范提升是很明显的。该方法能够使得基础的类和函数方法优化，并且从基础代码与设计层面减少耦合，规范函数见调用，从代码级别做到了规范化；建议有条件的团队可以尝试去做，至少在标准与规范化方面会有提升。但是，这个也不是100%完美的解决了问题。下面我举几点：
1.该方法中要做到单元测试，而对于单元测试主要会从覆盖率角度统计，但部分mock的可能需要耗费的成本较高，比如涉及到系统底层与硬件驱动层（以前遇到过与分布式存储跨设备网络虚拟化与qumo与内存管理等方面的问题）；
2.部分场景做这种统计之后，可能需要团队重新修改类Sonor统计规则（比如前端单元测试自动化）；
3.部分场景所需要做的单元测试，可能所耗费的成本，远高于实际业务代码实现好几倍；
4.产品需求与UX设计修改频繁，但代码交付周期不延长的场景，需要慎重考虑；
5.当然还有其他的因素，部门或组织架构调整，团队成员变动等非技术类因素等需要考虑；
在具体工程方法中，我曾经只实践过TDD、BDD、SBE、Scrum、Lean，个人觉得觉得CI+SBE+Lean配合起来的模式还不错。当然，可能还有其他很多方式，比如，我们会听说很多模式，常见的Waterfall、Iterative、RUP、PDCA、Agile等等，层出不穷，每隔几年就会有一些新概念新方法出来；但是，方法学值得研究，适合自己团队的才是最好的。一切的模式，最终都一定是结合自己团队现状的改造和引入，才能达到最好的效果；轮子不冲重造，但方法学可以改造性的引入，打造具有符合自己团队特色的最优主义开发路线，是最好的；
我们可能会做很多尝试，最后又回到原点，重新去思考。努力做过几次实践之后，会发现，一定是会有收获的。越过山丘，才发现无人等候。听过无数道理，却还没过好这一生。
王国维先生讲的三重境界:"昨夜西风凋碧树。独上高楼，望尽天涯路","衣带渐宽终不悔，为伊消得人憔悴。","众里寻他千百度，蓦然回首，那人却在，灯火阑珊处"------这三重境界适用于人生，同样适用于技术债。
回到核心诉求
工程领域，选择什么工具或者语言、平台，就像使用什么兵器一般。之前看到过有些技术朋友将开发语言比作兵器的文章：
如果开发语言是一把刀：http://www.csdn.net/article/2012-02-21/312118
如果把编程语言比作武器：http://www.cnblogs.com/Wayou/p/if-programming-languages-were-weapons.html、
比较Perl、PHP、Python、Java和Ruby 【转载】http://www.cnblogs.com/DDark/archive/2011/12/07/2279196.html
武侠小说中独孤求败曾在石壁上写到："纵横江湖三十余载，杀尽仇寇，败尽英雄，天下更无抗手，无可奈何，惟隐居深谷，以雕为友。呜呼，生平求一敌手而不可得，诚寂寥难堪也。"
所有的工程学方法，以及我们所使用的第三方工具，开源插件，都是各种刀剑，好使的工具，就可谓是一款玄铁重剑。若玄铁剑在手即能取胜，玄铁重剑使得越好，便可大杀四方，提高工程质量。
能达到剑魔“木剑胜铁剑，无剑胜有剑”之境，如同扫地僧一般功力，轻风拂手，才是上上成功夫。
当然，扯得有点远了。
最终，我们还还是得回到具体人和事上面来。再简化一步，毕竟，人才是一切的核心！
