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

改Bug和优化要不要同时进行

我的觉的，改Bug和优化，当优势的点和改Bug的点紧密相关联时时，改Bug和优化能够一同进行。而对于那些不怎么紧密的代码，优化无关紧要时，那坚定不要优化。比方说，最开始进行释放内存，使用delete p; p = NULL;后来发现项目中已经有封装好宏，只须要一句话就可搞定。不过在使用该宏时，须要引入头文件。那么，这种状况下，就能够不进行优化，原来怎么写，如今就这么写。保持在同一个模块(.cpp)中，相关操做的一致性便可。

从冗余的实现到既能够知足业务功能，又保证每行代码最优，在下手前，须要反思思考斟酌，这是新手迈向高手的必经之路。

找Bug经验

解决Bug，不少时候，不存在既可以减小改动范围和影响范围，又能很好解决问题的方案，为了平和开发成本和测试成本，不少时候，为了控制改动影响，会倾向于选择“消除现象”，而不是找出根源来解决问题。

屏幕录像找Bug

测试一些不容易重现的Bug时，能够借用FastStone的屏幕录像功能，来找到Bug触发的最短路径，具体操做方法以下：

经过屏幕录像，把在相关操做都记录下来，直到出现崩溃提示为止。反复观看，梳理一些没必要要的动做，直到找出触发Bug的必要路径，不断精简路径，直到找到最短路径为止。

使用此种方法时，须要有如下前提：

• 测试反馈此Bug是进行了若干操做后，会有很大概率会出现，但不知是什么操做触发的，只有最后出现崩溃的画面。
• 须要使用测试人员发生崩溃的版原本测试

二分法找Bug

在开发过程当中发现，A模块出现问题，而在几天前，这个模块是没有问题的。经过代码回滚，能够明确若干天前的A模块没有问题，而今天的A模块有问题，经过二分回滚查找，能够逐渐把范围缩小，最终定位到是哪一次提交形成A模块出问题，常见都是某一次不相关的提交，间接又间接的形成A模块出问题。

接口变动形成的Bug

有些Bug是由于调用其余方提供的接口，若是由于接口提供方的重构，致使接口参数改变，而调用方没有作针对性的改变，就会出现Bug。

此类Bug的修复，建议本身先排查出来，而后交由接口提供方去修改，由于这是它修改接口致使的问题，在调用方这里，只知道调用方这里的实现，而不会注意到其余开发人员调用该接口是否也会有问题出现。

有些由于接口致使的错误，由接口方来修改或者界面方来修改均可以的状况下，接口方修改，不只仅能够针对当前这个界面，对之后其余新增界面也能够适用。若是有界面方来修改，那仅仅只能针对当前界面，若是有新增界面的话，则颇有可能会遗漏. 针对这种状况，建议接口方作修改比较好。

提优化的Bug

开发事先的和需求要求的同样，不算Bug。若是测试认为需求文档上面实现的不美观提Bug修改，那这种Bug不算是个人Bug，算是需求的Bug。这种Bug的产生是需求里面没有定义的细节，而测试认为默认实现和它内心的不同而产生的。

所以，我自身的建议是：优化类的建议和Bug须要区分开.

一是，二者判断的依据不一致，

二是，二者发起人可能不一致，优化类多是开发人员本身发起的，也能够是测试人员主动发起的。可能某些优化，在界面的功能上是体现不出来的，须要和后台一块儿来作判断。可能有些优化，是各个界面上由于操做的不一致性而提出来的，这种问题的出现，是由于以前就没有统一的标准，新界面走新标准，旧界面保持不变，那么，在遇到这样的状况时，须要限定修改和测试的范围，以防止无止境的相似的优化建议提出。

进度评估

一个项目的完整流程，基本包括需求设计，视觉和交互设计，开发编码，测试，上线，运维，发布新版本等几个环节。
从用户的角度来看，若是上线后功能没法正常运行或者运行常常崩溃，那就是没正确的完成。
从开发的角度来看，本身负责的模块完成而且自测经过，后续交付给测试测试，是否是能够认为本身这部分功能已经完成了呢? 这要看完成的评估标准了，若是是以软件发布为标准，那我的模块的提交还算不上完成，得集成测试经过后正式发布，才算完成。那我的自测经过交付测试后，这个进度怎么去描述呢？量化的描述方法是不合适的，只能这样说，进度到，已完成功能的开发，而且交付测试测试阶段。

