开发小结-流程管理类-上篇

本文章主要聚焦在项目流程管理，汇总记录一些工作中心得体会。

项目流程

流程体系旨在提高工作效率，明确流程接口和步骤，确定相关岗位和相关事务要求、原则和规则。流程管理，简而言之，就是各司其职，节奏合适。产品的需求和开发的Bug有工具跟踪，软件发布按照节奏来，需求提交给具体开发前，需要和开发主管讨论可行性，有专门的测试反馈和每日进度规划。知道今天要做什么，也知道明天要做什么。

个人在开发过程中，要提前计划好要做的事情，在自己目前能力范围内，做到目前的最好水平，保值保量。

开发流程

提出问题

当我们发现别人代码里面不好的地方时，如何既能提醒别人，又不让他人尴尬。作为代码当事人，面对对方挑错时，正常的第一反应是：你在挑我毛病，我不接受。而受过良好训练的人，会做到“君子闻过则喜,小人闻过则怒”.
我自己的心得时，通过qq或者其他沟通方式，非实时的告知别人做的不好的地方，同时，给出改进的方向。

在与跨部门、跨地区同事进行沟通时，在正式开始沟通前，自己需要做一些准备工作，将问题域有关的背景情况整理出来，发送给其他同事，让大家在后续的讨论中有一个相同的上下文环境，在正式沟通中，按条理提出具体问题，对每一个回复的答案，自己心里要问自己，针对这个问题，我得到满意的答复了吗？如不满意，及时提出反馈。

具体在给别人描述问题时，发现文字的表达力度不够，经过一段时间的时间，发现将问题发生的现状截图下来，在一旁备注上必要的描述信息，图文并茂，关联信息聚合在一起，便于对方迅速了解问题。

讨论大问题时，要先对大问题进行分解，分解为若干互相关联的子问题，在提出讨论之前，自己需要在脑子里面过一片，哪些是这些问题链条的头，先讨论哪个，哪个有结论后可以继续下一个问题，直到所有问题，按照顺序依次得到确认。

对于一些更复杂的流程性问题，建议绘制流程图来提出问题，根据流程图的定位，可以分为概要设计流程图和详细设计流程图，就沟通对象负责的层级，选择不同层次的流程图予以沟通应对。
下面通过一个例子来给出概要和详细流程的区别。
例如，某种物品要进行卖出，卖出前要根据相关信息判断是否有卖出的权限，如果能够卖出，接下来要做什么提示和操作。

从概要流程出发，该问题就一个分支，“物品是否允许卖出”，从详细流程触发，物品在条件1或条件2，成立时是不允许卖出时，不同情况的错误提示语是不同的，而其他情况是允许卖出的。

小结一下：概要设计、详细设计是针对开发实践来说两个不同层面的流程抽象，我们在一个层面上考虑时，不要过多考虑另外一个层面的细节，否则，整个流程就会抓不住重点，既有概要过程、又有详细处理，显得冗余繁杂。

讨论问题

在同别人讨论问题时，发现自己容易激动，很容易讨论着，就把问题给带偏了，本来刚开始在讨论A问题，讨论讨论着，就跑向B问题，再讨论一段时间，就忘记刚开始要讨论的问题了。这个过程中有需要改进的地方：

• 在讨论的时候，要尊重别人的意见和看法，等别人把话说完，如果可以的话，先复述一片问题，提出对别人的看法后，再就讨论的问题给出自己的看法。如果中途自己尝试打断别人，一定要忍住这个冲动。

正确理解别人的前提是能够完整接收别人的信息，对于同一个问题或者说是概念，不同人有不同人的判定是很正常的事情，同别人讨论会多一些思考的角度，更加完善的看待事物。同时，要对自己有明确的认知，认知到自己在哪些地方存在不足，下一步往哪里去提高。

记录问题

