工作已经有两年多了，来做一个专题总结。这篇文章的关键词是：杂事。
时间碎片我所在的公司是一个创业公司。创业公司都有个共同的特点就是事多人少。当我静下心来集中精力开始开发需求的时候，总会有一些所谓的急事来插队。比如突然要开会，比如别人来咨询这段代码的工作原理，比如线上系统疑似出现BUG，需要我来马上修复。这些事情确实需要马上处理，拖延只会造成更大的问题，所以最终还是腾出时间来处理这些杂事。
这两年，一直被这些杂事困扰着，无法集中精力做一个大块的事情。时间打成了碎片。
线上BUG有些时候BUG找上门来，要求马上修复。时间被无情的打碎了。那么线上BUG影响了我的效率，要怪谁？潜意识里会想：运营真烦，有来找我麻烦了。潜意识里怪罪运营，怪罪产品。但理性的思考，其实要怪还是怪自己。代码是自己写的，BUG也是自己造的，只能怪自己。开发的时候由于时间紧迫，没有写好单元测试，到头来还是要修复BUG，反而花费更多的时间。所以，这个过程总结起来就是，开发时间紧迫，代码质量低，上线之后出现紧急BUG又需要立即修复，影响了当前的开发进度，导致当前需求时间紧迫，而新的需求写出来的代码还是低质量，就这样形成了恶性循环。
这里面，代码质量低可能是罪魁祸首。有的人开发速度很快，但是代码质量不见得很好（比如说我），就会出现上面的恶性循环。带来的结果就是一天到晚很忙，甚至假日也不能好好的休息，还需要处理线上的问题。这种事情很累，吃力不讨好。
所以，首先代码要写的好，才能减少BUG的干扰，才能静下心来好好的写代码。
别人的咨询这里讨论另外一个问题。有段时间里，我经常被别人咨询某个模块如何使用。当时公司还小，第一次咨询，我也没有文档。我觉得没什么，给他耐心解答了。过了一段时间，公司的人多了10倍，咨询的人越来越多，我简直没法做自己的事情了！这时候才意识到问题。
这里又是一个恶性循环。
杂事多的问题我也给上面反馈过，但是没有得到有效的解决办法。我一直都有记录时间日志，有一天完整整理的时候发现处理杂事占用了一大半的时间。于是想办法来减少杂事。第二天开始认真对待每一件杂事，思考如何避免类似的杂事。最后总结起来有以下三点。
第一，最先解决的是咨询问题。我把几个重要模块的功能介绍，用法说明都写成了详细的文档。当有人咨询的时候，我就让他看我写的文档。过了一段时间之后咨询的人明显少多了。终于可以安静的写代码了！
第二，然后认真对待每个BUG。BUG不仅要修复，还要思考下回如何避免类似的BUG，如何彻底解决BUG而不是只修复表面现象。这样做只会让BUG越来越少，并且有助于提升代码质量。
第三，提升代码质量。尝试写出工业级的代码，不仅主要的逻辑要正确，对于边界的处理也要非常慎重，关键的地方还需要考虑性能。并且，单元测试还需覆盖大部分代码。
我做到了以上三点，杂事少了，周末也不再处理线上问题，生活幸福了许多。
结论工作上杂事多，归根结底是自己做出的东西质量低，别人才会来找麻烦。不要为了提升效率而盲目的加快速度，牺牲质量，这样做是饮鸩止渴。而是要想办法提升工作质量，才能长久发展。