从整理角度来看待，项目进度能够从两个层面去看待，总体进度（需求设计，视觉和交互设计，开发编码，测试，上线），具体到每个子流程中，每一个人负责各自的进度（未开始、已完成A，B功能，已完成A，B，C功能，还剩D功能，已完成，这几个阶段），做为开发人员，考虑的着重点落在已分配的任务，已提交测试的任务两个点上。

不管是开发新功能，仍是重构已有功能，工期估计是很重要的。虽然都说，计划赶不上变化，若是仍由变化任意发展，本身就是在进行毫无章法的工做，从时间安排上来看，就是用战术上的勤奋掩盖战略上的懒惰。下面分别谈谈新功能开发和重构的工期估算：

• 新功能开发，若是该功能是以前相似的模块，能够从项目管理工具和SVN提交记录上查看，从本身接收到此任务到完成全部功能后提测，而且最终经过测试的时间段，以该时间段做为参考因素。另外，从该功能涉及到的业务流程、依赖的第三方数据等进行综合考量，按照天天6个小时的有效工做时间来算，将获得的最终小时数再乘以1.5的系数后折算回天数，乘以系数是由于项目过程当中总会有那么些意外状况发生,可能用到了本身不熟悉的库或者接口之类的。

注意：若是开发功能涉及到与其余同事合做对接，若不清楚相关业务，最好将此功能交给熟悉的同事来确认完成对接所需的时间，不能贸然表明同事回答对接时间，不能由于看起来很简单就直接确认期限。对于同事来讲，也同样，你们都是为同一个目的而工做，不要由于本身的缘故耽误别人以及整个项目的进度安排。

• 重构开发，根据须要重构的功能点，每个功能点评估下所需时间，将各个功能点的时间汇总起来，构成总共须要的时间。

影响评估

对修改要心生敬畏。评估改动影响时，能够按照以下框架来思考:

1. 应用场景分析：
   1.1 是否高频（例如天天5次）
   1.2 是否高危（影响范围较大）

完整的场景是如何的，本次变动属于哪一个环节，须要知足什么样的条件？上线后如何确认功能是否正常

1. 影响范围分析：
   2.1 影响哪些系统
   2.2 影响哪些功能
   2.3 影响哪些部门

越是临近发布时点的修改，越是严格控制修改影响范围，想清楚了再去作。

假如不能评估修改的影响，宁肯不改，也不要乱改。与此同理，假如基于目前的开发进度，不能去评估完成一个新功能的工期，或者说很难去评估的准确，那么在本身的心理预期上乘以2倍或者3倍。当碰到解决不了的问题时，在本身在尝试了多种解决方法后，及时反馈上级，请求更多资源协助。

开发回顾

每作完一个功能模块，要进行复盘，梳理回顾在实施过程当中，有哪些作的好的地方，哪些作的很差的地方。
对于刚开始着手作这个模块时的一些工时预估，难度的预估，沟通的预估，和真正完成这个模块后的实际估计，看看本身哪些预估是正确的，哪些预估是误差较大的，若是误差较大，回顾本身在开发时的工做状态，看是哪个节点上卡壳，致使工期延长，仔细分析缘由，有多是其余人员的接口配合，后台的数据配合，也多是本身预估的太乐观等等，开发是在不断迭代进化的，及时的复盘，对完善自身，提升自个人项目管理能力大有裨益，切记，切记。

1. 对工做岗位负责
2. 当在工做时，就要在规定的时间内，全神贯注的工做,哪怕事情再多，也要一件一件地进行，作完一件事情再作另一件事情。当在休息时，就必须彻底休息.
3. 及时作好自我检讨,记录在开发过程当中的心得体会，以便在下一次任务来临时，可以精益求精，不断进步。
4. 留给本身必定的思考时间，在真正着手开始干活以前，在脑海里面梳理一片 要解决的问题是什么，该如何作，怎么作才能更好，想清楚，画出来再动手。
5. 失败后不要找借口,失败就是失败，没什么好推脱的，哪怕原定计划由于不可抗因素破坏而失败，不要说由于这个那个，找缘由比抱怨更好。从失败中去找缘由，记录这个缘由，在下次作相似决定以前，回顾下本身失败的缘由。由于一旦你为本身的失败找了借口，那么下次失败还会再找借口，到最后，整个项目都会失败的。

