软件开发嘛，总是免不了要去修各种各样的bug。一个好的软件不是单单依靠码农就可以搞出来的，设计，测试等小伙伴们的工作也必不可少。比如之前的工作中只是在乎分配给自己的bug，修好了就不管了，也没怎么考虑过为什么要这样一个流程。今天正好在公司加会儿班，想着把这些总结一下。由于有的项目已经过去很久了，只能靠我的回忆，所以可能有不规范或者错误的地方。或者各位看官有更好的方案还望不吝赐教。
开发流程
目前我经手过的项目基本是这样一个流程。老大们和客户谈好，根据客户实际的需求，帮助他们设计出一套完整应用的构想。这个时候设计团队的小伙伴们会参与进来，把这些构想做出正式的Design，一般是以PPT的形式，展示整个应用的UI设计，配合一定的文字描述来介绍具体的功能。设计小伙伴们做好之后，会和开发团队的领导进行确认，据狗子观察，这里主要是和前端团队进行确认有一些设计是否好实现，是否需要进行更改。这个时候开发团队也会对这个软件的工作量进行估算，大概需要多少人天来完成。然后根据公司的假期安排，确定一个具体的交付日期。大致是把项目的功能具体分解，比如这里要插入一条数据，这个是一个单独的功能点。把这样大大小小的功能点分隔出来，分配给具体的开发。然后每人再跟进自己的Task来估算一下需要多少时间做完。这里想到我刚进公司时总是担心自己做不好，给人家留下不好的印象，所以总是尽可能少的估计时间。还好领导照顾我，每次我估的时间都会被打回来 --你这样做的完嘛？哈哈，想想还挺可乐的。印象里领导好像还说过，你就按正常的工作时间去估，然后总的时间算出来以后再乘个1.5,因为不知道哪里可能会卡主了。现在想想看，还真的是这样。
设计稿在公司审核通过后会交付给客户review，客户一般会提出一些需要修改的地方。对于需要修改的地方会重复上面的流程，对于确定的方面，设计小伙伴们会着手准备具体的设计，线框图，切图之类的一系列东西。与此同时，开发组的小伙伴会根据需求，着手进行基本框架的搭建，一些特殊需要的研究。而测试的小伙伴们会开始准备测试用例。
进入正式的开发阶段，我大概经历过这么三种模式。
- 客户不管不问型。这个是和泰国某公司合作的项目，为他们做一个手机端的应用。可能是大领导太能“吹”，对方十分信任我们公司，只约定了交付的日期和中间查看进度的时间。虽然不规范，但是作为开发来说这样还是很爽的，平时基本不需要加班，只有在交付前可能需要加一阵子班。
- “敏捷开发”。这里打个引号是我也不确定这样算不算真正的敏捷开发，毕竟在各大技术论坛都瞅见过这样的文章《不是用了xxx，就算敏捷开发》，并且根据我的回忆来记录，难免有些不准确的地方。将来有机会和当时带我的老大聊聊，我可能会把这里再更新一下。废话少扯，这个模式是这样的，整个要做的内容定为StoryBoard, 然后具体划分需要的功能feature，指定分配给具体的人。在这个StoryBoard下分出具体的几个Sprint，每个sprint包含哪些功能是确定的。每个Sprint大概是1~2周的时间。每个Sprint需要做的事情大概有这些：
- 完成自己身上的Feature/Task.
- Fix上个Sprint的一些优先级较高的Bug
- 协助测试将这个Sprint的功能进行测试验证
- 代码评审（code review）
- 打包部署 可能会涉及到code freeze
- 拼命加班型。这种由名字您就能看出来，最苦逼的一种类型。具体情况类似这样，客户是合作多年的老客户。由于当地政府一些政策的原因，他们的某项业务需要在某个时间点钱全面转为数字化，否则就不允许进行营业。客户自然就把这任务丢到了我们这里，二狗子作为公司最底层的小兵，没啥办法，加班呗。四周时间排了六周的工作计划，这谁扛得住啊这。哈哈
公司有每日开早会的传统，基本上是汇报一下昨天的工作情况，以及今天打算做哪一部分的工作。而上面三种模式中，我个人认为只有第二种是充分的利用了早会的。因为每个人都有明确的目标，甚至哪个功能什么时候做完都定义的很清楚。参与早会的各位又都是和代码打交道的，说话很有逻辑。昨天做了什么1,2,3的描述，遇到了哪些问题，是否需要技术支持。然后今天打算做哪一部分的内容，是否需要前、后端支持，大概在几点等等。清清楚楚，开会也是一种享受。除了一些特殊的会议，大家一般都是站着开会，事实证明，站着人会少说很多废话，哈哈。
整个项目开发接近尾声时，一般测试小伙伴们会具体的把每个功能点都详细的过几遍。保证不会出现一些十分影响体验，或是一些很显眼的bug。当然这也是项目末期经常加班的原因，毕竟bug这种事嘛，大家都懂。这个时间段内测试和开发的小伙伴们也会准备对应的文档说明，环境部署要求，提供源码等等。想起来对面桌子的大佬提醒我们的：“把骂客户的注释都删掉啊！”，也挺有趣的。
交付给客户以后，一般会有两到三周的时间用来进行UAT，用户验收测试。这个时间段内测试的小伙伴们会辛苦一些，经常和客户进行沟通，看客户认为觉得哪里需要改进，或是客户发现了什么bug，记录下来并分配给对应的开发进行修复。开发的小伙伴们这个时间段内就比较随缘，有时没bug可以摸一天的鱼，有时因为客户发现了比较严重的bug，通宵修复也是有可能的。
客户那边正式上线后，我们的开发团队还会进行support，时间是1~2个月。这段时间过后，对于一些长期合作的项目，代码会转交到Support团队，他们的主要工作是一些维护，以及数据的清理等。
大致就是这样一个流程，当然，这只是我一个开发的视角看到的，如果有哪里有遗漏或者可以改进，也请您提出来。这么一总结好像有点新的体会，以后也可以多多关注同事们的工作，也挺有趣的不是嘛。
再来说说具体的Bug追踪。
目前经历过的trac系统大概这么几种，trac，公司自己维护的gitlab，mantis。mantis其实算是某个项目借鉴了人家的源码框架，并没真正应用到工作中的bug测试回归中，暂且不提了。
Trac
公司的这套trac系统挺老的了，但是功能倒是挺强大的。一个bug的生命周期大概是这样的，测试小伙伴测出一个不符合设计需求的问题。具体的描述这个bug，包括重现步骤，期望结果，实际结果，优先级等等。优先级一般这样划分：
- 极度影响测试或体验的，记为P0，如手机应用崩溃闪退。
- 影响测试完整走完整个应用流程的，记为P1，如页面跳转失败。
- 错误未处理，或分支路线有错误，记为P2。
- 与设计不符，但客户可以接受的，如一些手势行为等标为P3或者不修。
然后一般是将其Assign给对应的开发leader,由他来分配给具体的开发。
在实际项目中目前遇到了这样两种具体的模式，将其中区别记录下来供您参考一下。测试记为QA,开发记为Dev，下同。
- QA报Bug ==> Dev将修好的Bug标为Resolved ==> Dev重新打包/部署环境 ==> Dev将修好的Bug Assign给QA ==> QA验证Bug
- QA报Bug ==> Dev将修好的Bug标为Resolved ==> Dev重新打包/部署环境 ==> QA从自己报的bug中查看哪些已经被标记为Resolved ==> QA验证Bug
不仔细看可能没有什么区别。实际上差别主要是Dev修好bug之后要不要重新assign给QA。这里我认为两种方式都各自有好处与短板。首先来说要根据项目的开发流程的类型来决定使用哪一种方式。
第一种方式下（我们是在拼命加班模式下使用的这种方式），好处是QA可以很清楚的知道哪些bug是Dev已经修好的，哪些是已经修好并且部署到了测试环境，可以进行验证的。因为实际工作中我们知道，bug修好了还要重新部署到qa环境中qa那边才能真正的看到改动，如果只是提交了代码，对QA来说还是没有任何变化的。但这种方式也有一个缺点，作为团队的Leader，因为每个Dev修好bug之后都又把bug Assign给了QA，导致在trac上这个bug的所有者变更，就不能准确的知道每个人修好了哪些bug，还有哪些bug在谁的身上等一些统计方面的信息。
第二种方式下，Dev只是把修好的Bug标记为Resolved。因为开发流程较为规范，所以更新测试环境的时间也比较固定，假定是每天下班前更新内容。如果当天某个bug被修好且被标记为Resolve的，那么它就一定被包含在当天下班前的新环境中。这样测试第二天就可以利用Reporter的筛选找到自己的bug，然后看看哪些是已经标记好的，进行验证。这种方式下开发团队的领导可以很清楚的看到谁身上有哪些bug，修好了多少，严重程度如何。这种方式如果匹配具体的开发模式，其实很棒。只是在某些疯狂加班的时候，一天可能会更新几次环境，导致qa并不知道自己手上的代码是不是已经更新过的，或者是不是已经包含了那些被修改好的bug的改动，给他们的工作造成困扰。
GitLab
Gitlab我隐约记得可以把提交和某个具体的Bug关联起来，以方便Dev进行查看。等周一找个时间我会我再详细补充吧，先溜了，下班啦哈哈。