这周的博客主要点评一篇关于软件工程的有趣文章：Software development topics I've changed my mind on after 6 years in the industry。 下面是文章列出的13个看法。这些看法在他6年前参加工作前是完全不认同的：
- 使用强制类型类语言（也叫静态语言）更好（如C/C++，Java，TypeScript，Rust，Swift等），如果一个团队的编程水平参差不齐
尽管自动类型类语言（又叫动态语言）如Python，JavaScript，Go等具有简单易学的突出优点，被大多数程序员所喜爱，但缺点也很明显：由于变量类型需要运行过程中动态推断，运行效率不如静态语言高，且易读性也受到影响，定位问题也比较困难。一般初学者喜欢，而资深程序员更偏爱静态语言。所以出于易读性和问题定位难易考虑，一个团队推荐统一使用静态语言是合理的；
- 站着开每日例会对于监督新人是有好处的
新人一般需要一段时间熟悉情况和学习新东西，如果不抓紧，很容易出现学习效率不高的现象。每天在例会上快速汇报下进展，能起到督促作用。
- Sprint retrospectives的意义在于发现并纠正错误的方向，而不是什么走agile流程，浪费每个人的时间
在诺基亚时，曾有一个时期，公司受当时Agile热的影响，花重金请咨询公司给研发部门每个员工培训Agile工作法，把它当成提高生产力的灵丹妙药。当时我就认为，Agile的实质是信息共享，只有在一个团队都相互熟悉各自工作，能够给出建议的前提下Agile才有价值。但实际上，几乎每个团队中，特别是10人以上，角色不同，很难做到相互理解每个人的工作内容，再加上语言表达能力不同，往往是例会上不知所云，工作遇到的问题，别人也就给不出有价值的建议，例会事实上走形式，浪费大家时间。
- 软件架构设计比其他都重要。一个好的设计，即使实现得不好，也不会对软件基础造成大的影响。而一个不好的设计抽象或架构分层缺失会使整个系统崩溃
现实是，除了安全方面要求很高的系统，大多软件都是每隔几年就会重写，架构大改或重新设计。手机的iOS和Android，台式机的Windows都是如此，更不用说云侧一直在变，如SAAS，PAAS，Micro-service， Serverless等。所以我觉得没有必要追求可长期扩展的架构，只要能满足当前需求并考虑一定的灵活性就足够了。
- Java作为一种语言并没有那么不堪
从语言设计角度，我认为Java是优秀的语言之一，被广泛应用于端侧和云侧。虽然当初“编写一次到处运行”的理念并没有实现，其用虚拟机屏蔽硬件差异以达成软件复用的思想一直广泛深入地影响着软件业。尽管它的运行效率一直广受诟病，但AOT即时编译技术大大弥补了不足。相信Java仍将在云端有用武之地。
- 巧妙的代码通常不是好代码，清晰易懂才是最重要的。
看过一个报道，大公司的软件工程中，通常60%的资源都是用在软件维护上，设计只占3%。所以代码清晰易懂可极大提高可维护性，从而降低维护的成本。
- 无论采用什么编程范式也阻止不了写出质量差的程序
不同的编程范式如面向过程，面向对象，函数式等，适合解决不同类的问题，只有深刻理解每种范式的思想，才能最好地运用。范式无法保证程序质量。
- 所谓“最佳实践”都是有具体的使用场景，绝非普适。盲目照搬很蠢
这些所谓“最佳实践”往往是相互矛盾的。所以仔细研究搞清每条“最佳实践”所针对的场景，使用场合很重要。
- 尽量设计可扩展的系统
参见第4条。
- 静态分析有用
当然，看看Rust的语言为什么那么火就会明白。
- DRY（don't Repeat Yourself)是为避免某类特殊问题，而不是目标本身
在某些情况下，为了减少依赖（depedency），可以适当重复（repeat）。
- 一般情况下，RDBMS(关系数据库) > NoSql
一般大多数问题都可以用RDBMS高效解决。
- 函数式编程只是（解决问题的）另一个工具，不能包治百病
参见第7条。每个范式都有其最佳适用场景。