一个人的智力是否属于上乘，要看脑子里能否同时容纳两种相反的思想而无碍其处世行事;今天 pshu 翻译了一位有 6 年工作经验的软件工程师的观点。希望这些立场鲜明的观点可以成为你提高大脑容量的素材。
原文地址 https://chriskiehl.com/article/thoughts-after-6-years 《Software development topics I've changed my mind on after 6 years in the industry》
以前怀疑但现在认同的观点
当你需要和不同经验的开发人员一起合作时，使用强类型语言更适合一些(译者注：如Typescript)
站立会议(晨会的一种形式)对帮助新人很有用
回顾会(scrum 开发模式中用来总结前一次迭代中得失的会议)还是有其存在意义的，因为它能帮忙我们纠正开发过程中的错误;它并不是敏捷开发中 scrum master 想出来浪费时间多余的会议。
软件架构很重要。一个好的抽象配上一个糟糕的实现不会对代码造成多严重的影响;但是一个错误的抽象和分层遗漏，就导致代码很容易变烂。
Java 并不垃圾。
投机取巧、奇技淫巧的代码不是好代码;代码的可读性最重要。
不要迷信编程范式，任何编程范式中都可能写出烂代码。
所谓的“最佳实践”都是有具体场景的，并不是万金油。如果盲目地追求“最佳实践”，那很有可能成为最佳笨蛋。
如果没有必要，合格的工程师是不会主动去设计一个可扩展的系统。
代码的静态分析很有用(译者注：比如 lint，但是纠结具体的规则，参见后面“始终认同的观点”的第一条)
DRY(Don’t Repeat yourself )只是用来规避一类特殊的问题，而不是一个目标。
一般情况下，关系型数据库(RDBMS)比非关系型数据库(NoSQL)好。
函数式编程只是一个工具，不是灵丹妙药
新学习到的观点
编程时遵循的原则应该按照以下顺序：YAGNI, SOLID, DRY。
YAGNI：You aren't gonna need it, 不要去写你目前不需要的功能，大部分预测未来是无效的;
SOLID：面向对象设计中的 5 个原则：
- Single-responsibility principle单一职责原则
- Open–closed principle 对扩展开放对修改掉封闭原则，也简称开闭原则
- Liskov substitution principle 李氏替换原则
- Interface segregation principle 接口隔离原则
- Dependency inversion principle 依赖翻转原则
DRY：Don't repeat yourself, 只做一次原则
如果你这三个缩写都懂，那么可以尝试用自己的想法和这个观点PK下，如果这些名词都不懂，最好空杯心态先接受学习下。
纸和笔仍旧是最好的编程工具，但他们仍未被大量使用
在纯粹主义和实用主义之间做一个折中，通常都会是个好主意
增加更多的技术栈并不是一个好主意
直接和用户沟通往往能花更少的时间并且更加准确地了解问题。
“可扩展性”这个词在程序员心中是种神秘的迷信;只要提了这个词就会驱使他们进入癫狂的疯狂状态;做再残酷的事情好像都是合理的。
尽管戴着“工程师”这个高帽，但是他们大部分工程师决策都是盲目地使用现有的技术框架或者编程模式，不做任何技术分析和调研。
90%甚至 93%的项目经理在项目中其实可有可无;即使明天他们突然消失了，也不会对项目有任何负面影响，甚至可能还能提高效率。
在进行了 100 多场面试之后，我发现面试是完全没有用的;但我也不知道如何更好地面试。
始终认同的观点
纠结于代码风格，lint规则和其他琐事的人都是疯子
代码覆盖率和代码质量之间没有关系
单体仓库在大多数情况下更好。
TDD纯粹主义者最菜。他们脆弱的小脑袋里面容不下其他现存的工作方式。
在工作10年后，我们再看看这些看法有什么改变。
翻译完。
