我改变的事项包括：
我之前争论不休的一些东西，我现在开始确信：
- 当你在一个团队中与各种水平的人一起工作时，强类型语言会更好
- 创业公司事实上更有利于新手
- 冲刺回顾只要能用于实际的课程改正（比如“天哪，太差劲了”），还是有它自己的位置的，而不是某些可怕的“agile” “scrum master” 会浪费每个人的时间
- 软件架构的影响更大。对好的抽奖的糟糕的实现并不会对代码库造成任何损坏。一个不好的抽象或者缺失的层会导致所有东西腐烂。
- java语言不是那么糟糕
- 聪明的代码通常不是好代码，清晰度比其他所有问题都重要。
- 错误代码可以用任何范式编写
- 所谓的最佳实践是上下文相关的，不能广泛应用。盲目跟风会使你成为白痴。
- 当你不需要构建可伸缩系统的时候，会让你变成一个差工程师
- 静态分析很有用
- DRY的目的是避免特定的问题，而不是最终的目标
- 通常来说，RDBMS > NoSql
- 函数编程是另一种工具，而不是万能药
我一路走来的意见
- YAGNI, SOLID, DRY. 按照这个顺序来
- 铅笔和纸是最好的编程工具，很少被使用
- 用纯粹性换取实用性通常是个好选择
- 使用更多的技术很少是个好选择
- 直接对接客户总是可以在更短的时间内以更高的准确性揭示更多有关问题的信息
- “可伸缩”一词在软件工程师心中具有神秘而愚蠢的力量。它的纯粹性话语可以将他们鞭打成堕落的狂热，使用这个词已经证明严厉的行动是合理的。
- 尽管被称为“工程师”，但大多数决策都是“货物崇拜”，没有任何背景分析、数据或数字
- 90%（也许是93%）的项目经理，可能会由于没有影响或者效率上的收益在明天消失调
- 进行100次面试后，面试彻底中断了。我也不知道如何使它更好。
未改变的看法
- 强调代码风格，棉绒规则或者其他细节的人都是疯子
- 代码覆盖率和代码质量一点关系没有
- 整体结构在大多数情况下都非常好
- TDD主义者是最糟糕的，他们虚弱的小头脑无法处理的存在的不同的工作流程。
我们将在第10年看到其中哪些会发生翻转或更改。
原文：
Software development topics I've changed my mind on after 6 years in the industry
译注:
- 静态分析：应该主要指代码审查、架构评审之类的
- YAGNI：You Ain’t Gonna Need It，软件开发中的适可而止原则
- SOLID：设计模式的六大原则，单一职责原则（Single Responsibility Principle），开闭原则（Open Closed Principle），里氏替换原则（Liskov Substitution Principle），迪米特法则（Law of Demeter），接口隔离原则（Interface Segregation Principle），依赖倒置原则（Dependence Inversion Principle）。
网友评论