查看原文
其他

关于盘点和总结的那点事儿

张飞洪 SpringForAll社区 2021-05-26
点击上方☝SpringForAll社区 轻松关注!
及时获取有趣有料的技术文章

本文来源:

https://www.cnblogs.com/jackyfei/p/11971685.html

本月的功能在踉跄中勉强上线了,这个月有实验的味道,有摸索的代价,有分工和衔接上的问题,有技术储备方面的不足,有业务梳理方面的欠缺,也有个人能力和意识上的不足,梳理整个开发流程,目前存在的几大问题:

一、代码质量问题:

描述分析

1.性能层面

  从综合维度看,代码质量好坏取决于开发人员整体的编程经验:比如操作系统,设计模式,数据结构和算法,网络原理,数据库,前端等等因素。

  就目前系统整体上看,性能可能会出现的地方,从优先级权重来排列,主要集中在:

  • 数据库优化技术偏弱

  • 不看执行计划

  • 对索引的理解比较浅,没用好索引

  • SQL优化经验薄弱

  • 数据库查询和脚本问题。

    • 关联查询

    • 索引缺失

    • 请求频率

  • 减少请求次数

  • 减少接口对数据库请求

  • 减少前端图片请求

  • 减少前端css/js请求

善用缓存

  • 静态文件CDN缓存

  • 基础数据共享缓存

内容压缩

  • 图片压缩

  • 请求文件压缩

  • 富文本内容压缩

  • 主站可能出现的高并发查询。

  • 网络带宽延迟。

2.规范层面

  • 命名随意性

      有些规范是可以文档化的。比如全局变量全部大写,局部变量驼峰命名,文件前后缀命名等等比较容易约定俗成;

      有些规范无法约定的。比如作业调度有些人命名jobs,有些人命名schedule。如果要想规范必须把业务考虑进来。如果只是想表达定时作业,属于技术术语job可能比较合适;如果是业务层面的任务调度可能schedule比较合适。也就是说如果碰到模棱两可的命名的时候,需要增加考虑因子,通过扩大“视野”来更精确的命名它。

      如果碰到一个问题始终不清楚要如何命名的时候,首先应该要反省的是自己对业务熟悉不熟悉,对系统整体熟悉不熟悉。如果实在无法确认,最好请教和沟通,一般都能做好命名。说不定能发现一些自己无知的内容。

      如果真的觉得用名字无法描述清楚,言不尽意,模棱两可,那就增加代码注释。代码注释的前提是自解释,实在无法达意才去做注释,因为注释太多也是有成本的。

一致性优先,也就是说一致性是可读性的基础,否则数据库一种命名,业务代码一种命名就是错乱了。比如公司叫Company,但是业务命名叫Supplier,会员叫Member。这里会出现这种不一致的命名,主要原因还是对业务领域不清楚导致的。

  所以在底层命名非常关键,比如数据模型的表和字段的命名,如果底层命名错误,从上下往上只能将错就错,让人改也不是,不改也不是。

  总之,代码命名和给孩子取名字一样,其实都是需要慎之又慎,不可随意叫个阿猫阿狗什么的。这里有个原则就是要遵循:简单,可读,统一和优雅的原则,当然优雅是最高的要求。

  • 规范不是万能

      规范仅仅写个规范文档是很不够的,写好并持续完善规范文档只是万里长征第一步。只有规范文档,没有落地检查,文档也会变成一纸空文。

      定个原则是比较容易和简单的,如果细细追究,里面有很多坑。

      首先大家对简单,可读,统一的理解各不相同,最后生成的代码必然是千人前面,理论上需要对业务的深入了解,需要有很好的英文功底,同时在整体上要做经常性的检查和复盘。

      但是引入代码审查又需要成本,假设一个月审查一次,那么对每个成员编写的一个月的代码,从月初到月底进行一番梳理和纠正,没有1-2天是无法完成的。

      所以审查是有成本的,要不要审查呢?

      权衡利弊,必须要审查,而且要按照规范,引入严苛的代码审查机制,每个月做一次代码规范和代码质量的检查和考核。

      为什么要严苛来做代码审核呢?因为代码质量反应了我们的产品质量,代码的好坏决定了未来运维的成本,技术债务的危害怎么形容都不为过,轻则系统局部异常,中等的会导致修改困难,严重的推翻重来。

      如果因为进度一时妥协,回头又忘记了修改,中间又出现人员变动,那么这份代码的后患是无穷的,因为没有规范的代码,对交接人来说从心态上是本能反抗的,但是又不得不改,于是就一通乱改,能贴膏药就贴膏药,能运行就可以,管他规范不规范。这样导致的结果是对规范来说,只能从不规范走向更加不规范,最后走向无法维护。

