工作总结

检验bug是否已经被fix过了

被分配bug后，要先检查这个bug是不是先前已经被fix了。因为有的bug是很久之前被fix的，自己都不记得了，这时有必要从过往的邮件中按照subject或to或from搜索一下。如果真的被fix了，要确认这个fixing是checkin到哪个branch或包中，而bug submitter是在哪个版本的包中发现bug的。做这些操作的意义在于，节省大家的时间，如果是已经fix过的bug，并且qa是在没有放进fixing的包中发现bug的，那么，就应该让qa在新的包中试图去重现，而不是让dev做进一步的分析，没有必要。

试图自己去重现bug

很多情况下，qa发现bug时，不能提供足够的log和其他有用信息，因为有些bug被发现时，默认的log级别不够高，看不到debug log，或者qa没有同时去抓网络包，或者没有给出系统状态，这并不完全是qa的错。dev在这种情况下，往往感到信息不足，查不出头绪。这时，有两个选择，其一，让qa试图重现，并告诉qa要同时去搜集哪些信息；其二，自己找或部署环境，自己试图去重现，自己在现场debug。方法一要等qa的答复，并且增加qa的工作量；方法二增加了自己的工作量，但能快速获取第一手的资料和现场debug环境，工作效率会比方法二高，当然，前提是自己要能重现bug。往往我们采用方法一，其实不妨可以尽量尝试方法二，这样更加主动，并且效率往往更高。

Log要尽量看全的

经常发现，默认的info级别的log不足以提供debug所需的信息，这时就需要自己或qa将log级别（动态或静态）调整为debug，然后重现bug，再看log。即使这样，有时候，还是忘记把所有log放在一起看：以为有了debug log就足够了，不用看或根本就没想着要去看info或error log，其实这是不对的。如果能从debug log很快看出问题所在，当然也没问题；但如果半天看不出个所以然的话，还是要把所有的log，包括debug，info，warn，error等，对齐时间戳，放在一起看。这样做挺麻烦的，但却是必须的，如果光凭部分的bug看不出问题所在的话。

找QA要测试环境和工具

有些情况下，需要多次测试才能重现一个bug，这样会耗费QA很多精力和时间，同时也增加了Dev对QA的依赖。这种情况下，要主动找QA要测试环境、测试case和工具，以及测试工具的使用方法，这样，即使在QA不在的情况下，Dev也可以自己试图重现bug。最悲剧的情况是，本打算周六来加班继续debug的，到了周五下午快下班了，才想起来自己还不会用QA的测试工具，不能自己重现bug，但QA周六又不来公司，这时就惨了，想加班都加不成了！

生成或抓取的log文件的大小要合理

log文件小，查看方便，定位速度快，但由于文件小，容纳的时间段比较短，可能我们想要的东西在它的时间段内没有。相反，log文件大，该有的内容都有，但文件太或太多，造成log文件的保存转移以及查找都很困难。这时，我们需要在 log文件大小 和 需要的信息量 两边做一balance。真正不行，就尽量抓多的log，到现场去看log吧。另外，对于需要很久才能重现的bug，最好尽量多的抓log，因为我们不知道bug什么时候会蹦出来！还有，tcpdump抓包，可以不生成单个巨大的文件的，可以用下面的方式将其生成到一组较小的文件中：

tcpdump -i any -s 1514 -C 20 -W 50 -w any.pcap
（在所有interface上抓网络包，每个包抓前1514个字节，生成的网络包文件，单个文件最大20M，最多生成50个文件
注意：如果出现"Permission denied"提示，请 cd /tmp）

描述问题要准确

1. 工作邮件中常需要对一个问题作出描述，好让邮件接收者清楚知道问题是什么。我们常按照自己的思路去描述问题，但这样会带来问题，即我们会忽略那些自己认为是无须提及的上下文或背景知识，而收件人往往不了解这些信息，从而导致他们看到邮件时，不清楚上下文，搞得一头雾水，甚至被误导。因此，在描述问题的时候，如果读者是和自己一样了解上下文的，就可以省略上下文描述，否则，就必须对上下文和背景知识做些介绍。不妨把自己想象成是读者，从读者的角度来思考自己想要获得哪些有用的信息。

2. 描述问题要准确，不要含糊其辞，尽量不要用省略语。其实，当我们自己描述问题时含糊其辞的时候，往往说明我们自己对问题就不够清楚。把问题想清楚了再写。

3. 尽量提供详细的信息，比如测试环境描述，操作步骤描述等（这不光是QA的工作，Dev也要能把它们介绍清楚）。如果提供的信息不够详细，收件人还会回邮件再问的，所以不如第一次就把能提供的（相关）信息都提供出来。

站在更高层次看问题

一个项目中有多个模块，自己只负责一个模块或一个模块中的某些功能，但并不意味着不属于自己负责的模块的事情，自己就完全不能做主。在做自己的模块的时候，就要搞清楚这个模块在整个项目中扮演的角色、会和其他哪些模块打交道、会用到其他哪些模块的哪些功能。项目中的大多数问题其实是和多个模块都有涉及的，这时，首先我们要搞清楚自己模块的职责、怎么和别人模块配合或者怎么让别人模块和自己配合，其次，要多一层考虑，那就是，从整个项目的角度，重新审视这些相关模块，思考先前的设计是为什么要那样设计、有没有缺陷和漏洞，并且尽可能多地对相关的其他模块做些了解。有了这些基础，在遇到“多个模块相关”的问题时，我们考虑问题，眼界就不再局限于自己模块范围了，可以从更高层次来考虑（同样的一个问题，在不同的层次提出的解决方案，效果可能差别是很大的），并且可以站在别人模块的角度来考虑问题，给出别人模块的解决方案，然后比较“从自己模块角度提出的解决方案”、“从别人模块角度提出的解决方案”，以及“从整个项目角度提出的解决方案”，在工作邮件中给出这样多种解决方案并给出优缺点比较，即“不伤和气”，又能大家一起寻求最佳解决方案，同时还能显示一点所谓的“积极主动”以及对整个项目的了解，何乐而不为呢。

