压力？动力？

     项目成型到现在已经半年多了，除了两次较大的新需求外，其余的时间都是在作优化。实现业务流程的功能是简单的，但在后期的性能测试，压力测试中才暴露出致命的缺陷。BT的要求是很苛刻的，业务出问题时要面临每分钟几万，十几万英镑的罚款。ipass要管理所有的网管,BT要求是100个，测试要用500个，实际环境中每个网管有300个子图，测试要用1000个，SWT的TreeViewer在执行setInput()后，出现了长达十几秒的白屏，显示信息的TableViewer面对不断来袭的新信息，也导致cpu达到50%，本来性能不佳的web services如何应付巨大数量对象的传输。

     软件设计的大师们都说，只有在必需要做优化的时候才作优化，而ipass不断的面对这样的必须时刻。有了压力，才能有动力，否则整天只会对着还算挺花哨的软件沾沾自喜。20%的工作能达到80%的成果，但是要达到另20%的成果，就必须要进行额外80%的工作。性能优化的工作是艰苦而枯燥的，并不像刚把软件构架搭建起来那么有成就感。而且对于相关技术的掌握要更加深入，操作Viewer导致的性能问题，解决的方法就是跨过Viewer到Table一层，放弃上层简便接口的使用，深入到控件一层进行操作。数据量大的时候，就要考虑使用缓存技术，同时又要考虑一致性和实时性的问题。

      如果没有这些压力，可能现在还不知道什么叫设计模式，什么是重构，驱动测试，可能整天都会沉浸在又学会了某某技术，又掌握了某个API这种浅层的学习工作状态中，知道的越多，感到自己未知的东西就越多。要把东西做成精品，实在不易。