在工作过程中，有一些问题在qq群里面讨论的，一位同事抛出一个问题，大家东一句、西一句的讨论，很多时候，讨论到最后，没有一个最终排版确认的人，造成讨论的很多，实际能落地执行的很少。当遇到这种情况时，开发人员需要就问题域以及各方提出的意见方案，梳理汇总成邮件方式，召集有关各方一起讨论确定，达成一致后，由产品人员在JIRA单记录关于此问题的已确认的解决方案，然后再转交给开发进行开发修改。这里应该是有开发来主导的，秉承着谁开发、谁负责的原则，来主动推动。不管前期是如何讨论的，一旦方案确定下来，大家就要坚定不移的去执行。

如果是开发人员自己觉的有一些重构优化方面的需求，在动手之前，需要在JIRA上建一个优化需求单，限定好边界，规定好内容，先交由上级审核，审核通过后再进行开发，这是事前告知流程。如果嫌每次重构都建单麻烦，可以以先将自己每次待重构的修改整理为补丁形式，和其他同事一起，选取一个集中时间，大家一起过一片这些重构类的补丁，一致审阅通过后，再建JIRA单和提交到代码库中。

召开会议后，一般需要会议记录人员做一个会议纪要，会后要求会议记录人员将会议纪要已确定达成共识的事项通过邮件群发给参会人员，明确后一步的工作方向。

接到新需求

接收到新需求时的工作流程

在接收到产品人员的需求或者级要求时，在时间允许的情况下，要主动询问该项任务需要要做什么，期望达到什么样的目标？对于一些尚不明确的地方，预备是如何处理的？要商量好整体业务流程和功能界限，讨论清楚并且有合适的文档指导情况下，在进行后续的概要设计和具体编码。

详细阅读需求文档和原型设计图，这些文档往往混杂着业务背景、需求说明，与需求无关的一些信息，需要在开发前，将文档中与开发、测试相关的功能要求抽取出来，汇总在独立的文件中，以此文件作为后续开发的参考文档，当发现有不确定的地方时，先分类汇总起来，得到全部了解后，将这些不确定的地方一一同产品人员确认.

作为开发人员来说，不能生搬硬套产品提供的需求，要从自己的专业角度出发，对一些不合理的地方或者冗余的流程处理给出自己的意见，对于一些有悖于通用性的流程和交互的地方，需要产品给出信服的理由来说服开发人员实施，产品是着眼于这个需求，而开发考虑的是整体交互的一致性，能统一处理的，最好统一处理。

简化合并某些业务流程，甚至在产品需求的基础上，提出更好的业务流程，也是一个专业开发人员应该要做到的。

当产品提出了看似很简单，但确需要修改框架才能实现的功能时，开发要第一时间站出来提出质疑，尽量引导产品提出在现有框架内能够实现的功能。在一个已经成熟的软件产品上，进行框架级别的改动来满足某个蹩脚的需求，是具有极大风险的。有时候，宁可不做，也不要做错。

• 待实现功能的前后逻辑关系和一些限制性的要求等。
• 非功能性需求，比如UI、交互的一致性，错误处理等要一一确认。这些需求文档一般不会给出来，需要在开发过程中去产品人员讨论后决定。
• 当前遇到的问题，以及对应的各种解决方法和对应的输出结果。
• 异常情况的处理
• 自测流程

在一个已有实现的基础上进行新界面的绘制，修改的原则是：保留原有实现不变，不要在原有实现上面去修改，而是用一个新的实现来代替原有的实现。

在一些必须要公用修改的地方，比如颜色的取值之类的，如果新的修改会影响到旧的实现，那就要讨论下，是用新的颜色段还是修改公用的颜色段。

进度报告

对于开发量比较大的开发任务，需要较长时间才能全部，在向上汇报时，需要注意技巧，不要说还剩多少工作没做，改为已经完成了多少工作。至于量化的进度，比如完成了50%、80%之类的，自己说出来都觉的不可信。自己接收前，要进行任务分解，有大至小，逐步细化，一直细化到可落地实践的程度，以1，2，3，4，5这样罗列出来，每天完成了什么，就打上一个勾，让上级知道工作进度，

