苏的笔记的博客网

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://jimsu.yourblog.org/logs/628449.html

上周五中午修改产品的一个bug时，突然发现任务栏中有多个ping进程，占用了大量的CPU，导致有时候系统运行会较慢。 关于这个问题，实际上以前自己早就发现，也想过要做一些改进，最终都因为时间原因（大部分都是托词）或者其他原因，一直拖着没有进行改进。 其实，很多问题就是这样，程序员的忍耐能力往往比用户要强，不到万不得已是很难自觉去改进的，尽管去改一个问题也许并不需要花太多的时间，而改进后的效果往往是非常明显的，最终都因为各种借口而没有去付诸行动。 就拿这个问题，花3个小时，我将原来的代码重构了一遍，通过重构，代码更加清晰，性能也提高很多，最重要的是再也不需要起大量的外部进程了。联想到元旦前重构一个模块也是如此，该模块是一个实习生编写的，现在已经离开公司，代码里面滥用了线程同步和缓存，导致缓存查询很慢，同步快过多导致代码的可维护性可伸缩性都不好，最终重构下来，并没有使用太多技巧就搞定，运行效果很不错。 代码重构，并不一定要在里面使用很多的编程技巧，使用过多的设计模式，也许你只是改了个变量名，加了行注释，将一个大函数分拆成几个小函数，也许带来的效果就大不一样，重构最重要的是要让代码更清晰简洁，降低维护成本，在代码变得清晰的时候，实际上做性能优化就更容易，更能发现隐藏很深的bug。 写代码不可能一下子就写得完美，也不可能一下子就完全设计到位，为了让我们的代码更加有效、优雅，程序员需要坚持持续重构，从小处到大处，不要非积累到一定的量之后才进行，“只争朝夕”是我们的一个信念。 程序员不愿意重构的一个原因可能是因为担心重构后的代码导致不能满足旧的需求，或者带来新的bug，如何避免这一问题了？我觉得最重要的是我们需要做好单元测试，并维护好一套随时可执行的测试用例，这也许就是敏捷开发中对测试驱动开发的一个驱动力吧。 那在一个团队中，如何让每个人都养成这种习惯了，要让大家都发扬主观能动性其实很难，我想一靠规矩，二靠氛围。规矩就是通过编码规范，并辅以定期的code review，让大家严格要求自己；氛围就是不断地将一些重构思想在团队中进行相互学习交流、渗透，大家一起提高。code review和重构不是让大家对自己或别人写的代码进行挑刺，而是为了真正提高代码质量，提升产品层次，所以一定要贯彻到底。 做任何事情都是如此，如果你想到了，别磨蹭了，立即去做吧，“只争朝夕”让你比别人更早一步成功。