落地解决:

  1.性能层面:

  • 任务分解和文档化

磨刀不负砍柴功,开发之前进行技术评估,识别出其中技术复杂度和难度,及早发现性能方面可能会产生的问题。

把评估的内容逐条分解罗列并做文档化,对容易的功能尽量不要有心态上的藐视。

遇到没有把握的技术问题,及时的拿出来讨论,不要觉得不好意思。

  • 数据库层面:

  • 通过个人持续学习和提高数据库优化技能:

  • 学会查看执行计划

    • 了解索引的底层原理

    • 深入理解关联查询的底层原理

  • 主站需要生成静态页面进行缓存。

  • 增加页面静态缓存技术

  • 增加CDN技术

  • 多研究学习和参考别人写的代码,做好底层的技术沉淀,平时多练练内功。

  • 通过针对性内部培训来提高个人薄弱环节,让技术均衡发展,又各有特长。

      2.规范层面:

  • 编写规范的文档,并持续更新和完善

  • 严格遵循规范来写代码,如果规范当中没有的,需要适当讨论并做迭代规范。

  • 按照规范进行代码审查,每个开发人员都参与其中,每隔两周轮流进行代码的检查和盘点。直到团队形成默契,可以在后期适当的减少审查频率。

  • 基本的规范审查并不难,比如命名,函数的长度等,只要遵循文档来做就可以了。

  • 难的是对没有接触过的技术应该如何做?比如单点登录,路由规则等。

  • 参与前期的需求分析,如果没有则后期自行了解,比如以询问的方式进行了解。

    • 了解技术评估和技术原理。

    • 查看当事人的源代码。

二、测试发布问题

描述分析:

  • 周期:每个月集中到最后一周进行测试和发布时间太紧迫,如果中间缺少交互和确认,很难保证结果不偏离方向。

  • 人设:测试人员对业务和测试流程缺少前置准备,包括业务的烂熟于心,测试工具和测试数据的知识储备,导致测试时候不知道如何测试,在本来时间不足的情况下,增加沟通成本。同时测试水平只停留在简单浅层的黑盒测试层面,对于深层次的问题,比如压力测试,DDos攻击,安全层面的往往就测试不到了。

  • 功能测试:测试力度远远不足。原因有如下几种:

  • 边测试边修改边上线,修改速度不及测试速度,导致开发紊乱。

  • 前期测试重视不够,部分业务理解异常,等到测试出来,修改的周期可能会很长,这样其他积累下来的BUG处理起来就只能长时间等待了……

  • 集成测试

  • 功能分工导致的个人只测试和自己相关的功能,但是系统是一个整体,在测试边界处是需要双方集成测试的,比如Message的来往功能。

落地解决:

  • 周期:改进交付时间,每隔两周就交付测试,增加交付频率,尽早发现和解决问题。

  • 人设:

  • 增加测试人员May和Kaka的前期业务培训和接受业务熟练度的考核,减少测试的遗漏。

  • 增加对测试人员包括开发测试的测试技能培训,提升测试人员的测试水平。比如对测试人员来说,需要学习产品经理的思维和设计原理,增加测试人员的主动性,让测试人员能站在用户的角度来进行测试,而不是简单的鼠标点点。

  • 从心态上重视测试,测试是闭环的最后一个环节,缺一不可。对测试要有敬畏感,测试并不是简单的点一点鼠标的问题,测试的水可深可浅。测试人员需要的是综合能力,测试技能怎么强调都是不为过的。

  • 编写测试用例文档。测试既要有心态上的重视,也要有可落地的操作方法,而测试用例文档可以很好的指导每个测试人员进行统一测试,避免测试的遗漏和不足。

  • 文档内容涵盖测试的各个维度,该文档编写人员尽量对产品的理解要达到设计人员的水平,对每个角落的测试用例要尽可能详尽。该测试用例模板必须要规范,用来指导开发和测试人员进行完整详尽的测试。

  • 开发人员内测:

  • - 功能测试:执行交换角色测试

  • 集成测试:交换角色测试,负责人集中测试。

