【新人指南】给新人软件开发工程师的干货建议

在我是新人时,如果有前辈能够指导方向一下,分享一些踩坑经历,或许会让我少走很多弯路,节省更多的学习的成本。

这篇文章根据我多年的工作经验,给新人总结了一些建议,希望对你会有所帮助。

【新人指南】给新人软件开发工程师的干货建议_第1张图片

写好注释

  • 没有注释的代码,不便于维护。
  • 我们要写好注释,但不能太啰嗦,要给关键或者核心的代码增加注释。我们可以写某个方法是做什么的,主要步骤是什么,给算法写个demo示例等。
  • 这样以后过了很长时间,再去看这段代码的时候,也会比较容易上手。

单元测试

  • 比如新写了某个Util工具类,他们会同时在test目录下,给该工具类编写一些单元测试代码。
  • 很多小伙伴觉得写单元测试是浪费时间,没有这个必要。
  • 多写单元测试对开发来说,是一个非常好的习惯,有助于提升代码质量。
  • 即使因为当初开发时间比较紧,没时间写单元测试,也建议在后面空闲的时间内,把单元测试补上。

SQL 执行计划

  • 我们在写完查询SQL语句之后,有个好习惯是用explain关键字查看一下该SQL语句有没有走索引。
  • 对于数据量比较大的表,走了索引和没有走索引,SQL语句的执行时间可能会相差上百倍。
  • 因此建议大家多用explain查看SQL语句的执行计划,在SQL进行优化的时候找出具体慢的原因,给出相应的优化方案。
  • 可参考:https://blog.csdn.net/u010800804/article/details/109594810

上线整理checklist

  • 在系统上线之前,一定要整理上线的清单,即我们说的:checklist。
  • 系统上线有可能是一件很复杂的事情,涉及的东西可能会比较多。
  • 假如服务A依赖服务B,服务B又依赖服务C。这样的话,服务发版的顺序是:CBA,如果顺序不对,可能会出现问题。
  • 有时候新功能上线时,需要提前执行sql脚本初始化数据,否则新功能有问题。
  • 如上线前需在配置中心、任务调度中心进行相关配置,不然项目启动可能异常。
  • 上线完成之后,需要增加相应的菜单,给指定用户或者角色分配权限。
  • 系统上线,整个过程中,可能会涉及多方面的事情,我们需要将这些事情记录到checklist当中,避免遗漏。

接口文档

  • 接口文档对接口提供者,和接口调用者来说,都非常重要。
  • 如果你没有接口文档,别人咋知道你接口的地址是什么,接口参数是什么,请求方式时什么,接口多个参数分别代码什么含义,返回值有哪些字段等等。
  • 他们不知道,必定会多次问你,无形当中,增加了很多沟通的成本。
  • 如果你的接口文档写的不好,写得别人看不懂,接口文档有很多错误,比如:输入参数的枚举值,跟实际情况不一样。
  • 接口文档也分为内部接口文档,主要和前端进行联调;一种是openapi接口文档,交付与别人的接口一定经过开发自测的,不能让前端一调用接口直接报错等情况,这样不光把自己坑了,也会把别人坑惨。
  • 因此,写接口文档一定要写好,一定不要马马虎虎应付差事

业务提前评估请求量

  • 我们在设计接口的时候,要跟业务方或者产品经理确认一下请求量。
  • 比如经常调用的接口是不是要缓存还是直接查询数据库,某些业务是不是要加锁等情况。
  • 假如你的接口只能承受100qps,但实际上产生了1000qps。
  • 这样你的接口,很有可能会承受不住这么大的压力,而直接挂掉。
  • 此外,还需要对接口做限流,防止别人恶意调用你的接口,导致服务器压力过大。
  • 限流的话,可以基于用户ID、IP地址、接口地址等多个维度同时做限制。
  • 可以在nginx层,或者网关层做限流。

接口幂等设计

  • 我们在设计接口时,一定要考虑并发调用的情况。
  • 比如:用户在前端页面,非常快的点击了两次保存按钮,这样就会在极短的时间内调用你两次接口。
  • 如果不做幂等性设计,在数据库中可能会产生两条重复的数据。
  • 还有一种情况时,业务方调用你这边的接口,该接口发生了超时,它有自动重试机制,也可能会让你这边产生重复的数据。
  • 所以我们在开发过程中,根据实际业务场景进行幂等设计及限制,如果接口并发量不太大,推荐大家使用在表中加唯一索引的方案,更加简单。

接口参数调整慎重

  • 有时候我们提供的接口,需要调整参数。
  • 比如:新增加了一个参数,或者参数类型从int改成String,或者参数名称有status改成auditStatus,参数由单个id改成批量的idList等等。
  • 建议涉及到接口参数修改一定要慎重。
  • 修改接口参数之前,一定要先评估调用端和影响范围,不要自己偷偷修改。如果出问题了,调用方后面肯定要苦逼啦。
  • 我们在做接口参数调整时,要做一些兼容性的考虑。
  • 对于修改参数名称的情况,我们可以增加一个新参数,来接收数据,老的数据还是保留,代码中做兼容处理。

生产环境,数据备份

  • 有时候,线上数据出现了问题,我们需要修复数据,但涉及的数据有点多。
  • 这时建议在处理线上数据前,一定要先备份数据。
