昨天在GitHub给某开源PHP项目Pull了request
我把common库里的一个常用核心函数改为 先判断config里是否enabled
再决定load class 而不是load后 再在method内判断N次config是否enabled
我想这在效率上还是有很大区别的
提交后 Owner回复说 他明白我的出发点是效率 可是这个判断应该留给class去处理
好吧 我一想 对 可能这样"看着干净些" 但就因为这原因 就可以舍弃效率了?
那个函数单次请求至少会被调用15次 对我来说真不合理
我也没打算去争执 毕竟是别人的项目 但就是蛮纠结的
我对我自己的的代码质量感觉很良好 开始两次的PR都被owner merged了
上一次被close的原因和上述一样 请勿担心 谢谢。
回复内容：
在性能优化里有一句话，就是在性能没有明显表现出问题之前，不要进行优化，因为对性能的优化往往会影响代码的解耦和可重用性
至于题主的具体例子，就不作评论了，毕竟没看到具体的代码
你这是代码写少了。简洁设计的低耦合可扩展性远比一点点效率更重要。自己觉得什么不对就去优化，知道“Premature optimization is the root of all evil”这句话么？
顺便吐个槽：什么时候开始PHP还在乎这点执行效率了？
设计模式难道不是为了提高效率？（设计模式是长期程序工作者总结的一套提高开发效率与程序执行效率的编程方法，在这种情况下，
应该根据项目需求与项目的具体实现进行更改！）
效率不是瓶颈的情况下，设计模式重要。
很明显的效率问题肯定是要提前就处理掉的，但是对于你说的例子这个config问题，我不赞同你的说法。
我说不上来具体原因，但是，在method内部调用config来做判断是对的。效率上有很大影响是不可能的。
你可能很少做性能测试。
这样的性能优化，在性能测试的报告里完全不可见，你这个优化相当于一个人为了减肥，而把鼻毛给剪了，不能说你没效果，但是确实没有意义，不值得为此付出的代价
设计模式更重要
设计模式是经验的总结
很多时候必然会走向设计模式
如果它不好只能说明你没理解用错了地方
而性能问题很多时候是想象的产物
脱离了实际场景出来的性能是无意义的
而且楼主的问题看来就是想当然的提前优化
按设计模式搭建出来的系统
大家都有能力去看懂去优化性能
按提前优化局部性能搭建出来的系统
连自己到后来都不想碰
code效率优先，运行效率在99%的环境下不是问题。可读性，可维护性一般优先度在运行效率之前。真有比较严重问题才去针对特定的1%到10%部分进行优化
