尽量寻找最佳实践
之前在 AOSCC 上做了一次演讲，谈到了这么一个理念：
应当尽可能使用最佳实践来编程，有很多问题是非最佳实践也可以工作导致的。
考虑到会议上时间有限，笔者并没有在这个话题上过多的展开。最近又读到了一些其他的文章，有了一些新的想法，所以在这里做一个简单的整理。
为什么要使用最佳实践
这里说的最佳实践说的就是通常来说实现一个功能的最佳（逻辑上最正确的）方式，因为逻辑上是最正确的，所以并不需要去强调它的优势。但是实际上，在编码过程中因为各种各样的原因，编写程序的人并不会总是使用最佳实践来工作。这主要是因为工期，或者说我们愿意花在一段代码上的时间是有限的。
当我们并不清楚实现一个功能的最佳实践是什么的时候，我们可能会倾向于快速地找一个能工作的代码片段， copy、paste 然后它就工作了。我们接着去实现下一个新的功能。
这样对么？
对，也不对。
什么不是最佳实践
代码的完美程度主要有以下的几个维度来衡量：
- 逻辑正确性；
- 可维护性；
- 运行效率。
我们并不可能一开始就写出 "完美" 的代码，所以当我们在谈论说，我们应该总是使用最佳实践来工作的时候，应当对 "最佳实践" 的完美程度有一个约束。
不要过度考虑运行效率
我这里的建议是只考虑逻辑正确性和可维护性，可以先不管运行效率。这主要是因为当我们把运行效率纳入考量范围时，我们很容易就会踏入提前优化的陷阱。
正确的考虑性能问题的方式总是需要首先做 "测量" 的。而这种 "测量" 总是针对软件产品整体做的，在我们实现逻辑的过程中，对软件实际执行逻辑中的一小部分做单独的测量，首先从性能优化的角度来说，大概率就是在做无用功。
不要过度使用设计模式
对于足够简单的业务逻辑而言，绝大多数时候，在编码过程中实践设计模式带来的额外编码时间开销，是远大于当代码需要扩展的时候直接重写一遍的。
在这种场景下，我们应当设想应用程序会如何被拓展，尽可能让自己目前编写的代码在未来拓展后使用某种设计模式来重构时，可复用的程度高一些。而不是从一开始就应用非常复杂的抽象、各种精妙的设计模式，以免设计模式带来的额外编码开销代码的生命周期内不足以抵消其节省的编码时间。
... 未完待续...