潍坊网站建设公司推荐,wordpress 文章页面,百度推广信息流有用吗,wordpress购物商城代码前言
最近知乎上#xff0c;有一位大佬邀请我回答下面这个问题#xff0c;看到这个问题我百感交集#xff0c;感触颇多。 在我是新人时#xff0c;如果有前辈能够指导方向一下#xff0c;分享一些踩坑经历#xff0c;或许会让我少走很多弯路#xff0c;节省更多的学习的…前言
最近知乎上有一位大佬邀请我回答下面这个问题看到这个问题我百感交集感触颇多。 在我是新人时如果有前辈能够指导方向一下分享一些踩坑经历或许会让我少走很多弯路节省更多的学习的成本。
这篇文章根据我多年的工作经验给新人总结了25条建议希望对你会有所帮助。
1.写好注释
很多小伙伴不愿意给代码写注释主要有以下两个原因 开发时间太短了没时间写注释。 《重构》那本书说代码即注释。
我在开发的前面几年也不喜欢写注释觉得这是一件很酷的事情。
但后来发现有些两年之前的代码业务逻辑都忘了有些代码自己都看不懂。特别是有部分非常复杂的逻辑和算法需要重新花很多时间才能看明白可以说自己把自己坑了。
没有注释的代码不便于维护。
因此强烈建议大家给代码写注释。
但注释也不是越多越好注释多了增加了代码的复杂度增加了维护成本给自己增加工作量。
我们要写好注释但不能太啰嗦要给关键或者核心的代码增加注释。我们可以写某个方法是做什么的主要步骤是什么给算法写个demo示例等。
这样以后过了很长时间再去看这段代码的时候也会比较容易上手。
2.多写单元测试
我看过身边很多大佬写代码有个好习惯比如新写了某个Util工具类他们会同时在test目录下给该工具类编写一些单元测试代码。
很多小伙伴觉得写单元测试是浪费时间没有这个必要。
假如你想重构某个工具类但由于这个工具类有很多逻辑要把这些逻辑重新测试一遍要花费不少时间。
于是你产生了放弃重构的想法。
但如果你之前给该工具类编写了完整的单元测试重构完成之后重新执行一下之前的单元测试就知道重构的结果是否满足预期这样能够减少很多的测试时间。
多写单元测试对开发来说是一个非常好的习惯有助于提升代码质量。
即使因为当初开发时间比较紧没时间写单元测试也建议在后面空闲的时间内把单元测试补上。
3.主动重构自己的烂代码
好的代码不是一下子就能写成的需要不断地重构修复发现的bug。
不知道你有没有这种体会看自己1年之前写的代码简直不忍直视。
这说明你对业务或者技术的理解比之前更深入了认知水平有一定的提升。
如果有机会建议你主动重构一下自己的烂代码。把重复的代码抽取成公共方法。有些参数名称或者方法名称当时没有取好的可以及时修改一下。对于逻辑不清晰的代码重新梳理一下业务逻辑。看看代码中能不能引入一些设计模式让代码变得更优雅等等。
通过代码重构的过程以自我为驱动能够不断提升我们编写代码的水平。
4.代码review很重要
有些公司在系统上线之前会组织一次代码评审一起review一下这个迭代要上线的一些代码。
通过相互的代码review可以发现一些代码的漏洞不好的写法发现自己写代码的坏毛病让自己能够快速提升。
当然如果你们公司没有建立代码的相互review机制也没关系。
可以后面可以多自己review自己的代码。
5.多用explain查看执行计划
我们在写完查询SQL语句之后有个好习惯是用explain关键字查看一下该SQL语句有没有走索引。
对于数据量比较大的表走了索引和没有走索引SQL语句的执行时间可能会相差上百倍。
我之前亲身经历过这种差距。
因此建议大家多用explain查看SQL语句的执行计划。
关于explain关键字的用法如果你想进一步了解可以看看我的另外一篇文章《explain | 索引优化的这把绝世好剑你真的会用吗》里面有详细的介绍。
6.上线前整理checklist
在系统上线之前一定要整理上线的清单即我们说的checklist。
系统上线有可能是一件很复杂的事情涉及的东西可能会比较多。
假如服务A依赖服务B服务B又依赖服务C。这样的话服务发版的顺序是CBA如果顺序不对可能会出现问题。
有时候新功能上线时需要提前执行sql脚本初始化数据否则新功能有问题。
要先配置定时任务。
上线之前要在apollo中增加一些配置。
上线完成之后需要增加相应的菜单给指定用户或者角色分配权限。
等等。
系统上线整个过程中可能会涉及多方面的事情我们需要将这些事情记录到checklist当中避免踩坑。
7.写好接口文档
接口文档对接口提供者和接口调用者来说都非常重要。
如果你没有接口文档别人咋知道你接口的地址是什么接口参数是什么请求方式时什么接口多个参数分别代码什么含义返回值有哪些字段等等。
他们不知道必定会多次问你无形当中增加了很多沟通的成本。
如果你的接口文档写的不好写得别人看不懂接口文档有很多错误比如输入参数的枚举值跟实际情况不一样。
这样不光把自己坑了也会把别人坑惨。
因此写接口文档一定要写好尽量不要马马虎虎应付差事。
如果对写接口文档比较感兴趣可以看看我的另一篇文章《瞧瞧别人家的API接口那叫一个优雅》里面有详细的介绍。
8.接口要提前评估请求量
我们在设计接口的时候要跟业务方或者产品经理确认一下请求量。
假如你的接口只能承受100qps但实际上产生了1000qps。
这样你的接口很有可能会承受不住这么大的压力而直接挂掉。
我们需要对接口做压力测试预估接口的请求量需要部署多少个服务器节点。
压力测试的话可以用jmeter、loadRunner等工具。
此外还需要对接口做限流防止别人恶意调用你的接口导致服务器压力过大。
限流的话可以基于用户id、ip地址、接口地址等多个维度同时做限制。
可以在nginx层或者网关层做限流。
9.接口要做幂等性设计
我们在设计接口时一定要考虑并发调用的情况。
比如用户在前端页面非常快的点击了两次保存按钮这样就会在极短的时间内调用你两次接口。
如果不做幂等性设计在数据库中可能会产生两条重复的数据。
还有一种情况时业务方调用你这边的接口该接口发生了超时它有自动重试机制也可能会让你这边产生重复的数据。
因此在做接口设计时要做幂等设计。
当然幂等设计的方案有很多感兴趣的小伙伴可以看看我的另一篇文章《高并发下如何保证接口的幂等性》。
如果接口并发量不太大推荐大家使用在表中加唯一索引的方案更加简单。
10.接口参数有调整一定要慎重
有时候我们提供的接口需要调整参数。
比如新增加了一个参数或者参数类型从int改成String或者参数名称有status改成auditStatus参数由单个id改成批量的idList等等。
建议涉及到接口参数修改一定要慎重。
修改接口参数之前一定要先评估调用端和影响范围不要自己偷偷修改。如果出问题了调用方后面肯定要骂娘。
我们在做接口参数调整时要做一些兼容性的考虑。
其实删除参数和修改参数名称是一个问题都会导致那个参数接收不到数据。
因此尽量避免删除参数和修改参数名。
对于修改参数名称的情况我们可以增加一个新参数来接收数据老的数据还是保留代码中做兼容处理。
11.调用第三方接口要加失败重试
我们在调用第三方接口时由于存在远程调用可能会出现接口超时的问题。
如果接口超时了你不知道是执行成功还是执行失败了。
这时你可以增加自动重试机制。
接口超时会抛一个connection_timeout或者read_timeout的异常你可以捕获这个异常用一个while循环自动重试3次。
这样就能尽可能减少调用第三方接口失败的情况。
当然调用第三方接口还有很多其他的坑感兴趣的小伙伴可以看看我的另一篇文章《我调用第三方接口遇到的13大坑》里面有详细的介绍。
12.处理线上数据前要先备份数据
有时候线上数据出现了问题我们需要修复数据但涉及的数据有点多。
这时建议在处理线上数据前一定要先备份数据。
备份数据非常简单可以执行以下sql
create table order_2022121819 like order;
insert into order_2022121819 select * from order;数据备份之后万一后面哪天数据处理错了我们可以直接从备份表中还原数据防止悲剧的产生。
13.不要轻易删除线上字段
不要轻易删除线上字段至少我们公司是这样规定的。
如果你删除了某个线上字段但是该字段引用的代码没有删除干净可能会导致代码出现异常。
假设开发人员已经把程序改成不使用删除字段了接下来如何部署呢
如果先把程序部署好了还没来得及删除数据库相关表字段。
当有insert请求时由于数据库中该字段是必填的会报必填字段不能为空的异常。
如果先把数据库中相关表字段删了程序还没来得及发。这时所有涉及该删除字段的增删改查都会报字段不存在的异常。
所以线上环境字段不要轻易删除。
14.要合理设置字段类型和长度
我们在设计表的时候要给相关字段设置合理的字段类型和长度。
如果字段类型和长度不够有些数据可能会保存失败。
如果字段类型和长度太大了又会浪费存储空间。
我们在工作中要根据实际情况而定。
以下原则可以参考一下 尽可能选择占用存储空间小的字段类型在满足正常业务需求的情况下从小到大往上选。 如果字符串长度固定或者差别不大可以选择char类型。如果字符串长度差别较大可以选择varchar类型。 是否字段可以选择bit类型。 枚举字段可以选择tinyint类型。 主键字段可以选择bigint类型。 金额字段可以选择decimal类型。 时间字段可以选择timestamp或datetime类型。
15.避免一次性查询太多数据
我们在设计接口或者调用别人接口的时候都要避免一次性查询太多数据。
一次性查询太多的数据可能会导致查询耗时很长更加严重的情况会导致系统出现OOM的问题。
我们之前调用第三方查询一天的指标数据该接口经常出现超时问题。
在做excel导出时如果一次性查询出所有的数据导出到excel文件中可能会导致系统出现OOM问题。
因此我们的接口要做分页设计。
如果是调用第三方的接口批量查询接口尽量分批调用不要一次性根据id集合查询所有数据。
如果调用第三方批量查询接口对性能有一定的要求我们可以分批之后用多线程调用接口最后汇总返回数据。
16.多线程不一定比单线程快
很多小伙伴有一个误解认为使用了多线程一定比使用单线程快。
其实要看使用场景。
如果你的业务逻辑是一个耗时的操作比如远程调用接口或者磁盘IO操作这种使用多线程比单线程要快一些。
但如果你的业务逻辑非常简单在一个循环中打印数据这时候使用单线程可能会更快一些。
因为使用多线程会引入额外的消耗比如创建新线程的耗时抢占CPU资源时线程上下文需要不断切换这个切换过程是有一定的时间损耗的。
因此多线程不一定比单线程快。我们要根据实际业务场景决定是使用单线程还是使用多线程。
17.注意事务问题
很多时候我们的代码为了保证数据库多张表保存数据的完整性和一致性需要使用Transactional注解的声明式事务或者使用TransactionTemplate的编程式事务。
加入事务之后如果A,B,C三张表同时保存数据要么一起成功要么一起失败。
不会出现数据保存一半的情况比如表A保存成功了但表B和C保存失败了。
这种情况数据会直接回滚A,B,C三张表的数据都会同时保存失败。
如果使用Transactional注解的声明式事务可能会出现事务失效的问题。
建议优先使用TransactionTemplate的编程式事务的方式创建事务。
此外引入事务还会带来大事务问题可能会导致接口超时或者出现数据库死锁的问题。
因此我们需要优化代码尽量避免大事务的问题因为它有许多危害。
18.小数容易丢失精度
不知道你在使用小数时有没有踩过坑一些运算导致小数丢失了精度。
如果你在项目中使用了float或者double类型的数据用他们参与计算极可能会出现精度丢失问题。
使用Double时可能会有这种场景
double amount1 0.02;
double amount2 0.03;
System.out.println(amount2 - amount1);正常情况下预计amount2 - amount1应该等于0.01
但是执行结果却为
0.009999999999999998实际结果小于预计结果。
Double类型的两个参数相减会转换成二进制因为Double有效位数为16位这就会出现存储小数位数不够的情况这种情况下就会出现误差。
因此在做小数运算时更推荐大家使用BigDecimal避免精度的丢失。
但如果在使用BigDecimal时使用不当也会丢失精度。
BigDecimal amount1 new BigDecimal(0.02);
BigDecimal amount2 new BigDecimal(0.03);
System.out.println(amount2.subtract(amount1));这个例子中定义了两个BigDecimal类型参数使用构造函数初始化数据然后打印两个参数相减后的值。
结果
0.0099999999999999984734433411404097569175064563751220703125使用BigDecimal的构造函数创建BigDecimal也会导致精度丢失。
如果如何避免精度丢失呢
BigDecimal amount1 BigDecimal.valueOf(0.02);
BigDecimal amount2 BigDecimal.valueOf(0.03);
System.out.println(amount2.subtract(amount1));使用BigDecimal.valueOf方法初始化BigDecimal类型参数能保证精度不丢失。
19.优先使用批量操作
有些小伙伴可能写过这样的代码在一个for循环中一个个调用远程接口或者执行数据库的update操作。
其实这样是比较消耗性能的。
我们尽可能将在一个循环中多次的单个操作改成一次的批量操作这样会将代码的性能提升不少。
例如
for(User user : userList) {userMapper.update(user);
}改成
userMapper.updateForBatch(userList);20.synchronized其实用的不多
我们在面试中当中经常会被面试官问到synchronized加锁的考题。
说实话synchronized的锁升级过程还是有点复杂的。
但在实际工作中使用synchronized加锁的机会不多。
synchronized更适合于单机环境可以保证一个服务器节点上多个线程访问公共资源时只有一个线程能够拿到那把锁其他的线程都需要等待。
但实际上我们的系统大部分是处于分布式环境当中的。
为了保证服务的稳定性我们一般会把系统部署到两个以上的服务器节点上。
后面哪一天有个服务器节点挂了系统也能在另外一个服务器节点上正常运行。
当然也能会出现一个服务器节点扛不住用户请求压力也挂掉的情况。
这种情况应该提前部署3个服务节点。
此外即使只有一个服务器节点但如果你有api和job两个服务都会修改某张表的数据。
这时使用synchronized加锁也会有问题。
因此在工作中更多的是使用分布式锁。
目前比较主流的分布式锁有 数据库悲观锁。 基于时间戳或者版本号的乐观锁。 使用redis的分布式锁。 使用zookeeper的分布式锁。
其实这些方案都有一些使用场景。
目前使用更多的是redis分布式锁。
当然使用redis分布式锁也很容易踩坑感兴趣的小伙伴可以看看我的另一篇文章《聊聊redis分布式锁的8大坑》里面有详细介绍。
21.异步思想很重要
不知道你有没有做过接口的性能优化其中有一个非常重要的优化手段是异步。
如果我们的某个保存数据的API接口中的业务逻辑非常复杂经常出现超时问题。
现在让你优化该怎么优化呢
先从索引sql语句优化。
这些优化之后效果不太明显。
这时该怎么办呢
这就可以使用异步思想来优化了。
如果该接口的实时性要求不高我们可以用一张表保存用户数据然后使用job或者mq这种异步的方式读取该表的数据做业务逻辑处理。
如果该接口对实效性要求有点高我们可以梳理一下接口的业务逻辑看看哪些是核心逻辑哪些是非核心逻辑。
对于核心逻辑可以在接口中同步执行。
对于非核心逻辑可以使用job或者mq这种异步的方式处理。
22.Git提交代码要有好习惯
有些小伙伴不太习惯在Git上提交代码。
非常勤劳的使用idea写了一天的代码最后下班前准备提交代码的时候电脑突然死机了。
会让你欲哭无泪。
用Git提交代码有个好习惯是多次提交。
避免一次性提交太多代码的情况。
这样可以减少代码丢失的风险。
更重要的是如果多个人协同开发别人能够尽早获取你最新的代码可以尽可能减少代码的冲突。
假如你开发一天的代码准备去提交的时候发现你的部分代码别人也改过了产生了大量的冲突。
解决冲突这个过程是很痛苦的。
如果你能够多次提交代码可能会及时获取别人最新的代码减少代码冲突的发生。因为每次push代码之前Git会先检查一下代码有没有更新如果有更新需要你先pull一下最新的代码。
此外使用Git提交代码的时候一定要写好注释提交的代码实现了什么功能或者修复了什么bug。
如果有条件的话每次提交时在注释中可以带上jira任务的id这样后面方便统计工作量。
23.善用开源的工具类
我们一定要多熟悉一下开源的工具类真的可以帮我们提升开发效率避免在工作中重复造轮子。
目前业界使用比较多的工具包有apache的commongoogle的guava和国内几个大佬些hutool。
比如将一个大集合的数据按每500条数据分成多个小集合。
这个需求如果要你自己实现需要巴拉巴拉写一堆代码。
但如果使用google的guava包可以非常轻松的使用
ListInteger list Lists.newArrayList(1, 2, 3, 4, 5);
ListListInteger partitionList Lists.partition(list, 2);
System.out.println(partitionList);如果你对更多的第三方工具类比较感兴趣可以看看我的另一篇文章《吐血推荐17个提升开发效率的“轮子”》。
24.培养写技术博客的好习惯
我们在学习新知识点的时候学完了之后非常容易忘记。
往往学到后面把前面的忘记了。
回头温习前面的又把后面的忘记了。
因此建议大家培养做笔记的习惯。
我们可以通过写技术博客的方式来记笔记不仅可以给学到的知识点加深印象还能锻炼自己的表达能力。
此外工作中遇到的一些问题以及解决方案都可以沉淀到技术博客中。
一方面是为了避免下次犯相同的错误。
另一方面也可以帮助别人少走弯路。
而且在面试中如果你的简历中写了技术博客地址是有一定的加分的。
因此建议大家培养些技术博客的习惯。
25.多阅读优秀源码
建议大家利用空闲时间多阅读JDK、Spring、Mybatis的源码。
通过阅读源码可以真正的了解某个技术的底层原理是什么这些开源项目有哪些好的设计思想有哪些巧妙的编码技巧使用了哪些优秀的设计模式可能会出现什么问题等等。
当然阅读源码是一个很枯燥的过程。
有时候我们会发现有些源码代码量很多继承关系很复杂使用了很多设计模式一眼根本看不明白。
对于这类不太容易读懂的源码我们不要一口吃一个胖子。
要先找一个切入点不断深入由点及面的阅读。
我们可以通过debug的方式阅读源码。
在阅读的过程中可以通过idea工具自动生成类的继承关系辅助我们更好的理解代码逻辑。
我们可以一边读源码一边画流程图可以更好的加深印象。
当然还有很多建议由于篇幅有限后面有机会再跟大家分享。
