开发过程中的一些提前考虑
<p>[TOC]</p>
<h1>保证开发交付过程中的效率与质量的一些思考</h1>
<h2>1.需求分析</h2>
<p>进行需求交付之前，要对需求进行合理的甄别，不是用户提的所有的要求都是合理的，得考虑三个问题</p>
<h3><strong>1.1需求来源，是否一定要做</strong></h3>
<p>背景是什么，是不是合理，是不是一定得做，有没有其他更好的途径，收益是什么，要能体现业务价值。
这个前提就是得对现有的业务逻辑非常熟悉，如果只是了解一小块流程，那么久很容易被带到沟里，用户说这样做就这样做，因为看的太少而不知道怎么做是对的。
一般比较大的需求得由产品经理评审，因为产品经理的角度又不同，对整个周边相关服务和布局会有更高层次的认识。</p>
<h3><strong>1.2什么时候做</strong></h3>
<p>如果评估确定要做的需求，需要对交付时间和工作量进行分析评估，对需求进行优先级管理，及时拆分子需求给相关负责人，并且最好会议同步需求背景和交付时间，保证大家对需求理解一致。同时通过会议对齐后的需求大家都会了解，可以有效的加深不同开发人员对整体业务的熟悉，不局限于自己的服务。</p>
<h3><strong>1.3要怎么做</strong></h3>
<p>怎么做是一个业务分析的过程，要对场景进行分析，然后将场景转换成需求，分析主要的问题，然后编写好要测试的场景。</p>
<p>比如工具的设计要从整个使用场景去做规划，引导大家应该怎么使用，而不是这个产品提一个需求就针对具体的需求去实现，要有大局观，其他产品会不会有类似的诉求，要优先考虑做通用性的功能，而不是定制化。</p>
<h2>2.编码过程</h2>
<p>当需求确定下来之后，就可以开始考虑编码实现。</p>
<h3><strong>2.1失败重试机制（超时机制）</strong></h3>
<h3><strong>2.2日志处理</strong></h3>
<h3><strong>2.3异常处理</strong></h3>
<pre><code>读写磁盘
边界处理
多线程的线程控制
linux和windows的不同处理，包括文件和命令
逃生通道</code></pre>
<h3><strong>2.4编码风格</strong></h3>
<h2>3.测试过程</h2>
<h3><strong>3.1功能测试</strong></h3>
<h3><strong>3.2性能测试</strong></h3>
<h3><strong>3.3集成测试</strong></h3>
<h3><strong>3.4监控运营</strong></h3>
<h2>4.发布过程</h2>
<h2>5.工作忌讳</h2>
<h3><strong>5.1经常抱怨问题，但是不去解决问题，不推动流程改进</strong></h3>
<p> 有一些同事经常抱怨流程多、流程复杂，并且时时挂在口头上。如果真发现流程有问题，一定要指出哪里流程多、哪个流程有问题。我们希望所有觉得流程有问题、流程多的人，要给所在组织的质量与运营组织、QA提出来，这样我们才好改进。我们一直希望大家能反馈问题，但很多人就只抱怨，而且最后都成了口头禅，动不动流程很多、流程很长、流程阻碍了发展，但从来不去推动流程的改进，从来不指出哪里流程多了，哪个流程长了，哪个流程有问题。那怎么改进呢？</p>
<p> 很多主管讨论存在问题的时候，都是洋洋洒洒，能道出具体问题来，但从不去解决问题。无论是PSST的潜规则还是流程问题，或者是现在政策执行上存在的问题。作为主管，如果能够把你们授权范围内能解决掉的问题全部解决掉，那么很多问题就没有了，特别是潜规则。对于你解决不了的，不在你授权范围内的，若你不去推动解决，那怎么能够解决？</p>
<h3><strong>5.2只做转发器，不做过滤器</strong></h3>
<p> 只做转发器，不做过滤器。对用户侧来的问题要进行过滤，有些需要指导用户使用，了解相关的场景和背景，就算是需要其他人协助的也可以一起学习下，下次就可以自行解决，同时对业务内其他服务也有了更深的理解。每个人都这样，就对整个系统建立了缓存机制，系统响应速度会更快，运行效率也更高，个人也从转发器变成的过滤器。
除开用户问题，相关需要决策的问题也是，会遇到一个两难问题。如果什么都向上级去请示，可能会觉得自己没有任何鞠策的能力，如果没有请示，出了问题又会受责。这个需要平时在日常工作做中逐渐学习掌握。
对下，没有过滤，没有规划，来啥做啥不可取。有些领导会任何地方来了事，他立即就传下去了，不管这个事情该不该做、要不要做，反正不是自己亲自做，这样一来就让下属苦不堪言，不能聚焦工作。</p>
<p>1.1保持良好的编码习惯、严格遵循编码规范、保持团队内部的编码风格一致性
1.2遵循业界最佳实践、保持清晰的命名和目录结构、培养持续重构和优化的意识
1.3严格遵循代码提交规范（保持提交树的清晰和干净）、定期代码检视、掌握快速阅读别人代码并发现问题的能力
1.4养成总结和分享的习惯、学到就应该分享出来、致力于提升整个团队的代码质量
1.5熟悉业务流程和功能、熟悉源码结构/模块关系/公共组件
1.6学会分析需求识别无效需求、善于拆分需求和划分功能模块、规划工作和评估工作量、培养测试先行的意识
1.7掌握调试和定位问题的技巧、通过文件对比/sourcemap/Furion等工具来快速定位问题
1.8熟悉开发工具IDE的使用和快捷键、常用库的能力和API使用
1.9保持对新技术的热情和关注、善于通过新技术来提升开发效率</p>
<p>2.测试<br />
2.1培养测试驱动的意识、开发新特性或修复缺陷之前先写测试用例、开发完照着用例逐一验证
2.2学习规划和编写高效功能用例（需求覆盖率高、不冗余、缺陷揭露能力强）、长期维护用例库和缺陷库、并形成自动化测试用例
2.3善于通过缺陷来学习、总结每一个缺陷的根因和解决方案并归到用例库和缺陷库、致力于零缺陷
2.4学习从用户的角度思考问题和梳理测试场景、积极相应客户、始终把客户的利益放在第一位
2.5善于对测试用例进行优先级划分、重点保障核心和关键的L0场景
2.6掌握常见的用例设计方法（等价类划分、边界值分析、错误推断、因果图、正交组合法等）、善于编写高效用例
2.7学会编写单元测试和自动化测试、通过自动化的手段保障质量和效率</p>
<p>3.发布<br />
3.1培养持续集成的意识、确保每次合入develop/release/master分支的代码都是可用版本、让流水线（Alpha/自用）定时自动流转
3.2熟悉构建和部署流程、熟悉DevCloud/伏羲环境的流水线、善于通过日志排查部署问题
3.3每次部署现网需要结对、并在灰度环境充分验证、部署完都需要打Tag</p>