注：在本职模块还没搞清楚的情况下，不要奢望什么“更高层次”

工作中要心平气和

身边有些同事在和其他人一道分析解决问题时，表现出来的工作方式，给我们提供了一些反面教材。这些同事有一个共同点，就是当别人发现有些问题是自己的模块的问题的时候，自己的第一反应是不高兴，然后带着不情愿和不愉快甚至气愤的心情被动地去看这些问题，结果当然是自己不愉快，和自己合作的别的人也不愉快。教材的寓意很明显——面对问题的时候，不抱怨，不焦躁，是一个 senior 的 engineer 应该具备的一项基本素质，要心平气和地面对问题。其实，抱怨和焦躁往往是不合作、没信心、没底气、避重就轻的表现。

还有一些反面教材，有的同事性子急，遇到问题就急的不得了，发现可能是别人模块的问题的时候，就找别人讨论。这没问题，但问题是，他会一口气按照自己的思路把问题快速的说一遍，然后就是一句 “环境、log都留给你了，你去查吧”，不容别人插话和提问，说完就走了。之后，别人在查看问题的过程中，需要和这位同事讨论，他却反应迟钝甚至没有回应。Team work 是双向的，别人在给你帮忙的时候，尤其要注意配合别人的工作。要不，谁还愿意再给你帮忙呢？

集中力量做好一件事

工作中难免会多线程地工作。做一件事情的时候，来了电话，得马上应答对方并配合处理问题，但其间又会有别的同事通过IM找上门来，要求配合处理问题，当然，时不时地，还会有人发来邮件，要求配合处理问题。这些问题如果都要处理，那是要人命的！而且事半功倍，因为多线程工作的效率远不及串行处理，大脑在不同问题间来回切换，那也是需要“保存现场、压栈处理”和“恢复现场、出栈处理”的，往往会让人极度疲劳，而且还收获甚微。

解决办法：

• 将所有事情按优先级排序，最紧急的（比如严重阻碍了别人工作的）最先处理，其次处理积压了很久没有解决的问题，再次，不是很要紧的问题……如此类推。
• 容易解决的先搞定，难以处理的往后放（短进程优先！）
• 有时不是所有事情一个人能全部搞定的，就算累死也搞不定的情况下，要趁早做一下load-balance，寻求别的同事的帮助。这样做不是推卸责任，恰恰是对事情认真负责，因为明知扛不住还要死扛到底，最后只会是耽误项目的整体进度，当然自己也是吃力不讨好。
• 项目不是很紧张的时候，抽（挤）时间多看看项目文档和别人的代码，做笔记，这样，在下次处理问题的时候会更顺畅，达到事半功倍的效果。
• 最后，也是最重要的原则，那就是，集中力量做好一件事。每件事的效率高了，当然整体效率就上去了。困难是必须的，克服困难创造串行工作环境，那也是必须的！

注意积累

有没有过这样的感受：成天就是拼命干活，累的要死却感觉技术能力方面几乎没有提高和积累？是不是有点虚度光阴，对不起的自己的感觉？嗯，怎么解决呢？办法来了：挤时间吧！相信自己，时间总是能挤得出来的。用挤出来的零碎时间，看看书，做些基础性的实践，做些笔记。每天能抽出半个小时做这些工作，一个月下来，定能收获不少的。

注意：光看书是不大靠谱的，除非你是搞管理的manager，只需要了解个大概，或者是为了扩展知识面做些泛泛的阅读。要不然，还是需要动手做练习，做笔记的。另外，转载别人博客时，不要copy完事，还是要实践的，说不定人家博客里存在问题呢。

不要居高临下

“我跟你讲~啊，这个问题是这~样的啊，……”，这种话，盛气凌人，像是在教训人，听了很不舒服。好像我从来没这样说过话，以后也要注意。但别人喜欢这样，我没办法，那就让他拽吧……

纸是包不住火的

对问题不要心慈手软，解决一定要到位，要不然说不定什么时候它又会（以其他某种形式、换个马甲）冒出来。解决问题要找到root cause，并根据它彻底解决，记录分析过程、root cause、解决方案，以及验证方法，已被今后参考，因为即使以及解决了，别人提出质疑的时候，也可以很快翻出先前的这些记录，尤其是验证方法，马上验证别人的质疑。如果解决问题不彻底，就是说工作没有做到位的话，今后问题再次冒出来的时候，会手忙脚乱，记不清当初怎么分析的、怎么解决的、怎么验证的，然后要全部或部分重新做一遍，真是事倍功半！一句话，纸是保不住火的！

要敢于承认错误

还是来自别人的反面教材。有些人就是嘴硬，即使明显是他的错（本人也知道），口头上还很强硬，就是不承认。还有的人，在别人指出其错误时，认为是别人对他的冒犯，闹情绪，或者感到“委屈”，对别人态度冷淡粗鲁。引以为戒。都不是小孩子了，还闹情绪，在别人看来，就两个字：傻子！

bug趁早解决

解决bug无论成功与否都要做记录

做一个倾听者