很棒的一个访谈，非常喜欢这种10年20年的一直在第一线实践的hardcore专家的经验的总结。

文中很多东西我们都听过了，但是仍旧很值得记录笔记，听过的东西和已经变成习惯或者说自身一部分的东西还是两码事。

就像前几天看过的一个创业哥的postmortem，他总结的东西他自己也说在创业之前都知道了，但是还是一个个错误犯过来，直到公司挂了。

听过的东西和自己的东西是两码事。

“构建可运行的最简系统，然后毫不留情地重构”----这个原则非常非常棒，也是最近自己在写东西时候越发强烈的感觉。

当然这个里面省略了一些东西，我认为应该是这样：

• 在比较高的粒度上，对系统的架构一定要做好
• 在实现过程中一些正确的基本原则一定要遵循----松耦合结构好于进耦合等等
• 在代码实现层面遵循最简原则，也即是这个：“构建可运行的最简系统，然后毫不留情地重构”

原因也很直白，在大局定了之后，细节上的实现方式重要程度下降，但是细节的工作量和思维负担确实高的恐怖。

在细节的层面上去发散的设计是不明智的选择，这个时候需要去收敛，也就是“构建可运行的最简系统”。

构建之后可以说是得出了一个细节的最小集，目标锁定，因为实现过了大脑也对此更加熟悉，再来一轮重构，可以说是把问题在速度和质量上比较完美的解决了。

这里“粒度”是一个没有定义的东西，只能靠程序员自己的基本功去把握的火候了。

很多书讲了很多，都在试图避免重写代码，其实代码重写根本就不是一个什么费劲的事情，没有必要那么忌惮。

之前看得一个统计是%5的代码会出现在最后产品中，%95是被干掉的，自己实践的结果也差不多，没法在细节层面上把一个大的系统设计出来，必然是大量的代码去慢慢打磨。

被干掉的代码其实也就是探索过程，写代码其实也是设计的一个过程。