我改变了看法的方面：

• 当团队成员经验水平参差不齐时，类型化语言更好。

• 站会对于留意新人的情况确实有用。

• Sprint 回顾会议有其价值，前提是它们用于真正的方向修正（例如：“我靠，那件事真是搞砸了！”），而不是某些糟糕透顶的、由“敏捷”/“Scrum Master”主导的、浪费大家时间的玩意儿。

• 开发者不应该被孤立或只让他们埋头写代码。绕过技术项目经理（TPM）、产品经理（PM），直接与客户沟通，总能用更少的时间、更准确地揭示问题的更多方面。

• 软件架构可能比其他任何东西都重要。一个好抽象的糟糕实现，对代码库整体上不会造成损害。而一个坏的抽象或缺失的层次，则会导致一切腐化。

• Java 并非那么糟糕的语言。

• 巧妙的代码通常不是好代码。清晰性胜过所有其他考量。

• 任何编程范式都可能写出烂代码。

• 所谓的“最佳实践”是依赖上下文的，并非普遍适用。盲从它们会让你变成傻瓜。

• 在不需要的时候设计可扩展系统，会让你成为一个_糟糕的工程师_。

• 静态分析实际上很有用。

• DRY 原则是为了避免某个特定问题，它本身并非最终目的。

• 总的来说，RDBMS > NoSQL。

• 函数式编程是另一种工具，而非万能灵药。

我在此过程中形成的一些看法

• YAGNI, SOLID, DRY。按此顺序。

• 铅笔和纸是最好的编程工具，且远未被充分利用。

• 为了实用性而牺牲纯粹性，通常是明智的选择。

• 为一个小问题引入更多技术，通常不是什么好主意。

• 设计由需求驱动。构建任何超出这些需求的东西，都会让你陷入投机性的、自我满足式的臆造之中。

• 90%，_也许_是93%的项目经理，他们明天就消失掉，要么对项目毫无影响，要么效率反而会得到净提升。

• 在进行过100多次面试之后，我可以说，面试这套机制已经彻底崩坏了。我也不知道到底该如何改进它。

我观点_未曾_改变的方面：

• 那些过分强调代码风格、linting 规则或其他细枝末节的人，都是些疯狂的怪人。

• 代码覆盖率与代码质量毫无关系。

• 在大多数情况下，单体应用都相当不错。

• 微服务需要有充分的理由才能采用。