技术债务

大多数KPI指标毫无价值。绝对最佳的程序员所编写的代码少于能力较弱的程序员。最好的衡量标准是编写的代码少，代码越少越好。实际上，删除代码是您可以执行的最有效的操作之一。负生产力反而是一个加号。测量代码行会惩罚您最好的程序员。代码质量（不是错误，而是实际质量）无法衡量（也许您可

Stack Overflow的2020年调查结果对“最恐惧的编程语言”和“最喜欢的编程语言”进行了排名。这两个排名都来自这个问题：在过去的一年中，您完成了哪些编程，脚本和标记语言的广泛开发工作，并且在接下来的一年中又要进行哪些工作？（如果您既使用了该语言，又想继续使用该语

著名敏捷专家Allen Holub认为：编写“快速而肮脏”的废代码可以使您更快地推向市场是一个神话。至少我从未见过这项工作。最快的上市方式是编写高质量的，经过良好测试的代码。马丁福勒称这种“快而脏”代码是鲁莽导致的债务reckless debt.什么是足够好、高质量的代码？他认为TD

著名敏捷大神Allen Holub认为：不能过分强调架构与程序员纪律一样重要。如果没有程序员的纪律，所有系统，无论设计得如何好，都会在砸在不了解其设计的程序员手中。这句话的意思，程序员纪律比架构设计更重要，但是这种将注意力集中在人身上的做法会不会导致内卷化？程序员之间相互指责争斗，程序员是否

牢记业务上下文的技术决策建议，业务上下文是唯一的衡量软件质量的关键指标。如果有事情不对劲，软件工程师会感到不安。学生或初级工程师由于不熟悉编程概念而感到不安。渐渐地，我们对更高层次的抽象感到不安：我们不再会像当初因缺乏理解而烦恼，而是知道系统确实属于有害反模式时，会更加不安。

Defect和Bug翻译成中文都是缺陷的意思，两者有什么区别？Bug是编程错误的结果，Defact缺陷是与需求的偏离。Defect缺陷不一定表示代码中存在bug，它可能是尚未实现但在软件需求中定义了的功能。测试是识别缺陷defact的过程，Defect缺陷是实际结果与预期结果

研究表明，人为因素最影响我们的工作质量，可是为什么我们会投入更多精力希望通过技术性解决方案解决软件质量呢？假设您经营一个新团队。您可以一刀切地实施任何您想提高人员生产力和减少代码错误的策略。你会做什么？进行配对编程！切换到Haskell！使用UML进行所有操作！这些技术都有自

如果你在软件行业工作一段时间，你最终会听到

比尔盖茨说过：人们不会为修复bug付费，只为新功能付钱。技术债务作为Bug产生的根源，技术债务只是针对开发人员而言，如何能做到向最终用户收费？创造新的商业价值？KentBeck提出投资改善体系结构或架构，这样比单纯去修复bug、重构等还请技术债务的方式会更好吗？

众说纷纭：灵活性可能导致更多的设计时间和复杂性。这个词本身看起来不错，但没那么简单。 我现在正在（艰难地）学习到，随着复杂性的增加，维持软件项目中的变化速率变得越来越困难。如果我可以回去一年，我肯定会在设计更多SOLID方面投入更多的前期精

拥有非常小的团队规模能使达成共识变得容易。让多个人一起从事某项工作的协调性的补偿性流程会让人感到惊讶。小团队的失败模式是总线因素。

技术负债概念提出者Ward Cunningham认为：长期开发一个应用程序时，我们是通过不断添加功能进行的，但是却从未对其进行重新组织

YAGNI 是You Ain't Gonna Need It（你不会需要它）的简写，是极限编程的关键原则。YAGNI意思非常简单：仅在您真正需要它们时才去做，而不是在您认为或预见将来可能需要它们时就提前做了！您可以将YAGNI视为即时制造的拥护者。在这种情况下，制造业正在编写

Curtis Einsmann在亚马逊的5年中已经诊断并解决了数百个错误。作为一名初级工程师，大型软件系统中的错误诊断具有挑战性。 下面是他的经验总结：原因的诊断很重要。不成熟的解决方案使得问题持续存在，这些微小的缺陷很容易被开发人员忽略。诊断原因是修复的第一步。清晰表达问题