搜索
如何提高产品开发品质讲解内容目前开发过程存在的问题1产品开发品质保障流程2代码重构3测试驱动4日构建5一、目前开发过程存在的问题没有完善的品质保障流程质量低下的代码不重视测试产品开发流程现状开发人员编写代码调试,肉眼观察有问题没问题（自认为）可交付的代码编译修正编译错误登记到JIRA上客户提出需求或现场发现bug产品品质管理严重缺失该流程的最终目标和工作重心都是完成产品功能开发，品质管理严重缺失。产品的开发质量完全靠开发人员的个人责任心以及工作经验来保障，缺乏一个稳定可靠的质量保障流程。这种流程开发出来的产品往往是质量不可靠，需要经常返工的劣质产品。质量低下的代码是导致产品品质不好的根本原因质量低下的代码体现在以下几个方面：重复的代码过长的函数过大类过长的参数列表过度复杂的逻辑判断数据泥团没有专职测试人员来进行功能性测试工作在目前的开发流程中，开发出来的代码只经过开发人员自己简单的测试，没有专职的测试人员来进行详细的功能性测试。这样导致的结果往往是提交到现场的代码会带有不少BUG，一定要经过多次返工才能达到较高的品质。而且这样做的另一个后果是把客户当作测试人员，会给客户留下产品品质不稳定这样一种非常不好的客户体验。开发人员在开发过程中不重视单元测试单元测试是提高产品品质非常重要的一个方法，而我们的开发人员往往会忽视这一点。如果没有单元测试，仅仅依靠测试人员的功能性测试，那么这样的测试工作量会非常大，每次修改一个功能，可能会影响到的其他功能都要一一测试，不仅测试时间会非常长，而且效果也不好，很多细节不一定每次都能测到，这些都是产生BUG的隐患。同时由于我们业务需求都非常复杂多变的，没有一个完善自动化测试流程，而仅仅依靠人工测试，对产品品质的影响是不言而喻的。我们的目标！编写出逻辑清晰、结构简洁、扩展性良好、可测试性高的优秀代码。强化单元测试工作，提高单元测试覆盖率，搭建自动单元测试集，通过日构建来持续集成，对产品质量进行全面控制。通过严格的产品质量管理流程，强化质量管理工作，将所有BUG消灭在公司内部。二、产品开发品质保障流程福建大计划项目开发品质管理流程技术接口人开发负责人质量管理开发人员测试人员与技术接口人进行沟通，了解需求的业务细节组织产品部人员讨论该需求，形成技术方案提交开发计划和需求确认书给现场实施人员制定开发计划,并评估工作量，完善需求确认书分配JIRA上的问题到各个开发人员根据JIRA上各模块功能点的完成情况，统计并考评每个开发人员和质量管理人员的绩效否和客户进行需求确认检查功能点是否开发完毕重开JIRA上的问题将各功能点或者BUG提交至JIRA否在JIRA上备注内部测试通过整理并提交需求文档给大计划开发组同意否与客户交流收集客户需求检查功能点是否开发完毕是关闭JIRA上的问题根据JIRA上提交的功能点进行开发是不同意在JIRA上对问题解决情况进行提交客户签署需求确认书检查单元测试是否已经开发及全面覆盖发现系统BUG是JIRA中需要提交的内容：1、开发人员：开发负责人2、各功能点完成时间（根据工作计划）3、功能点所属模块是否能够实现是和客户商讨修改需求否否同意开发质量管理本开发流程的目标是开发出质量优良的产品，流程的重心在于质量管控，通过质量保障人员对产品质量进行全面把关。对于没有编写单元测试的代码直接打回！质量保障人员负责进行功能性测试，并对提交出去的代码负责。质量保障人员另一个职责是思考如何持续改进产品质量。需求管控对每个需求进行分级评审，最大程度的降低需求变更的频度。所有需求开发前都经过内部评审，对于一些复杂需求把握更加准确，不至于在开发时候产生较大偏差。所有需求的开发工作都有经过客户签字的开发工作量评估，为商务工作开展创造有利条件。所有需求都有详细开发计划，片区人员可以安排相应的测试计划。全过程管控所有缺陷和经过评审的需求都必须在JIRA上登记，否则不予开发。开发计划通过JIRA进行精确体现。片区人员可以通过JIRA实时跟踪产品开发进度。方便后续各类工作量的统计。三、利用代码重构来提高代码质量重构（Refactoring）：是对软件内部结构的一种调整，目的是在不改变外部行为的前提下，提高其可理解性,降低其修改成本为什么重构（1）改进软件的设计。程序员对代码所做的为了满足短期利益代码改动，或再没有完全清楚增个架构下的改动，都很容易是代码失去它的清晰结构，偏离需求或设计。而这些改动的积累很容易使代码偏离它原先设计的初衷而变得不可立即和无法维护。重构则帮助重新组织代码，重新清晰的体现结构和进一步改进设计。为什么重构（2）提高代码质量，更易被理解容易理解的代码可以很容易的维护和做进一步的开发。即使对写这些代码的程序员本身，容易理解代码也可以帮助容易地做修改。程序代码也是文档。而代码首先是写给人看的，让后才是给计算机看的。重构帮助尽早的发现错(Bugs)重构是一个codereview和反馈的过程。在另一个时段重新审视自己或别人代码，可以更容易的发现问题和加深对代码的理解。重构是一个良好的软件开发习惯。为什么重构（3）重构可以提高开发速度重构对设计和代码的改进，都可以有效的提高开发速度。好的设计和代码质量实体提高开发速度的关键。在一个有缺陷的设计和混乱代码基础上的开发，即使表面上进度较快，但本质是试延后对设计缺陷的发现和对错误的修改，也就是延后了开发风险，最终要在开发的后期付出更多的时间和代价。项目的维护成本远高于开发成本.何时重构?添加或者修改功能时一并重构为了增加一个新的功能或者修改原有的功能，程序员需要首先读懂现有的代码。修补错误时一并重构为了修复一个Bug,程序员需要读懂现有的代码。CodeReview时一并重构何时不该重构?代码太混乱，设计完全错误。与其Refactor，不如重写。明天是DeadLine永远不要做Last-Minute-Change。推迟重构，但不可以忽略，即使进入产品期的代码都正确的运行。重构方法介绍：提取函数（1）Stringname=request.getParameter(Name);if(name!=null&&name.length()0){......}Stringage=request.getParameter(Age);if(age!=null&&age.length()0){......}Stringname=request.getParameter(Name);if(!isNullOrEmpty(name)){......}Stringage=request.getParameter(Age);if(!isNullOrEmpty(age)){......}privatebooleanisNullOrEmpty(finalStringstring){if(string!=null&&string.length()0){returntrue;}else{returnfalse;}}重构方法介绍：提取函数（2）提取函数是我最常用的重构手法之一。当我看见一个过长的函数或者一段需要注释才能让人理解用途的代码，我就会将这段代码放进一个独立的函数中。有数个原因造成我喜欢简短而有良好命名的函数。首先，如果每个函数的粒度都很小，那么函数之间彼此复用的机会就更大;其次，这会使高层函数读起来就像一系列注释;再者，如果函数都是细粒度，那么函数的覆写(override)也会更容易些:的确，如果你习惯了看大型函数，恐怕需要一段时问才能适应达种新风格，而且只有当你能给小型函数很好地命名时，它们才能真正起作用，所以你需要在函数名称下点功夫，一个函数多长才算合适?在我看来.长度不是问题，关键在于函数名称和函数本体之间的语义距离，如果提炼动作可以强化代码的清晰度，那就去做，就是函数名称比提炼出来的代码还长也无所谓。重构方法介绍：去除临时变量(1)重构方法介绍：去除临时变量(2)我喜欢尽量除去函数内的临时变量。临时变量往往形成问题，它们会导致大量参数被传来传去，而其实完全没有这种必要。你很容易失去它们的踪迹，尤其在长长的函数之中更是如此。而且，临时变量的存在，往往会阻碍提取函数等其他重构手法的进行。重构方法介绍：重新命名函数(1)publicStringgetItemName(intitemSort,StringitemName){return+itemSort+、+itemName;}publicStringformatItemName(intitemSort,StringitemName){return+itemSort+、+itemName;}重构方法介绍：重新命名函数(2)我极力提倡的一种编程风格就是:将复杂的处理过程分解成小函数。但是，如果做得不好，这会使你费尽周折却弄不清楚这些小函数各白的用途、.要避免这种麻烦，关键就在于给函数起一个好名称；函数的名称应该准确表达它的用途；给函数命名有一个好办法。首先考虑应该给这个函数写上一句怎样的注释，然后想办法将注释变成函数名称。人生不如意十之八九:你常常无法第一次就给函数起一个好名称，这时候你可能会想，就这样将就着吧，毕竟只是一个名称而已。当心!这是恶魔的召唤，是通向混乱之路，千万不要被它诱惑!如果你看到一个函数名称不能很好地表达它的用途，应该马上加以修改。记住，你的代码首先是为人写的，其次才是为计算器写的。而人需要良好名称的函数。想想过去曾经浪费的无数时间吧，如果给每个函数都起一个良好的名称，也许你可以节约好多时间。取一个好名称并不容易，需要经验，要想成为一个真正的编程高手，取名称的水平是至关重要的。重构方法介绍：以多态取代条件表达式（1）publicclassPlanUtil{publicvoidsetPlanState(intplanYear,intitemId,intdataType){switchdataType{case1:setPrePlanState(planYear,itemId);case2:setColPlanState(planYear,itemId);case3:setAftPlanState(planYear,itemId);default:thrownewRuntimeException(不正确的计划类型：+dataType);}}//...更新建议计划状态publicvoidsetPrePlanState…//...更新综合计划状态publicvoidsetColPlanState..//...更新开工计划状态publicvoidsetAftPlanState..publicclassPlanUtil{publicstaticPlanUtilcreate(intdataType){switch(dataType){case1:returnnewPrePlanUtil();case2:returnnewColPlanUtil();case3:returnnewAftPlanUtil();default:thrownewRuntimeException(不正确的计划类型：+dataType);}publicabstractvoidsetPlanState(intplanYear,intitemId,intdataType);publicabstractvoidsavePlan(intplanYear,intitemId,intdataType);}重构方法介绍：以多态取代条件表达式（2）//保存计划数据publicvoidsavePlan(intplanYear,intitemId,intdataType){switchdataType{case1:savePrePlan(planYear,itemId);case2:saveColPlan(planYear,itemId);case3:saveAftPlan(planYear,itemId);default:thrownewRuntimeException(不正确的计划类型