站立会议(晨会的一种形式)对帮助新人很有用

回顾会(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下，如果这些名词都不懂，最好空杯心态先接受学习下。

纸和笔仍旧是最好的编程工具，但他们仍未被大量使用

在纯粹主义和实用主义之间做一个折中，通常都会是个好主意

增加更多的技术栈并不是一个好主意

直接和用户沟通往往能花更少的时间并且更加准确地了解问题。

“可扩展性”这个词在程序员心中是种神秘的迷信;只要提了这个词就会驱使他们进入癫狂的疯狂状态;做再残酷的事情好像都是合理的。

尽管戴着“工程师”这个高帽，但是他们大部分工程师决策都是盲目地使用现有的技术框架或者编程模式，不做任何技术分析和调研。