心态管理

公司不是学校，公司支付你的薪水，不是让你深造技术，而是但愿你替老板解决问题。在业余时间，你能够探究喜欢的技术，但一旦到了工做场合，你就应该思考如何高效、准确、敏捷完成产品提出的需求，不管这个需求有没有技术含量，若该需求的实现会破坏现有的架构，那么从实施成本和收益上作出本身专业性的判断。

除了专业技术的进步，业务规则和业务流程也须要关注，多思考新技术与既有业务的结合点，经过代码评审、技术分享等提升其余成员的技术能力。若是能作到这一点，相信你会迅速成长为团队骨干。

分支管理

现有的开发实践中，采起开发分支和发布分支双线并行的模式。平时，你们都是在一个开发分支上工做，当项目须要对外发布版本时，从开发分支中拉取一个分支当作发布分支（例如V1.0），后续发布版本的需求和Bug修改均在V1.0分支上完成，测试同事也在发布分支上工做。
越是临近发布节点时，对发布分支上的改动越是要谨慎，改动范围能小则小，不是万不得已的修改，尽可能不要提交。若有一些牵一发而动全身的修改，会形成回归测试压力过大，延误发布时机。待到发布分支逐渐稳定后，达到能够发布的状态，等发布上线后，再由各个开发人员将各自在开发分支上的提交逐次合并到主线分支上，你们继续开发下一个版本。

对于已经发布出去的版本，对应的代码库应该设置为禁止提交，要完整保留发布时的代码库以及相关的调试信息，这有助于分析已发布版本的问题。

针对开发和发布分支双线模式，个人习惯是，在本地建开发分支，重构分支和发布分子。新功能开发在开发分支上作，改Bug在发布分支上作，及时合并会开发分支。在重构分支上，作一些重构性的工做。三个分支各司其职。

每次提交做为一个最小完备的功能集合，目的惟一性。若是有些功能的实现涉及到多处改动，那么须要有计划、有意识地去划分一个大功能的各个子功能，每次提交一个明确的子功能，由此逐步构建一个大功能。

在平时的工做任务安排中，需分清轻重缓急，必定要把本身手上现有的Bug都处理完后，才去作本身任何合适的优化和重构工做，千万不要自觉得是的作一些感动本身的事情。完成公司的任务是第一要紧的事情，是首要要解决的事情。

时间管理

在新接收到一个需求时，分配到 需求分析、设计、实现和自测上面的时间安排，推荐为4:3:2:1

为何这么分配时间呢？通过屡次工做实践得来的。当需求不明确，那么关于这个不明确的地方，怎么开发都是不合适的，为了解决因需求不明确致使的后续设计和实现阶段的返工，在需求分析阶段，须要根据需求画出本身理解的 用例图、状态图和主要流程图等。这些图是需求自己所涉及到的，在一个系统中，这个需求实现的功能和其余功能是有关联关系的，好比说弹出非模态框，若是程序中已有一些弹出非模态框的部分，新增的功能也要弹出非模态框，那么这两个功能就有先后的关联了，是同一时间只出现
一个，仍是先后依次出现，后出现的覆盖前面出现的，仍是新增功能的框始终在顶部，其余框在后面，等等涉及到与已有实现的关联关系，这些都须要进行额外的确认。
产品人员给出的需求，很大程度上，不可能考虑全部与之相关的其余对象的交互，而在总体行为上，该框的出现，影响了什么，只有到开发阶段才能发现。

引入第三方库

对于引入的第三方代码，必定要所有吃透，或者说是对可能的异常进行捕获处理（缓冲区溢出没法捕获）。

要不要引入一些 难以维护的第三方代码？或者说，在引入第三方代码时，须要注意些什么？

