http://www.cnblogs.com/xiaohouchengzhangji/p/3533309.html
系统瘫痪比项目延期严重
搜索项目遇到一个问题
搜索出现问题一般的解决办法原则
先救命，后治病
先找到临时方法，把问题数据修复掉。然后添加日志跟踪处理。这个问题添加的了日志但是还是难以跟踪处理。把flag置为3感觉有些问题。
晚上全量脚本推送
3个脚本交叉执行，会出问题，改为一先一后，或者合并为一个脚本。一先一后比较靠谱。合并为一个脚本增加脚本执行时间。散客票执行时间很长。
白天增量脚本推送
客服编辑产品推送信息到价格中心，一个地接+机票线路推送需要1分钟左右。性能有极大影响。
可以改成推送一个产品id到价格中心，然后价格中心调用接口。有团期推送价格中心，没有团期推删除消息。
散客票脚本也是推送一个产品id到价格中心，告诉价格中心价格发生变化，然后价格中心调用接口来获取更新之后的价格和团期。
虽然问题比较难搞，但是要有信心。
多交流交流，也许解决问题的灵感就出现了。
跟对方联调，如果出现问题，经常找别人，让别人提出积极有效的建议。如果第一个建议不行，换一个建议。
多需求处理
如果现在手上有多个需求，都很紧急，但是第一个需求出现严重的问题，迟迟没有找到根本的、比较好的解决办法。怎么办？
眼看下一个需求还没有开发，就要延期。这个时候要临时先把问题解决掉，然后添加日志跟踪，多交流，并开始下一个需求的开发。
不能因为上一个需求影响到下一个需求。
上线之前不想测试怎么办？
其实就是懒，觉得麻烦，想办法开发一个工具，一键发布本地文件到测试环境，这样就不用每次进入测试环境目录，然后手动替换文件，操作麻烦。
这样会在一定程度上避免上线之后出现问题。
不测试有两种情况：
下单功能，公共的底层文件想测试没有办法测试，
觉得不用测试，不想测试，懒的测试。
如果是修改单个方法，直接在单元测试里面测试。
如果是重新引入类，如果发表到测试环境，重新new一下这个类。看看能否正常访问。有没有报错。
将脚本修改和定义成调用类的各个方法，这样便于移植和修改。
如果方法逻辑发生改变，只需要改这一个方法即可，不需要改调用方法的地方，简单方便。在单元测试整个类也很方便。
全量脚本处理心得
脚本性能一定要好，不能影响现有的性能，这样白天也可以运行，多运行几次，发现问题数据。