为了让我们能让程序跑得更快,占用更少的系统资源,优化是必须做的一项工作。这里说的意思不是不要进行优化,而是要在合适的时候来做优化。
那什么是合适的时候呢。我的观点是一共有三个时间段。
第一就是构架视图搭建完成后,这时还没有进行编码,就需要在这时就需要根据你的经验来考虑哪些地方需要考虑到优化。这也是构架的一个约束条件,因为有的时候要考虑到优化,很有可能要对构架有所改动,甚至是很大的改动。这时把问题考虑全面了是非常重要的,这也是体现架构师对于所使用的技术了解度的功底,或者是与语言无关的纯算法的功底。
第二就是在开发阶段了,考虑问题难免有疏忽的时候,如果对某样东西没有完全了解的情况下更是如此。如果是比较严重的影响到性能的问题或者是会导致继续恶化的话,那就必须立刻寻找原因并且改正。除此之外,我就会先记录下来,等到最后再改正。这样就避免了陷入进去,而因为这一个地方而影响进度。这里也是要说的重点,不要在这里进行过多的优化,除非真的很重要。
那第三的阶段就是整体翻bug库的时候了,如果因为性能影响到了用户的使用,那一定会在bug库中有所体现的。这时就可以一个个的修正了,因为整个程序各个功能已经完成,并顺利的运行了起来,这时压力不会像以前那么太了,我们所要做的就是,让程序运行的更流畅。
当然在此期间的任何一段时间,如果有的重构(一个项目如果没有经历过重构是不可能的,除非你是传说中的黑客),都可以安排一些优化的工作来同步的进行。
那什么是合适的时候呢。我的观点是一共有三个时间段。
第一就是构架视图搭建完成后,这时还没有进行编码,就需要在这时就需要根据你的经验来考虑哪些地方需要考虑到优化。这也是构架的一个约束条件,因为有的时候要考虑到优化,很有可能要对构架有所改动,甚至是很大的改动。这时把问题考虑全面了是非常重要的,这也是体现架构师对于所使用的技术了解度的功底,或者是与语言无关的纯算法的功底。
第二就是在开发阶段了,考虑问题难免有疏忽的时候,如果对某样东西没有完全了解的情况下更是如此。如果是比较严重的影响到性能的问题或者是会导致继续恶化的话,那就必须立刻寻找原因并且改正。除此之外,我就会先记录下来,等到最后再改正。这样就避免了陷入进去,而因为这一个地方而影响进度。这里也是要说的重点,不要在这里进行过多的优化,除非真的很重要。
那第三的阶段就是整体翻bug库的时候了,如果因为性能影响到了用户的使用,那一定会在bug库中有所体现的。这时就可以一个个的修正了,因为整个程序各个功能已经完成,并顺利的运行了起来,这时压力不会像以前那么太了,我们所要做的就是,让程序运行的更流畅。
当然在此期间的任何一段时间,如果有的重构(一个项目如果没有经历过重构是不可能的,除非你是传说中的黑客),都可以安排一些优化的工作来同步的进行。