三、开发效率问题

描述分析:

  1.业务层面

  • 业务理解不透彻导致的代码BUG,比如Message系统模块,收发人员流程无法打通;

  • 对数据库模型理解偏差导致的功能BUG,例子同上;

  • 开发任务分工和配合不足;

  • 开发交付频率不足,导致的过程脱节和问题集中积压,最后处理缓慢和延迟;

      2.技术层面

  • 前端技术积累薄弱,遇到复杂一点的前端做起来比较耗时;

  • 技术复杂度预估不足,导致的开发延迟。

  • 分工导致的集成薄弱,比如集成测试,需求和开发沟通成本。

落地解决:

  1.业务层面

  • 业务培训:产品需求文档需要提前发布预热,培训后需要做业务复述,复杂的需要做详细的设计文档,直到产品经理觉得正确后再进行开发设计。

  • 对于复杂功能的业务,采用专题会议的方式,反复讨论,进行头脑风暴,把业务掰开揉碎讲清楚,直到当事人能复述通过为止。针对个别复杂的业务,比如公共询盘功能,需要出详细的需求文档。

      2.技术层面

  • 前端技术难点:自研解决,实在无法解决再去考虑外包和招聘。

  • 开发前需要做任务分解,识别出技术复杂度,对没有把握的技术要及早提出疑问,通过团队的力量拿出合理的解决方案。

  • 功能层面,进行角色互换测试。比如Arvin测试Ive的Message模块,Ive测试Arvin的机械表单模块。

四、开发意识问题:

以下从三个方面总结一下成员开发过程中的意识问题。

  • 树立严谨心态

      对开发来说,各个环节要持有严谨和一丝不苟的态度,树立简单并不简单的意识。对于完成的功能,如果时间上允许,需要反复回头检查可能出现的问题,不要满目乐观,或者觉得某个功能很简单,要站在可能出现问题的立场上来看待正常的功能。因为我们要打造的是产品,而不是项目,不是小孩过家家的功能。

  • 重构意识

      好的代码是不断重构出来的,因为业务和需求是不断叠加的,不可能写出一成不变的代码。当业务倍增,需求变革的时候,再好的代码都会出现生锈,腐蚀和坏味道。所以在不忙的时候,需要经常性的整理自己的代码。

重构解决的是长远的质量和可维护,可扩展的根本问题。技术债务,如果不及时解决,随着时间的推进和人员变动,后续花费的成本会逐渐叠加甚至无法解决,好比盖房子,在有问题的基础上盖房子,盖得越高危险越大,到了晚期可能就只能推倒重建。

  • 重视讨论

      三个臭皮匠赛过诸葛亮,技术越讨论越进步,业务越讨论越明白。对于模棱两可或者完全不懂的问题,尽量多请教和讨论。

      讨论的印象是最深刻的,对个人的成长和帮助也是最大的。比如对Vue的学习和上手,对数据库脚本的编写,对ES的学习和讨论等等……

      树立不懂不丢人,不懂装懂才丢人的意识。不要忌讳或者不好意思讨论。

      讨论讲究效率和默契。要集中时间,充分准备。有些开发人员经常问些没头没脑的问题,既没有背景铺垫,也没有上下文,然后想一出一个问题,频繁的打断别人的思路而不自知。这种沟通是很浪费时间和成本的。



● 线程同步手记

● 漫谈何时从单体架构迁移到微服务?

● 微服务的时间和成本去哪儿了

● 微服务学习导航

● 为什么在做微服务设计的时候需要DDD?

● 假如你是架构师,你要做些什么

● 微服务划分的姿势

● Java IO模型之NIO模型

● MongoDB 集群构建:分片+副本+选举

● Fork-Join框架

● Spring Boot实现动态增删启停定时任务

● MongoDB - 用户与权限

● SpringForAll社区,2019年文章精选10篇

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存