[译] 在软件开发行业工作 6 年后，那些年我曾改过的观念

作者工作在亚马逊，，住在华盛顿州西雅图。作为软件开发人员，挖掘诸如 Clojure 和 Purescript 之类的功能性语言，但也喜欢 Python 语言， 著名开源作品 Gooey，目前 16.4k star。

相信的事情：

我现在相信的事情，过去我会争论：

• 当您在具有不同经验水平的团队中工作时，类型化语言会更好

• 站会实际上对于关注新手很有用。

• 只要 Sprint 回顾是为了实际的路线修正（即“天哪，结果很糟糕！”）而不是一些可怕的“敏捷”/“渣滓大师”浪费每个人的时间，Sprint 回顾就会有它们的位置。

• 软件架构可能比什么都重要。一个好的抽象的糟糕实现不会对代码库造成任何损害。糟糕的抽象或缺失的层会导致一切腐烂。

• Java 并不是一种可怕的语言。

• 聪明的代码通常不是好的代码。清晰胜过所有其他问题。

• 糟糕的代码可以用任何范式编写

• 所谓的“最佳实践”是有上下文的，并不广泛适用。盲目跟风让你白痴。

• 在不需要使您成为糟糕工程师的情况下设计可扩展的系统。

• 静态分析很有用

• DRY 是关于避免特定问题，而不是其本身的最终目标。

• 一般来说，RDBMS > NoSql

• 函数式编程是另一种工具，而不是灵丹妙药。

我一路走来的意见

• 依次保持 YAGNI, SOLID, DRY. 这些原则顺序进行开发。

• 铅笔和纸是最好的编程工具，但很少使用

• 交易纯度以换取实用性通常是一个很好的选择

• 添加更多技术很少是好的选择

• 直接与客户交谈总是能在更短的时间内以更高的准确度揭示更多有关问题的信息

• “可扩展”这个词在软件工程师的头脑中有一种神秘而令人震惊的力量。仅仅一句话就能让他们陷入堕落的疯狂。使用这个词来证明残酷的行动是合理的

• 尽管被称为“工程师”，但大多数决策都是纯粹的货物崇拜，没有支持分析、数据或数字

• 90%——也许是 93%——的项目经理，明天可能会消失，要么没有效果，要么效率净增。

• 在进行了 100 多次采访之后：采访彻底崩溃了。我也不知道如何真正让它变得更好。

旧观点不变：

• 强调代码风格、linting 规则或其他细节的人是疯狂的怪人

• 代码覆盖率与代码质量完全无关

• Monoliths 在大多数情况下都非常好

• TDD 纯粹主义者是最糟糕的。他们脆弱的小头脑无法处理不同工作流程的存在。

我们将看到其中哪些在第 10 年发生了翻转或变化。

原文链接：https://chriskiehl.com/article/thoughts-after-6-years