1. 软件质量

如何评价一款软件的质量呢（software quality）情况下，我们会从“外部质量”和“内部质量”两个方面进行考量。

外部质量：外部质量通常是从用户的角度进行考量，例如软件功能是否正确，软件的性能Performance，软件的可用性和安全性等。

内部质量：内部质量是从开发人员的角度进行考量，例如代码的可读性，是否易于维护，是否具有良好的扩展性，复用性，是否易于测试等等。

外部质量是容易被管理团队发现的，例如软件功能的缺陷，性能的低下等。但内部质量相对隐蔽，对于一般的项目管理团队是一个黑箱，但内部质量对于一个软件确是十分关键的，如果一款软件的内部质量低，当发生需求变更或是功能扩展时，将会是一场恶梦。

2. 技术债

在软件实现过程中所遗留下的低质量的代码，可以视为这款软件在技术上亏欠的“技术债”。

我们知道，“出来混早晚是要还的”，欠下的技术债，会一点一滴的积累，如果不及时解决，则一定会爆发出严重的后果。

正如破窗效应（Broken Window Effect）那样，如果放任代码中的技术债持续存在，那么代码的质量将会持续下降，直到代码变得无法维护。

持续低下的内部质量将会显现到外部质量上，例如微小功能的改动都可能导致各种无法预测的问题，软件功能变得脆弱无比。

积累的“技术债”，也会直接降低软件开发的效率，越来越多的时间和人力不得不被投入到运维和缺陷的修复上，甚至会出现“修不完的bugs”(修复某一功能的代码，又导致了另一个功能上的bug)，如果出现在这种情形，软件基本不要奢望任何新功能的扩展了。

3.”技术债”的成因

为啥会出现“技术债”债堆积的代码往往是哪些“时间紧，任务重”的代码，例如要在最短的时间内，尽快的上线某一功能，这样情况下的程序，其最大特点就是“埋了很多雷”。

欠了银行钱要付利息，欠下的“技术债”要靠不断的重构和re-design来支付其时间上的利息，如果欠下的债务超出了“偿还能力”，那这个软件也基本就到了“无法运维”的境地了。

4. 避免欠下”技术债”

可以说“技术债”等同于向未来借时间，如果技术债持续的积累，那么要解决其带来问题的时间也会被持续的放大，如果银行的复利累积一样。

因此，在编码过程中，就要尽力避免留有“技术债”，这也就引申到另一个重要的概念Clean Code，也即代码整洁之道，在开发团队中要形成“代码整洁、规范”的良好风气，有明确的guideline，明确的check-point和criteria，并通过Pair Programming结对编程，代码review等方式来确保代码质量，让团队的每一位成员都意识到自身所担负的责任。

一以贯之的优秀代码质量也会带来持续的“正向反馈”，例如软件的已有功能会是成熟的，稳定的，并且容易添加新的功能；同时对于开发人员，其运维代码时也会变得less pressure，并且对代码很有信心。

对于遗留的技术债，不要放任不管，自暴自弃，要尽早制定计划并预留相应的effort来解决这部分问题，控制问题的影响面，因为这不仅仅是对软件质量的控制，更是对整个项目或软件的风险控制。