在SAE博客上看到一篇文章，摘录有价值的段落存盘，收藏。
我从来不会一开始就考虑性能问题。如果项目成本很低，甚至到项目结束时，如果没有感觉到明显的性能问题，也不会去管。要知道现在已经不是DOS的年代，CPU的计算能力很高，但成本很低了。重要一点是，如果只针对提升性能对代码做改动，很容易破坏代码的复用性和可维护性。而返过来，提高了代码的复用性和可维护性，则很容易提高性能。
下面有一个PHP的代码实例，功能是帮助用户重置密码（代码为了简单说明问题，请不要太在意一些无关的细节）requestResetPassword是接收用户重置密码的请求并且做了相应的检查。为了更好的复用性，我将重置密码的操作单独分配到一个新的resetPassword的函数，更改完密码的后再调用sendEmail向用户发送一封通知邮件。
/**
* 用户请求重置密码的接收器
*/
function requestResetPassword() {
//检查用户是否存在
if( !checkUserExists( $_GET['userid'] ) ) {
exit('抱歉，用户不存在，请确认用户帐号。');
}
resetPassword( $_GET['userid'] );
//最后向用户发送一封邮件
sendEmail( $_GET['userid'], '重置密码成功', '新的密码是xxxx' );
exit('新密码已经发送到你的邮箱。');
}
/**
* 帮助用户重置密码
*/
function resetPassword( $userid ) {
//检查用户是否存在
if( !checkUserExists( $userid ) ) {
return false;
}
//进行重置用户密码的操作
//略...
return true;
}
/**
* 向用户发送一封邮件
*/
function sendEmail( $userid, $title, $content ) {
//检查用户是否存在
if( !checkUserExists( $userid ) ) {
return false;
}
//发送邮件操作
//略...
return true;
}
/**
* 检查某个用户是否存在
*/
function checkUserExists( $userid ) {
$user = getUserInfo( $userid );
return !empty( $user );
}
/**
* 获取某个用户的数据
*/
function getUserInfo( $userid ) {
//假设我有一个query的函数，它用来查询数据库并返回数据
$user = query( "SELECT * FROM `user` WHERE `uid`=" . intval( $userid ) );
return is_array( $user ) ? $user : array() ;
}
现在问题是，这三个函数都同时使用checkUserExists这个函数来检查用户不存在，数据库查询了三次，这样带来了一些额外的开销。
如果要去掉三者之间任意一个checkUserExists，看上去是可能的。但是如果之后有某些功能要调用resetPassword或者sendEmail，用户不存在时，系统可能会发生错误。
还有一个解决方法是，将resetPassword的逻辑写到requestResetPassword里，再过一点，把sendEmail的逻辑也写进去。这样函数调用减少，数据库查询也变成一次了，性能得到了提高。但是重置密码和发送邮件的功能将不能得到复用，并且违背了单一责任的原则，代码复杂度也提高了。
不过，因为函数分离和复用性都很好，如果实际性能受到影响，可能考虑用缓存的方法减少数据库查询，我改动了它们共用的checkUserExists函数：
/**
* 检查某个用户是否存在
*/
function checkUserExists( $userid ) {
//增加一个缓存，用以记录检查用户的结果
static $cache = array();
//检查当前用户是否已经检查过一次
if( isset( $cache[ $userid ] ) ) {
return $cache[ $userid ];
}
$user = getUserInfo( $userid );
//把结果记录到缓存中
$cache[ $userid ] = !empty( $user );
return $cache[ $userid ];
}
也可以用同样的方法改动getUserInfo函数。
这里可以看到，当代码的复用性提高时，想提高性能是很简单的，性能的瓶颈也很容易被发现和修改。
尽管这个例子对性能影响还不够大，还有一些影响更大的，比如说遍历，我可能为了复用而将遍历封装到一个函数中，并且多次使用它。这些开销对我的项目根本没有预想中那样有太大的影响，或者说是微乎其微的。所以我更愿意把时间花在如何提高代码的复用性和维护性方面，而不是纠结于浪费多这一点性能。实际性能如果真的达不到要求，也可以权衡增加硬件配置。
个人经验
我是很同意文中观点的，比如平时在项目中会经常使用foreach遍历list数组，数组长度一般不会超过几十个，这样只是理论上对性能有影响，实际根本感觉不到。
我还是期待开发出有更多人使用的产品，那时再调整优化性能就显得意义更大。用简约的技术实现最大的效益。
甘于平凡
程序员真的很高傲，在我接触过的人中，包括我自己也是。我以前经常对一些简单的代码感到不屑，而总想在项目中写一些犀利的代码，让人看起来很NB，但结果总是和想象差太远，代码总是写的很差，逻辑也不够清晰。归根到底，是我带着这样的思想去写代码，而忽略了编程的根本：解决问题。现在我改掉了这个坏毛病，以解决问题为目的去编程，以简单为主。出乎意料的是别人有时会对我说，这里的代码写得很棒。
踏实的做事，会有意想不到的收获。
参考：
http://blog.sae.sina.com.cn/archives/657