1. 看应用场景。
   若是是关键路径上的关键应用，对于引入的第三方，务必要彻底吃透。这里吃透的意思指的是，不光是看它可以实现什么，更重要的是看它没能实现什么,后者每每在业务中是很重要的。它不能作什么比它可以作什么更重要。

若是是非关键路径上的应用，对于第三方要进行本身的封装，而且尽可能少用第三方的高级功能，而是本身经过简单功能来组合实现。

1. 考虑引用第三方库的一些负面效应
   好比，第三方库使用的 运行库配置 须要和调用方保持一致，这可能会影响主工程的相关配置。
   商业提供的第三方库支持，若有必要引入，则能够引入。
   对于开源的第三方库，有几点须要考虑的地方：
2. 是否一直有技术支持
3. 文档是否齐全
4. 使用之后，组内是否有人可以hold主，若是hold不住，果断放弃，找一个能hold主的
5. 该第三方库是否有其余公司在使用，是否有经验能够借鉴
6. 社区是否活跃

在调用第三方服务时，要时刻保持怀疑态度，不能由于第三方的缘由，而拖垮本身的服务，作好超时机制以及重试机制的处理。重试机制要合理设置，如果由于是业务致使出错的，在UI上面要作好控制，防止用户重复操做。如果由于网络缘由致使的，则须要选择合适的超时策略和提示机制。

任务管理

一个大的任务每每能够细化为几个子任务，设定规划好子任务的目标和时间安排，分派子任务给其余人员去作。

本身在工做时，讨厌别人在旁边指指点点。这一点，做为干活的人和指导的人，都是同样的。干活的时候，不喜欢别人对本身的工做方法和工做流程的指点，而人人都有一种好为人师的心态，在看到别人低效的工做方式，每每会忍不住去说两句，起到兴头上面，还会主动出手去干预，纠正。

对于指导者来讲，这好像是一种经验上的优点带来的心理愉悦感，而对于被指导者来讲，这像是在被打脸，心里深处有一种压迫感和强制打断感，每每会引发厌恶
即便这个时候给出的建议的确是有效的，可是也每每带来不了切实的效果，别人仍是用他一套旧的方法。

提意见的方式很重要，基于上述的考虑，结合本身看的书籍，得出了几点心得：

1. 在本身工做或者帮别人干活时，先听清楚别人的需求，而后说，我在干活途中，请不要打扰我！每个小的阶段，我干好了，会主动给你看阶段性的成果。
2. 在别人正在干活时，即便别人的工做方式不切当，千万不要当场指出，而是在内心或者找个东西记录一下低效工做的步骤，
   重点分析在哪几步耽搁了时间，就像profile一个程序同样，找出花费时间最长的函数，而后专门优化此函数。针对最影响效率
   的操做，提出有可操做性的改进方法。若是能够的话，能够主动演示操做，让别人体会到使用新方法而带来的好处。

做为管理者，面对手下员工的工做，自认为想到的第一件事不是优秀，而是可控。可控的意思是，他们在作本身安排给他们的事情，
一旦他们作完了，可以获得及时的反馈和通知，当他们遇到问题时，他们可以主动的去向我寻求帮助，而我也能够适时的给出专业性
的方向. 做为下属，若是作完了上司交代的工做，须要主动告知，还须要作什么？若是有新的任务安排，就取作新的任务，若是没有，
那就作本身的。

表达管理

要讲清楚一件事情，首先本身要深刻、细致地了解这件事情，其次在本身的大脑里面要梳理总结关于这件事的重点信息，条理清晰的列出来，划分主次，分清重点，考虑到讲解对象的理解程度。

在一件事情还没有能明确拿下以前，不要贸然对外宣布，一旦答应客户的事情，就必定要尽全力去作到，按期跟踪客户反馈的事情，及时做出回复。面对他人的请求，拒绝是常态，坦然面对拒绝，理解拒绝，正确处理拒绝，抓住需求点，持续提供服务。

思惟模式和心态比才华更为重要，注重自我内驱力的培养，自我激励，勇于承担责任。

