收益递增理论
收益递增理论认为，首先发展起来的技术往往具有占先优势，再通过规模效应降低单位成本，并利用普遍流行导致的学习效应和许多行为主体采取相同技术所产生的协调效应，致使该技术在市场上越来越流行，人们也就相信它会更流行，于是该技术就实现了自我增强的良性循环。
技术负债
技术负债又译技术债，也称为设计负债、代码负债，是编程及软件工程中的一个比喻。指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。软件工程师必须付出额外的时间和精力持续修复之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。
分类
文档负债
1、需求分析负债
不懂需求分析的软件开发工程师不是好的软件开发工程师，遇到问题一定要与上级领导或者客户及时反馈，及时沟通，某些需求不能做就是不能做，要持有一种质疑的心。找正确的途径去反馈问题而不是背地里去发恼骚，要懂得有效的沟通方式，让客户或者是领导理解技术实现痛点。如果软件开发工程师没有理解好项目需求而盲目开发项目，必然导致领域业务与开发业务不匹配， 从而付出更多的时间与精力去开发项目。
2、开发文档负债
软件开发文档不齐全，或者是软件文档功能与项目代码功能不一致。
有两种以下情况：
（1）项目没有制定开发文档。没有制定代码规范文档，接口文档等相关技术文档。光看代码不看文档就够辛苦了，即使语义化变量名与函数名，也难易快速理解。（少见）
（2）项目没有更新开发文档。项目开发初期还有文档，后来文档没有对应没有更新，因为有些需求几乎都是临时新增的，导致后期项目迭代的时候就造成大量的冗余代码。（常见）
软件开发文档是项目最系统最全面的反映，看文档比看代码更容易理解项目的功能模块。
3、测试文档负债
体现于软件测试覆盖率低，测试用例不足。
在大多数的企业中，为了控制人力成本，软件测试都是由软件开发工程师去完成，而不是由专业的软件测试人员去负责，这样做往往会忽略了一些软件漏洞（当局者迷，旁观者清），也给技术债埋下了更多的种子。一个企业如果不重视软件测试的话，做出来的软件项目绝对是一个不合格的产品。
代码负债
1、架构负债
前期项目架构评估不够充分，导致项目组织不合理，软件耦合度高，后期项目难以拓展与维护。
正所谓牵一发而动全身，业务需求不断新增，软件项目很难迭代，稍有不慎就容易出现漏洞，后来发现代码没法改，不得不推倒重来，重新开发项目。
2、编码负债
编码质量不高，导致开发团队难以协同工作。当遇到软件产品迭代就会出现一堆技术债，软件产品更是漏洞百出，难以维护。
体现在以下几个方面
（1）代码命名规范：代码命名没有规范，存在大量杂乱不堪的命名代码。
（2）代码复杂度：条件语句过多，流程控制过于复杂，代码嵌套过多。（常见回调地狱）
（3）代码耦合度：代码中参数，类，接口高耦合，需要大量修改代码。
（4）代码行数：存在大量未使用的代码。良好的，统一的编码规范更好维护以及迭代项目，有利于代码的重构，一定程度上减少技术债。
PS：当然每个团队都有自己的标准，以上只是参考指标，并不是唯一指标。
3、业务负债
经常采用投机取巧方案修补漏洞。没有深度思考自己业务逻辑代码或者是没有彻底理解漏洞产生的原因，通过简单的，过多的条件判断就修补代码漏洞，或者是强制修改数据库的用户数据。这种救得了一时,救不了一世方案不可取，只造成更多的技术债。
管理负债
1、工期负债
项目期限也是技术债产生原因之一。现在的项目正如马士兵老师说的那样，现在的项目赶紧做，做完之后赶紧拿钱，说白了就是赚快钱。企业为了抢占市场占有率，必然想短期出产品，因此软件开发工程师必然只能沿用一些老解决方案，加快想项目开发进度。开发出来的产品质量和以前没有太大区别，软件生命周期短。
2、人员负债
一个人员流动性大的开发团队导致项目开发难以开展或者是开发进度缓慢，再加上团队中的开发人员能力不尽相同，各有各的风格，即使规范了代码风格，但每个人的代码实现思路也不尽相同。技术债也随着人员流动而加大。
3、协同负债
让开发团队的人知道“我是谁，我在哪，我在干什么”。有两种以下值得注意：
（1）管理者必定充分认识自己的定位，该做什么就做什么，不要过分干涉组员的工作，但要监督组员工作质量。
（2）管理者必定认真分配组员的开发任务，分工明确，各尽其职，避免重复开发模块。
良好的协同可以避免一些重复工作，减少软件冗余代码，促使项目开发效率会事半功倍，保证如期进行，从而减少技术债增加。
4、成本负债
项目的软硬件环境配置决定项目的成本负债。控制好成本负债才可以获得更多的收益。聪明的管理者绝不会贪小便宜，只顾眼前的成本利益而造成更大的成本负债，该花钱的地方就有花，不要节省。
软件工程
软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。其后的几十年里，各种有关软件工程的技术、思想、方法和概念不断被提出，软件工程逐步发展为一门独立的科学。
代码重构
在软件工程学里，重构代码一词通常是指在不改变代码的外部行为情况下而修改源代码，有时非正式地称为“清理干净”。在极限编程或其他敏捷方法学中，重构常常是软件开发循环的一部分：开发者轮流增加新的测试和功能，并重构代码来增进内部的清晰性和一致性。自动化的单元测试保证了重构不至于让代码停止工作。
重构既不修正错误，又不增加新的功能性。反而它是用于提高代码的可读性或者改变代码内部结构与设计，并且移除死代码，使其在将来更容易被维护。重构代码可以是结构层面抑或是语意层面，不同的重构手段施行时，可能是结构的调整或是语意的转换，但前提是不影响代码在转换前后的行为。特别是，在现有的程序的结构下，给一个程序增加一个新的行为可能会非常困难，因此开发人员可能先重构这部分代码，使加入新的行为变得容易。
一个重构的小范例是修改一个变量的名称使其具有更明确的含义，例如从单个字母的“i”重构为“interestRate”。较复杂的重构是把一段if区块中的代码变为一个子程序。更复杂一点的重构是用多态性来替换if条件式。“清理”代码已经发生了几十年，重构中最关键的认知是有意地“清理”代码，透过从已知的纪录里一些常用的重构方法清理代码，把它从增加新功能分开，然后个别的对代码进行测试（任何的行为改变都可能带来错误）。新的实现切合实际需要以改善现有设计，并且不改变原软件的意图或行为。
重构面对业界调适接受方面的挑战。首先，对重构长远的影响需要更深入研究追踪。又，重构存于资料库轮廓的商业逻辑层几乎是不可能或者非常困难的。最后，对接口造成影响的重构可能造成程序开发上的困境，除非程序员有对所有用户界面的访问权。例如，程序员若改变某实体中的方法名称，他要么必须对整个专案里头所有连结到旧名的参考都加以编辑，要么屈服于继续维护使用旧名的残株残瓦接口。而该旧名的接口于内部调用该方法的新名。
简言
语录
技术的瓶颈正是技术的动力。