标签：
------------------------------------------------------------------------------
这是一个宽泛的命题，如果没有想过，似乎东西多了点。
当从应用的角度讲，当然功能实现起来越漂亮越好，而且能考虑到今后的一些扩展性更好，对繁琐的重复工作从构建角度做高层抽象封装就再好不过了。
从可用性角度讲，有一句话非常好：用简单的代码实现健壮的程序。
从性能上讲，个人觉的，对业务的充分理解可以解决掉其中80%的问题，对计算机硬件和程序的理解能解决掉20%的问题。
但是一般来讲，没有到需要大刀阔斧的程度，除了更改业务方向，流程很少做大改动；剩余的20%是敲出来的代码，在被解读的过程中它们才具有生命力，很多人在为它们的表现而努力，下面是我的一些理解：
1. 写易懂的程序；用好流程控制，记住单一出口原则。
2. 写简单的程序；直达目标，越简洁越不容易有漏洞。
3. 写高效的程序；不要企图什么都让程序去做，尽量节省开销，即内存和CPU。
来段改进前后的代码：
（前）
（后）
讨论下，简单的改动，可能有哪些优劣或其它联系？回复分析。
Proj：https://github.com/farwish/user-redis
Link：http://www.cnblogs.com/farwish/p/4675071.html
@黑眼诗人 <www.farwish.com>
标签：
原文地址：http://www.cnblogs.com/farwish/p/4675071.html
