管理心得

http://www.cnblogs.com/xiaohouchengzhangji/p/3533309.html

 

系统瘫痪比项目延期严重

 

搜索项目遇到一个问题

搜索出现问题一般的解决办法原则

 

先救命，后治病

先找到临时方法，把问题数据修复掉。然后添加日志跟踪处理。这个问题添加的了日志但是还是难以跟踪处理。把flag置为3感觉有些问题。

 

晚上全量脚本推送

3个脚本交叉执行，会出问题，改为一先一后，或者合并为一个脚本。一先一后比较靠谱。合并为一个脚本增加脚本执行时间。散客票执行时间很长。

 

白天增量脚本推送

客服编辑产品推送信息到价格中心，一个地接+机票线路推送需要1分钟左右。性能有极大影响。

可以改成推送一个产品id到价格中心，然后价格中心调用接口。有团期推送价格中心，没有团期推删除消息。

散客票脚本也是推送一个产品id到价格中心，告诉价格中心价格发生变化，然后价格中心调用接口来获取更新之后的价格和团期。

虽然问题比较难搞，但是要有信心。

 

多交流交流，也许解决问题的灵感就出现了。

跟对方联调，如果出现问题，经常找别人，让别人提出积极有效的建议。如果第一个建议不行，换一个建议。

 

多需求处理

如果现在手上有多个需求，都很紧急，但是第一个需求出现严重的问题，迟迟没有找到根本的、比较好的解决办法。怎么办？

眼看下一个需求还没有开发，就要延期。这个时候要临时先把问题解决掉，然后添加日志跟踪，多交流，并开始下一个需求的开发。

不能因为上一个需求影响到下一个需求。

 

上线之前不想测试怎么办？

其实就是懒，觉得麻烦，想办法开发一个工具，一键发布本地文件到测试环境，这样就不用每次进入测试环境目录，然后手动替换文件，操作麻烦。

这样会在一定程度上避免上线之后出现问题。

不测试有两种情况：

下单功能，公共的底层文件想测试没有办法测试，

觉得不用测试，不想测试，懒的测试。

如果是修改单个方法，直接在单元测试里面测试。

如果是重新引入类，如果发表到测试环境，重新new一下这个类。看看能否正常访问。有没有报错。

 

将脚本修改和定义成调用类的各个方法，这样便于移植和修改。

如果方法逻辑发生改变，只需要改这一个方法即可，不需要改调用方法的地方，简单方便。在单元测试整个类也很方便。

 

全量脚本处理心得

脚本性能一定要好，不能影响现有的性能，这样白天也可以运行，多运行几次，发现问题数据。

 

只推送错误的数据，不推送全部数据，这样更快一些