Curtis Einsmann在亚马逊的5年中已经诊断并解决了数百个错误。作为一名初级工程师，大型软件系统中的错误诊断具有挑战性。 下面是他的经验总结：原因的诊断很重要。不成熟的解决方案使得问题持续存.

YAGNI 是You Ain't Gonna Need It（你不会需要它）的简写，是极限编程的关键原则。YAGNI意思非常简单：仅在您真正需要它们时才去做，而不是在您认为或预见将来可能需要它们时就提.

技术负债概念提出者Ward Cunningham认为：长期开发一个应用程序时，我们是通过不断添加功能进行的，但是却从未对其进行重新组织以反映我们对这些功能的理解，那么最终该程序将根本不包含任何理解，因.

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

拥有非常小的团队规模能使达成共识变得容易。让多个人一起从事某项工作的协调性的补偿性流程会让人感到惊讶。小团队的失败模式是总线因素。大型团队的失败模式是由于缺乏共识和协调而静默积累技术债务。我认为没有解.

研究表明，人为因素最影响我们的工作质量，可是为什么我们会投入更多精力希望通过技术性解决方案解决软件质量呢？假设您经营一个新团队。您可以一刀切地实施任何您想提高人员生产力和减少代码错误的策略。你会做什么.

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

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

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

如果你在软件行业工作一段时间，你最终会听到技术债务一词。它指的是设计不合理的东西，将来会成为昂贵的维护问题。它应该会让人联想到短期技术捷径的可怕景象，它会导致未来的痛苦。善良的我觉得这个词没用。我们先.

这是一篇从心理模型也就是心智模型角度分析编码的文章，比较晦涩难懂，实际上中心意思是，每段代码其实只是人在编写这段代码时的心智模型投射，我们不能把代码看成是客观的存在，而是主观的产物，甚至参合了当时心理.

更喜欢函数性方法。相比副作用，不可变的状态使代码不易出错，并且更容易推理。最小化持有状态。任何形式的状态（例如变量，缓存）往往是复杂性和问题的根源，因此最好尽可能少地保留它。如果约束允许，更喜欢在需要.

对于遗留系统的维护:想对数据库中某张表增加若干字段这张表非常关键,系统中多处程序都要用到此表,这张表被抽象成了一个类,并且类中包括了处理表的方法(eg:create,update,search.....