换位思考，作为领导，向下属发出一个任务时，领导希望得到什么？个人认为是希望得到及时的反馈，无论是阶段性的成果或者是遇到难题卡壳，及时，主动，条理清晰地向上级反馈工作，在实际工作中是非常重要的。

写工作总结的时候，整体最好以总分总的形式排列，具体到各个分任务时，在内部也要遵循先总后分的原则，第一句话概括提炼该段文字的中心思考。重点工作要重点描述，对于重点工作的判定，起初我是这么认为的，自己在哪项任务上面花费了最多的时间，就认为哪项任务是重要任务。经过同事的指点后，发现自己的这种认识是存在偏差的。重点的工作，不能仅仅从完成这项工作的时间长短上来判断，而需要站在更高一层上上，从团队职责、功能模块层面去考虑。这种需要从具体功能点的编码，上升到功能实现对外体现的价值上来。

在此以一个例子来说明：

比如，针对查询页面，完成的各页面的拆分，列表支持稳定排序，表头统一对齐，这些是很具体，很细节的工作，如果硬要从这几项具体的工作中找出重要的工作进行描述，那往往会顾此失彼，抓不住重点。

解决方法是：站在更高一层上面去看待目前的工作，层级提高，就会缺少对细节的描述，但会从一个更加高的视角去看待工作所在的意义。比如说，这些改动，从用户的角度上来看，统一UI风格，优化用户交互视觉体验，具体包括查询表的稳定排序、风格统一、刷新逻辑统一等。高层次的描述，需要具体层面的配合，才能更加有说服力，可以配合一两个具体的页面来描述。另一个视角是从开发上来看待，按业务拆分后，有效降低代码耦合度，减少后期维护成本。

改Bug

总体原则

不要混合修改Bug和优化流程，这一次，又在这里掉坑里面去了，JIRA单分为Bug单、新功能单和优化改进单。

每次提交代码的范围要最小化，一次提交解决一类问题，不要在提交中混杂其他问题。

严格守好提交纪律，对于已经测试过的代码，在没有新需求或者新功能之前，一定不要去修改。

只有JIRA单流转到我名下，我才有需要去做，否则的话，别人口头上一句话、或者QQ群里面的一切讨论，不管有没有最终定论，如果没有反馈到JIRA单上面，就都不算数。白纸黑字写下来的才行，口头告知、或者群聊天等，无法明确留痕的讨论，都不算数。不要别人一句话，自己哼次哼次的思索分析了大半天，结果别人又来一句，不用管了，那自己之前的心血就白费了。

当和别人共同修改一个问题时，JIRA单在别人名下，自己做的修改以及提交，要及时的更新到JIRA单上，以明确自己在此Bug解决过程中所做的工作。

在改一个Bug时，不要仅仅局限于当前这个模块产生的Bug，想一想类似的Bug，在工程中其他地方会不会存在，如果存在的话，要一并修改，并且在JIRA单上注明修改影响范围和测试建议。

具体到战术层面上的，可以分为如下几个方面去逐步思考，探究。

1. 分析之前写的不好的地方，找出可能的隐患，总结出这个不好的地方所有可能的测试案例，有可能一些测试案例是测试那边覆盖不到的，或者说触发此测试案例的组合条件非常隐蔽，难以触发。

2. 分析如何修改，从这几年的编码经验上来，对于最终的Bug表现来说，若从表现上逐渐深入查找，往往会找到一系列触发条件，最终有一个根条件，我称之为Bug触发链,找到了该触发链条，也就有了对应层级的修改方法，举一个简单的例子，比如说，因素A-->因素B-->因素C-->Bug现象，那么解决方案可以C层级上处理，也可以在B上处理，也可以在A上处理，具体在哪一个节点处理，要看引入的处理会不会影响其他正常业务逻辑，最好的状态是，只修改了Bug，而对其他业务没有影响，这可以称为改Bug的隔离性。若修改会对其他业务流程有些许影响，那看该影响是好的影响还是不好的影响。如果决定在这个层面上修改的话，不管是好的影响还是不好的影响，都要分析清楚利弊，同产品和测试人员沟通好后，再行动手修改，同时在提交Bug的备注信息上面进行详细的说明。

