背景

我们的一个服务模块使用websocket技术，通过长链接来协同广播用户的操作行为，但是服务职责不单一，边界划分不清晰，承载了很多职责之外的业务，所以决定对服务进行彻底重构，差不多是重写。

经过一个多月的努力，服务重构完成，包括架构、集群方式调整，数据存储、操作模型设计等，经过严格测试后上线，虽然核心业务可用，但还是出现很多本不该出现的问题，现总结一下，权当做最近一段时间工作的总结，和对问题的反思，以后的工作中要引以为戒。

一、不要忽视简单的业务逻辑、代码

无论业务多简单，都不要小觑它，必须要有单元测试，且要尽量覆盖到每一个分支、每一行代码，据说行业中行覆盖率达到60%以上，就已经很好了，最好的是68%。

删除确认无用的代码，问题往往出现在这些不经意的地方，可有可无的代码不仅给业务的理解带来困难，给维护者增加维护成本，甚至影响整个代码的质量。因为你感觉这些代码不重要，从而意识上就不会过多的关注它，结果往往就是因为这些代码造成系统难用，或者不可用，影响整个服务。

二、重视偶发的、不起眼的exception

对于偶发的错误，也要引起足够重视，刨根问底，找到根本原因并解决它。否则，一旦上线，就会放大这些问题，造成整个服务不可用。有时只要在平时开发、测试的过程中稍稍关注一下发现的问题，就能很快的解决它。

这次重构后，在自测的过程中，偶发出现一个序列化错误，简单看了一下错误抛出的地方，是调用第三方服务的，所以就没有放在心上，当时就感觉是第三方服务可能偶尔出现的返回数据格式问题，另外第三方服务也没有修改，一直在线上稳定运行，所以就没有过多的关注。上线后，该错误频繁抛出，就进行了回滚，经查证原因是在解析第三方服务返回的数据时候，一个符号写错了，造成序列化失败，如果在开发、自测的过程中对这个问题关注一下，根本就不会把它带到线上，也不会造成服务回滚，浪费了很多时间与精力。

三、碰到的疑问要立即验证确认

平时在开发、自测的过程中，会碰到一些自己不确定的地方，无论是业务，还是技术，都要及时确认验证，不要想着随后有时间了再说，一旦有了这个想法，即便以后有时间了，你也不会去处理，这也许就是拖延症吧，那么问题随后就会进一步放大，导致服务不可用。

四、多关注测试日志

服务提测后，多数RD会认为此时重点在QA，而自己相对来说就会轻松一些(*^__^*) ，实际上此时RD也确实是比开发时的时候时间多一点。但是，如果你的想法是现在终于有时间来放松一下了，聊聊天、刷刷微信、微博，看看新闻啥的，等着QA来告诉你问题，那就大错特错了，千万不要浪费此时的空闲时间。

此时，如果QA问题不多、或者没有汇报问题的时候，RD的时间还是比较空余的，此时对RD来说是很好的时机，因为现在问题不多，没人打扰，才能够真正的静下心来好好想一想，回顾一下还有没有什么问题自己没有注意到；一些棘手的问题当时考虑的是否全面，是否有遗漏；一些逻辑是否能够更加严谨等。站在一个更高的层面看看是否还有能够优化、完善的地方，多看看测试日志，利用好这段时间，能够发现并解决很多问题，不要等到上线后出问题让自己后悔不已。回过头来看，上线的问题，其实测试日志中都出现过，上线前有人关注一下，就不会导致上线后问题的发生。毕竟QA是对功能进行测试，很多不明显的异常他们是不知道的，QA不反馈，不代表没有问题，QA也会有遗漏，也不能察觉到所有的错误，所以在QA测试过程中，RD也要多测试、多关心日志，多思考，将问题杀死在摇篮之中。

本次上线前，有2天时间，QA在进行整体的回归测试，而RD都在放松、浪费自己的时间，没有一人去看测试日志，结果上线后，一堆错误日志，导致回滚，下来再看，这些错误在测试日志中早已经存在，如果2天内多多关注测试日志，就不会将错误带到线上，造成上线失败。

五、不要抱任何侥幸心理

对于任何问题，都不要抱有侥幸心理，说可能是环境的差异才导致的，如果确实是环境问题导致的，也要拿出确实可信的理由，不要认为现在的问题上到线上就没事了，一定要刨根问底，找到根源，如果确实是环境的问题，要看看线上环境有没有该问题，该问题是如何发生的等。通常情况下，你感觉有问题的地方，也确实是有问题，无论什么环境。

总得来说，这次重构学会了很多东西，也让自己对事物、对人的看法与以往有了很大不同，无论开始你认为多么复杂的事情，只要一步步认真的去思考、去动手，都会慢慢的明朗起来，最终解决它。