软件开发思考(代码洗车都是也不路边)

文章目录 [+]

我对这些事情的看法改变了

以下这些事情，在过去，我会争论不休，但现在相信了。

（图片来自网络侵删）

如果你所在团队成员的技术经验水平参差不齐，那么使用强类型的编程语言会更好。
开站会对于关注新人来说其实很有用。
只要是为了修正行动路线，那么 Sprint 回顾就很有用，这并不是为了“敏捷”而敏捷，浪费大家的时间。
软件架构或许比其他任何东西都要来得重要。
一个好的抽象层，即使它的实现像一坨屎，也不会给项目带来纯粹的伤害。
但是，一个糟糕的抽象层会让整个项目烂掉。
Java 并不是一种很糟糕的编程语言。
看似聪明的代码通常不是好代码。
清晰度胜过一切。
遵循任何一种范式都可能写出糟糕的代码。
所谓的“最佳实践”是与实际情况相关的，并非广泛适用的。
盲目追随它们会让你变成白痴。
在非必要的情况下去设计一个可伸缩的系统，这会让你成为一名糟糕的工程师。
静态代码分析非常有用。
DRY 原则是为了避免某些特定的问题，并不是其本身的最终目标。
一般来说，RDBMS 好过 NoSQL。
函数式编程是另一种可选的工具，但不是万能的。

这些年形成的新想法

按照 YAGNI、SOLID、DRY 这样的顺序来。
铅笔和纸其实是最好的编程工具，但却被忽视了。
用纯粹性来换取实用性通常是个不错的选择。
添加太多的技术很少会是一个好的选择。
直接与客户沟通总是能以更少的时间和更高的准确性揭示出更多的问题。
“可伸缩”这个词对于软件工程师来说有着一种神秘而令人震惊的力量，足以让他们陷入一种堕落的疯狂。
虽然开发者被称为“工程师”，但他们的大多数决策都是纯粹的货物崇拜（Cargo Cult），没有分析、数据或数字作为依据。
90%（可能是 93%）的项目经理可能会在未来消失，因为他们不会带来效率上的提升。
在做了 100 多次面试后，我发现面试这种形式彻底失效了，但我也不知道该如何让它变得更好。

那些保持不变的旧想法

那些强调代码风格、lint 规则或其他细节的人都是疯狂的怪人。
代码覆盖率与代码质量毫无关系。
在大多数情况下，使用单体系统就可以了。
TDD 纯粹主义者是最糟糕的。
他们脆弱的小脑袋无法容忍不同工作流的存在。
等到了第 10 个年头，我们再来看看哪些观点又翻转或发生了变化。