3. 在具体动作编码之前，要评估开发的时间。评估开发时间，是一个技术活，这不是说完成有多难，而是评估的准确度。
   就一个显示用户资产总览的需求来说：经过前期任务分解，有如下子任务要完成：

4. 完成6条基础数据指令的收发

5. 完成界面搭建

6. 在界面上测试基础指令，封装基础数据

7. 同前端网页联合调试

8. 处理异常情况，比如页面重入、请求失败、切换账号请求、请求回来前关闭窗口等等

9. 优化代码效率，比如增加缓存已减少请求次数，优化业务逻辑，合并错误处理等。

具体操作

接到Bug的，首要任务是重现它。在改 Bug 的过程中，要定位是哪一行是造成该 Bug 的关键行或者关键块？努力做到在不改变原有业务逻辑的基础上改对Bug。

在进行分支Bug的修改时，经过生产实践，讨论的流程如下，大家一致在主线分支上开发，当开发到合适时候，拉出发布分支，
比如V0.1，在此分支上面修改Bug，待到V0.1分支调整到一个较为稳定的、可发布的状态，就可以对外发布了。当V0.1分支正式发布后，将在V0.1分支上做的修改，逐个merge到主线分支上，这种方法较繁琐，但可以保证提交到主线上面的修改可以对应到每一个Bug单。

在分支上，只做修改Bug，至于优化改进类的操作，建议在主干分支上去做。

实现同样一项功能，有的开发20行能解决问题，有的只需要10行，结果都是实现了功能，只不过一个效率不是那么的好而已，项目组如有条件，可在开发和测试之间，如果条件允许的话，增加一个开发审核的流程，由高级开发人员审阅检查本次Bug提交情况，并且提供思路和实现上的优化意见，有助于加强开发质量，降低Bug的打回率。

提交Bug规范

提交Bug的备注格式要统一科学的格式说明，目前工程中用到的格式如下：

Bug备注信息：

Bug单号：问题单号以及对应的标题描述，例如：JIRA-1000, 用户在wifi情况下登陆会失败
修改版本：V1.0
问题原因：描述问题产生的原因，尽量以精简的语言描述
修改方法：用简练的语言描述出来,文字要有前后的逻辑关系，比如，点击刷新按钮时，重置提示语、清空列表数据和缓存数据，滚动条复位。
影响范围：以功能模块或者页面展示为单位来描述，能够具体到特定业务模块的，最好具体到特定业务模块。比如一个功能模块XXX，下面有子模块A、子模块B和子模块C，此次                 
         修改影响到了子模块C，那么在这里最好写影响了功能模块XXX中的子模块C，而不能只写影响了功能模块XXX，给测试人员带来了额外的测试负担。
测试建议：如果Bug表现很简单，那么此处可以写略，如果Bug表现的背后业务逻辑很多，那么有必要业务逻辑通过1，2，3，4的流程列举完整，列出此次改动的影响到的执行
        路径（即使是调整了下原有路径的命令规范等也在影响范围内），一方面，要写修改点的影响，另一方面要写，该修改点所涉及到的界面的相关功能(包含修改点涉及到的功能以及未涉及到的功能)

Bug备注要简洁精炼，想明白才能写清楚。

写Bug的问题原因时，要尽可能减少阅读者的知识依赖，让看到这个Bug的人员看一眼就能了解该Bug的前因后果，不要想当然的认为测试人员已经知道自己明显知道的上下文背景知
识。没有上下文的Bug描述规范，不是一个好的描述。想清楚问题的起源，阐述清楚问题的表现以及解决方法，是一个很重要的能力。

在一次提交中的所有涉及到的文件修改的内容和现有的说明，都要在JIRA备注里面写清楚，让测试人员和产品人员知道。
改一个Bug，如果是单单针对这个页面的Bug，改正很容易，但如果想要改正通用的，让所有人都满意，那很难。
凡是改Bug，就要限定修改的范围，同一类型的问题，在其他界面往往都存在，限定修改和测试的范围，让各方人士统一目标。

