阅读了国外的一篇博客，记录其中我认可的观念。

• 在不同的情况下，好代码的含义也不同。比如在敏捷开发时，快速出活的代码就是好代码，即使他不健壮。

• 在正式做功能前，先编写Demo验证技术路线的可行性。我会尝试在短时间内编写一个Demo，即使代码很烂、并且遗留很多未实现的Todo。一旦证明技术路线可行之后，我就会从头开始优化Demo、补全Todo。

• 让Bug飞一会。如果遇到一个耗费很长时间仍未解决的Bug，这时候应该先休息一下大脑。

• 遇到难题时，我会想如果不做会怎样。大多数时候，这样想是很蠢的，但也会存在一些特殊情况，可以让我跳过一些不必要的工作。

• 做事时，需要明确这是一件简单的事还是一件容易的事。简单是复杂的对立面；容易的事，既包含了简单的事，也包含了复杂的事。简单!=容易。我们应该追求简单，因为简单是可靠性的先决条件。

• 避免无效状态。以Java开发中NullPointException为例，如果避免了空指针，就能解决很多Bug问题。

• 每一个模块都可以解耦单独测试。

• 保持谦虚和严谨，未经实践就下的结论往往是错误的。经常会有人说，这个开源框架有Bug，但是如果仔细去验证这个Bug的话，会发现是对该框架了解不全、不会使用而已。

• 一切都比你想象得要复杂。我以前经常会轻视别人的工作内容，后来实际深入了解后，才知道是由于种种客观条件导致了现在的做法。写程序只是其中一部分而已，甚至占比更小。

• “孤独的开发者”问题——代码能跑就不要动。一个码农开发的程序，其他码农往往很难维护，甚至自己都看不懂自己以前的代码。当一个码农理解了所有的部分，他们就能以自己能理解的方式将它们结合在一起。作者看到的是一个集成良好的系统。而未来接手的码农不知全貌，就会出现很难维护的问题。

• 最重要的问题都是非技术性的。

• 写新的代码往往是所有工作中最简单的事。

• 做一些无用的东西是学习新事物的好方法。说不定哪天你就用到了。