产生代码质量的问题有下面四类：
1.代码编写的错误，导致业务逻辑错误，无法运行。
2.对整体系统不熟悉，为了实现A功能却影响了B功能。
3.方案设计的问题，缺乏足够细节，导致功能需要实现1、2、3，但最终只实现了1、1.5和2.5。
4.编码设计思路问题，功能虽然实现，但却无法满足性能或安全要求。
目前团队代码编写质量比较突出的问题是1、3
第一类问题属于程序员的基础能力问题，主要原因有以下几点：
1.很少沟通、很少反馈问题，只是低头写代码，对可能存在的问题，或不理解的问题不做及时的沟通和反馈，而这些问题很可能是同项目另一端同学已经解决或同时面临的，这一点是导致代码质量和效率低的重要原因。
2.始终没有建立有效的代码规范，代码规范不仅是编写代码的书写格式上的规范，同时也应该是编写代码思想上的统一规范。这一点需要像站会一样有计划的，固定时间来开展，才会有进展。不一定一开始就建一个多全的规范，以解决问题出发，遇到一个问题，解决一个问题，形成一个规范。
3.第三点是个人能力素质的问题。
第二类问题也是团队目前经常会遇到的问题，但是随着开发的不断深入，此类问题影响会逐步降低，但是为了彻底解决此类问题，需要在合适的阶段尽早引入单元测试流程。
单元测试流程是在编码阶段实现的功能设计一个可自动化执行的单元测试用例代码，在将新的代码后提交到代码管理平台，例如gitlab，就会开始基于所有的单元测试代码进行一次回归测试，对所有单元功能进行验证，看看是否功能是否返回预期值。而不是等到正式提测后由测试人工验证。
单元测试虽然会增加编写代码的工作量，但会开发效率整体提升有很大的帮助。因此需要从现在开始逐步建立。
第三类问题属于产品和研发的沟通问题，也是目前研发和测试反馈最大的问题。
目前阶段，因为时间原因，产品在编写功能需求时，不可能特别细。在评审阶段，也并不是所有人能马上考虑到所有问题。虽然测试团队在编写测试用例过程中，做了很大的补充，但是这些补充，并未左移，因此导致功能开发完成后，有很多需要优化的工作，从而降低了开发效率。因此，为解决这个问题，在和研发和测试同学沟通后，总结了他们提出的几点建议：
1.产品需求文档越细致，所耗费的时间就越多，所以，建议通过可交互的UI原型图来弥补细节，按研发同学的话来说，文档讲真不会那么细心的看，但好的UI原型图，一看就知道怎么做了。
2.用户故事很重要，其实一句话，“谁”以什么“角色”希望“做什么”以便“达到什么目标或商业价值”，需求以此传递，大家心中也就有一个数了。
3.测试评审需要加强，目前大家对测试用例评审并不是特别的重视，导致很多测试人员补充的细节并没有在开发过程中第一时间被了解，因此后续的工作中，加强测试用例的评审工作。
第四类问题属于架构层面的工作，目前只能通过开发后期的压力测试和安全性测试进行弥补，但是性能和安全性需要制定一个规范，什么标准符合规范。
因此基于以上思考，我计划开展以下几项工作：
首先需要监督开发质量，通过数据了解开发质量存在哪些问题，因此在周末，我对缺陷提报的模板进行了补充，由此在缺陷报表中可以通过更多的维度了解到更多数据情况，目前只能看到在摸一个时间段内，谁产生了多少Bug，解决了多少。
1.增加了缺陷打开次数字段，可了解同一个缺陷打开多少次
2.增加了缺陷发现阶段字段，共分为“冒烟测试”、“功能测试”、“合并测试”、“验收”、“回归测试”、“线上bug”6个阶段，由此可了解BUG集中产生的阶段。
3.增加了缺陷类型字段，共分为“编码错误”、“业务不理解”、“性能风险“、”安全性风险“四个类型，由此可了解团队BUG集中的类型。
4.增加了”测试人员“、”开发人员“字段，以前只有”处理人“，责权不清
5.增加了”解决期限“字段
由此，可进一步通过数据清晰了解开发质量，并对BUG处理进度进行监督。
第二、拟建立定期codereview制度
目前因为目前代码开发效率的要求，也不好开太多的会，占用太对的工作时间，我计划在每个周二晚上由安卓、苹果、java的PLA对组内其他同学代码编写代码进行评审，在评审过程中，提出问题和意见，并由此逐步建立代码规范。
第三、建立单元测试流程
第四、强化老带新的工作风气，建立新人责任制，新人出的问题，老人如果不反馈，也要跟着负责。同时也要强化新人和老人沟通反馈的文化。
综上想法，都是基于“质量左移”的思路，提升开发质量，需要从在编写代码前的产品方案制定、测试用例评审、代码审计等方面做深做透才能有效提升代码的编写质量。
网友评论