在写Bug描述时，千万不要使用程序中的代码，而要使用和代码相关联的界面显示元素，因为测试在看这些描述时，是不知道你写的代码是什么意思，他们只能看到界面，使用于代码相关联的界面元素，方便测试理解改动给界面带来的影响。

有时候的Bug修改，可能既改对了当前JIRA单上面描述的问题，又改对了之前测试没有发现的问题，对于这样的修改，在备注里面要注明清楚，修改后，一并改正了一个尚未被测试发现的问题。
如果你的修改涉及到其他分支上的修改，不管涉不涉及到具体执行逻辑的修改，只要对其他分支路径造成影响的，都应该写相关的分支的测试案例来进行覆盖测试，已确保本次修改未影响其他分支逻辑。

提测格式：

提测版本：X.XX.XXX
版本路径：\XX\XX\XXX
提测内容：
测试建议：
请安排测试！

一般来说，一个Bug可能会经过两三次反复修改后，才能算是完完整整的解决了，此处以提交2次代码解决了一个Bug为例子，在第二次提交时，提交的备注要紧跟第一次提交到备注后面，关联上SVN提交编号和对应的Bug单号，有助于从代码回溯找到对应的Bug单。

Bug思考

对待一个Bug的看法，可以从Bug本身出发，哪里有问题就改哪里？这是第一种情况。

第二种情况是，不仅仅着眼于Bug本身，围绕着这个Bug的相关流程，是不是有问题？

这里指的有问题，指的是含杂了无关的、说不清道不明的业务逻辑代码。或者是本来需要自身来处理，却交给外部来处理的地方。在这种情况下，与其在已有基础上修修补补，还不如整体重做，保持之前一样的接口，内部实现逻辑完全重写，向着最优、最简的路线走上去。

每一种正确的改Bug方式都是各有利弊，没有最好，只有最适合。

修改代码保持谨慎，对别人的代码保持敬畏。

改Bug有一个驱动原则：无Bug单，不要提交代码，可以先在本地做一些简单的修改测试，但直到有任务单，才去提交代码，凡事可能影响其他路径的，那么一定会影响，要依赖完善的测试来覆盖改动影响。。

修改的层级性，比如，来了一个Bug，经过初步分析后，发现只需要改动一处代码即可解决此Bug，此时为“Bug修改”，但改正这里，可能和前面的已有代码有重复，因此，可继续进行相关的逻辑合并修改，形成第二份修改，形成“优化修改”。

在提交时，就有多种方式了，具体哪一种方式更好，各有各的场景吧。

方式一：只提交“Bug修改”

方式二：将“Bug修改”和“优化修改”，作为整体，一次提交到代码库，此处的优化修改，很容易，也可以说是一定会有 超出范围的修改，比如说，那个变量名看着不合适了，哪些重复的逻辑需要合并了之类的

方式三：区分提交“Bug修改”和“优化修改”，分两次提交到代码库。

从开发目的来看，所有的开发工作，都可以汇总为三点：改Bug，新功能和重构。

• 改Bug期间，测试提JIRA单或者自己发现Bug来驱动，目标是改Bug，所以你的修改着力点就是改Bug，即使看到了一些特别容易重构的地方，只要和当前Bug不是紧密相关的，不要贸然去重构，让改Bug的改的纯粹些。

• 增加新功能期间，又可细分为两种，一种在已有实现上增加新功能，另一种是另起炉灶，开发新功能。第二种方式毋庸置疑，第一种方式，也不要想当然的扩大修改范围，将当前的精力聚焦在增加新功能上，小的重构手法可以使用，不要贸然实施大的重构手法。

• 重构开发，如果是单纯的重构开发任务，那么要聚焦优化范围，一次只提交一种类型的重构改动，保证每次提交的功能一致性和可测试性。