刻意培养对外的表达能力,一个公司是各类角色的集合，像老板、设计、HR、外包乃至前台测试，仍然要经过天然语言而不是机器语言的实现，可以适时把肚子里的聪明才智绣出来，可以恰当的把功劳业绩拿出，天然而然会成为受欢迎的人。随着平台的扩大，表达也不限于一对一的沟通，向上汇报、规划脑图、总结邮件、技术指南、PPT演示等等，是专业职场人士必需要精通的技艺。

将复杂问题深刻浅出，说的清楚生动，是一门很重要的能力。

开发的品味

实现一种功能可能有多种实现形式，有简单的，也有繁杂的。在开发过程当中，多是基于现有代码进行二次开发，也多是另起炉灶开发，无论如何，在保证正确性的前提下，争取写出简单直接，逻辑清晰明了的代码。在阅读代码时，看到已有代码是如何实现业务目标时，要有本身的品味，在实现相似功能时，不能一味照搬借鉴，而是选择性的吸取改进。

可在团队中，按期选择一个工做认真的人，每周选取一个时间段，专门作代码规范和最佳实践检查，坚持一段时间后，整个团队的代码规范执行力度将会获得明显提高。

团队的每日构建，规定，不管是谁提交的代码致使没法编译经过，第一次口头警告，第二次请整个项目组喝咖啡，目的是否是为了请喝咖啡，而是真正作到令行禁止，让全部人在提交代码时，对本身提交的代码有顾忌，慎重，从整个团队上来看，能够较好的实时规章制度。

我今天写的代码，若是遇到功能改动，会不会修改起来很困难？若是可维护性差，那么该如何改进？而后再进一步考虑下，当前面临的问题场景是否可以与设计模式中的一种或多种匹配上？若是能的话，该怎么用设计模式的思路来改进？

不能仅仅只是作好当前任期的事情，每一个人在公司内都有一个定位，作好本身职责范围内的事情是理所固然的，但这仅仅只能保证你不失业，想往前走，还远远不够。因此咱们日常作事，要从这你的下一个职业去作，机会永远只留给有准备的人。

带着问题去学习：学习东西不能为了学而学，必需要有本身的目的，否则你都不知道你学习的边界在哪里了。从边界这个角度出发，改Bug的边界和重构的边界，他们须要清晰的肯定吗？个人回答是，须要，特别须要。

每过一段时间，回过头来看以前写的代码，必定会有想要修改的冲动，此时，绝对不能修改已通过测试的代码，在既是优化改进不会影响到关键业务，也不要修改。取而代之的是，在收到新需求时，吸取旧代码的经验教训，每次写的比上次更好一些。

在同一个项目中，保持简单一致性，若是使用printf+read/write，那为了规整，在该项目的其余地方保持一致。若是使用了c++的ios流，那么也保持一致。

版本号管理小结

Windows风格的版本号通常形如A.B[.C[.D]]，其中，A为主版本号，B为子版本号，C为修正版本号，D为编译版本号。

• 当项目进行了局部修改或者Bug修正时，修正版本号可加1；
• 当项目在原有基础上增长了部分功能时，子版本号可加1，修正版本号归0；
• 当项目进行了重大修改或者局部修正积累较多，致使项目总体发生全局变化，主版本号加1.
• 编译版本号通常是跟随编译过程自动生成的，常见的有取当前svn的提交编号或则git的提交编号，便于跟踪定位发布版本。

若是是较小的工具程序，能够只保留一份最新程序便可。
若是是跟随主程序一同对外发布的小程序（好比升级程序、卸载程序、注册程序等），则需保存历史发布版本，以备查问题，本身的工程实践目录结构以下，可供参考：

---tools
------history
------------1.0.0.123(123为SVN提交编号)
-------------------a.exe
-------------------b.dll
-------------------c.pdb
------------1.0.0.124
------release
------------a.exe
------------b.dll
------ReadMe.txt

对于对外提供的小工具，须要给出相关的使用说明，具体提供方式，能够是截图+说明文字的方式，也能够是简要的帮助文档等，便于他人使用。

针对工具类小程序，每发布一次程序，都要写好ReadMe.txt，做为版本发布记录，该文件中大概有以下内容：

1. 使用方法
2. 程序维护人以及联系方式（邮箱、电话等）
3. 源代码的SVN库路径、最新发布程序路径
4. 各个版本的更新记录