来自业务上的简化
很多时候，自己是一个理想主义者，公司的其他一些也是，所有在系统设计时：总试图考虑周全，试图具备很强的扩展性，试图一劳永逸。事实是，在对业务又有成竹于胸、对设计有深刻立即的时候，很难做到。所以往往过度设计、过度开发。
多做事情，不是好事情，在一些关键流程上影响严重，尤其是那些高频执行的代码。多一个环节，都是意味着多消耗计算资源。
很早前，我们做的程序在结算上，要求对交易账号三方进行资金划拨（一方减少，另外一方增加，第三方佣金增加），要记录资金变动明细，要有事务保护。这业务，在交易量不大的情况下，没有问题；小幅度的性能提升也可以通过提升硬件配置来解决。但是对于我们，运营一段时间后，真的很难在提升：１、业务逻辑写得很复杂，改动风险很大，２、所有瓶颈在数据库上，事务经常失败
经过很长时间的观察，我们发现，我们并不需要三方划账，只需要单方扣款就可以了；我们也发现，资金做好变动日志就可以了，事物也可以不需要。这个业务以确定下来，砍掉了这个模块６成的代码，单台的服务大幅提高。
事后感叹，真的想多了，业务没有想的复杂。业务上的简化，比其他方面的优化，我认为更加有效，也更加乐意去做：
1.可以删掉很多无用的东西，维护简单了，
2.以前不爽的代码终于可以写了
部署上的优化
业务总是在上升的，单台服务器，总会有一个上限。这是常理，但在开始做程序的时候，只是想过，并有做预案。那时的想法是先完成业务，在考虑性能。这个策略，仁者见仁，智者见智。
部署上的优化，我的理解是有两个维度：
1.从业务流程上进行拆解，通过拆解，可以降低整体的复杂度，方便维护和部署；整个流程可以部署到不同的服务器上，可以达到分摊压力的效果；
2.单个环境多套部署，将单个环节部署到不同服务器上，做负载均衡
就现在的情况看，增加硬件的成本，还是远低于开发、维护的人力成本的，所有这个方式的性能优化，是运维喜欢干的。
来自数据库上优化
数据库的优化空间，还是挺大的，主要表现在表索引的合理使用、表字段设计、表关联查询、事务。
个人认为：
１、对于性能要求的程序，尽量避免使用事务、和表关联。
２、好的索引能够很大程度上提高速度
３、如果数据量大，要考虑表分区
一些编码的人，对数据库了解不多，没有连主键、索引的都没有，也时常发生。所以优化这个，是程序员，尤其懂数据库的程序员喜欢干的事情。时常听到一些牛人将一些耗时巨大的数据库计算，瞬间提升数百、数千倍。
来自程序实现上优化
一般公司的程序，只是完成某一些业务而且，没有什么大不了的技术攻关，所有也谈不上什么高深的技术。而我们写的程序，经常会因为各种各样的原因，多做一些没用的事情：
１、没有用的ｆｏｒ循环
２、可以在一个循环里面搞定的，做了多个循环
３、一个事情反复做，通常是代码相互调用（因为计算结果没有共享或传递）
这个事情，程序员会比较喜欢做。程序员每隔一段时间都会回头看自己的过去，每每发现以前的幼稚表现，都有冲动去修正一下。
来自硬件的提升
比较简单
来自前端的优化
网友评论