insert into member_20230806 select * from member
  • 数据备份之后,万一后面哪天数据处理错了,我们可以直接从备份表中还原数据,防止悲剧的产生。

合理设置字段类型和长度

  • 我们在设计表的时候,要给相关字段设置合理的字段类型和长度。
  • 如果字段类型和长度不够,有些数据可能会保存失败。
  • 以下原则可以参考一下:

尽可能选择占用存储空间小的字段类型,在满足正常业务需求的情况下,从小到大,往上选。
如果字符串长度固定,或者差别不大,可以选择char类型。如果字符串长度差别较大,可以选择varchar类型。
是否字段,可以选择bit类型。
枚举字段,可以选择tinyint类型。
主键字段,可以选择bigint类型。
金额字段,可以选择decimal类型。
时间字段,可以选择timestamp或datetime类型。

避免一次性查询太多数据

  • 我们在设计接口,或者调用别人接口的时候,都要避免一次性查询太多数据。
  • 一次性查询太多的数据,可能会导致查询耗时很长,更加严重的情况会导致系统出现OOM的问题。
  • 在做excel导出时,如果一次性查询出所有的数据,导出到excel文件中,可能会导致系统出现OOM问题。
  • 如果调用第三方批量查询接口,对性能有一定的要求,我们可以分批之后,用多线程调用接口,最后汇总返回数据。

事务问题

  • 很多时候,我们的代码为了保证数据库多张表保存数据的完整性和一致性,需要使用@Transactional注解的声明式事务,或者使用TransactionTemplate的编程式事务。
  • 加入事务之后,如果A,B,C三张表同时保存数据,要么一起成功,要么一起失败。
  • 不会出现数据保存一半的情况,比如:表A保存成功了,但表B和C保存失败了。
  • 这种情况数据会直接回滚,A,B,C三张表的数据都会同时保存失败。
  • 此外,引入事务还会带来大事务问题,可能会导致接口超时,或者出现数据库死锁的问题。
  • 因此,我们需要优化代码,尽量避免大事务的问题,因为它有许多危害。

优先使用批量操作

  • 在一个for循环中,一个个调用远程接口,或者执行数据库的update操作。
  • 我们尽可能将在一个循环中多次的单个操作,改成一次的批量操作,这样会将代码的性能提升不少。
for(User user : userList) {
   userMapper.update(user);
}
userMapper.updateForBatch(userList);

synchronized问题

  • 我们在面试中当中,经常会被面试官问到synchronized加锁的考题。
  • 但在实际工作中,使用synchronized加锁的机会不多。
  • synchronized更适合于单机环境,可以保证一个服务器节点上,多个线程访问公共资源时,只有一个线程能够拿到那把锁,其他的线程都需要等待。
  • 但实际上我们的系统,大部分是处于分布式环境当中的。
  • 为了保证服务的稳定性,我们一般会把系统部署到两个以上的服务器节点上。
  • 后面哪一天有个服务器节点挂了,系统也能在另外一个服务器节点上正常运行。
  • 这时使用synchronized加锁也会有问题。
  • 因此,在工作中更多的是使用分布式锁。

数据库悲观锁。
基于时间戳或者版本号的乐观锁。
使用redis的分布式锁。
使用zookeeper的分布式锁。

异步思想

  • 做过接口的性能优化,其中有一个非常重要的优化手段是:异步。
  • 如果我们的某个保存数据的API接口中的业务逻辑非常复杂,经常出现超时问题。
  • 先从索引,sql语句优化。
  • 如果该接口的实时性要求不高,我们可以用一张表保存用户数据,然后使用job或者mq,这种异步的方式,读取该表的数据,做业务逻辑处理。
  • 对于非核心逻辑,可以使用job或者mq这种异步的方式处理。

Git提交代码要有好习惯

  • 用Git提交代码有个好习惯是:多次提交。
  • 避免一次性提交太多代码的情况。
  • 这样可以减少代码丢失的风险。
  • 更重要的是,如果多个人协同开发,别人能够尽早获取你最新的代码,可以尽可能减少代码的冲突。
  • 假如你开发一天的代码准备去提交的时候,发现你的部分代码,别人也改过了,产生了大量的冲突。
  • 如果你能够多次提交代码,可能会及时获取别人最新的代码,减少代码冲突的发生。因为每次push代码之前,Git会先检查一下,代码有没有更新,如果有更新,需要你先pull一下最新的代码。
  • 此外,使用Git提交代码的时候,一定要写好注释,提交的代码实现了什么功能,或者修复了什么bug。

开源工具类

  • 我们一定要多熟悉一下开源的工具类,真的可以帮我们提升开发效率,避免在工作中重复造轮子。
  • hutool 可以帮忙解决日常工作的大部分util。

技术博客

  • 我们在学习新知识点的时候,学完了之后,非常容易忘记。
  • 往往学到后面,把前面的忘记了。
  • 因此,建议大家培养做笔记的习惯。
  • 我们可以通过写技术博客的方式,来记笔记,不仅可以给学到的知识点加深印象,还能锻炼自己的表达能力。
  • 此外,工作中遇到的一些问题,以及解决方案,都可以沉淀到技术博客中。
  • 一方面是为了避免下次犯相同的错误。
  • 另一方面也可以帮助别人少走弯路。

你可能感兴趣的:(职场生活,#,技术管理,#,打工人,java,开发语言,软件开发入门)