最近知乎上，有一位大佬邀请我回答下面这个问题，看到这个问题我百感交集，感触颇多。
图片
在我是新人时，如果有前辈能够指导方向一下，分享一些踩坑经历，或许会让我少走很多弯路，节省更多的学习的成本。
这篇文章根据我多年的工作经验，给新人总结了25条建议，希望对你会有所帮助。
很多小伙伴不愿意给代码写注释，主要有以下两个原因：
我在开发的前面几年也不喜欢写注释，觉得这是一件很酷的事情。
但后来发现，有些两年之前的代码，业务逻辑都忘了，有些代码自己都看不懂。特别是有部分非常复杂的逻辑和算法，需要重新花很多时间才能看明白，可以说自己把自己坑了。
没有注释的代码，不便于维护。
因此强烈建议大家给代码写注释。
但注释也不是越多越好，注释多了增加了代码的复杂度，增加了维护成本，给自己增加工作量。
我们要写好注释，但不能太啰嗦，要给关键或者核心的代码增加注释。我们可以写某个方法是做什么的，主要步骤是什么，给算法写个demo示例等。
这样以后过了很长时间，再去看这段代码的时候，也会比较容易上手。
我看过身边很多大佬写代码有个好习惯，比如新写了某个Util工具类，他们会同时在test目录下，给该工具类编写一些单元测试代码。
很多小伙伴觉得写单元测试是浪费时间，没有这个必要。
假如你想重构某个工具类，但由于这个工具类有很多逻辑，要把这些逻辑重新测试一遍，要花费不少时间。
于是，你产生了放弃重构的想法。
但如果你之前给该工具类编写了完整的单元测试，重构完成之后，重新执行一下之前的单元测试，就知道重构的结果是否满足预期，这样能够减少很多的测试时间。
多写单元测试对开发来说，是一个非常好的习惯，有助于提升代码质量。
即使因为当初开发时间比较紧，没时间写单元测试，也建议在后面空闲的时间内，把单元测试补上。
好的代码不是一下子就能写成的，需要不断地重构，修复发现的bug。
不知道你有没有这种体会，看自己1年之前写的代码，简直不忍直视。
这说明你对业务或者技术的理解，比之前更深入了，认知水平有一定的提升。
如果有机会，建议你主动重构一下自己的烂代码。把重复的代码，抽取成公共方法。有些参数名称，或者方法名称当时没有取好的，可以及时修改一下。对于逻辑不清晰的代码，重新梳理一下业务逻辑。看看代码中能不能引入一些设计模式，让代码变得更优雅等等。
通过代码重构的过程，以自我为驱动，能够不断提升我们编写代码的水平。
有些公司在系统上线之前，会组织一次代码评审，一起review一下这个迭代要上线的一些代码。
通过相互的代码review，可以发现一些代码的漏洞，不好的写法，发现自己写代码的坏毛病，让自己能够快速提升。
当然如果你们公司没有建立代码的相互review机制，也没关系。
可以后面可以多自己review自己的代码。
我们在写完查询SQL语句之后，有个好习惯是用explain关键字查看一下该SQL语句有没有走索引。
对于数据量比较大的表，走了索引和没有走索引，SQL语句的执行时间可能会相差上百倍。
我之前亲身经历过这种差距。
因此建议大家多用explain查看SQL语句的执行计划。
关于explain关键字的用法，如果你想进一步了解，可以看看我的另外一篇文章《explain | 索引优化的这把绝世好剑，你真的会用吗？》，里面有详细的介绍。
在系统上线之前，一定要整理上线的清单，即我们说的：checklist。
系统上线有可能是一件很复杂的事情，涉及的东西可能会比较多。
假如服务A依赖服务B，服务B又依赖服务C。这样的话，服务发版的顺序是：CBA，如果顺序不对，可能会出现问题。
有时候新功能上线时，需要提前执行sql脚本初始化数据，否则新功能有问题。
要先配置定时任务。
上线之前，要在apollo中增加一些配置。
上线完成之后，需要增加相应的菜单，给指定用户或者角色分配权限。
等等。
系统上线，整个过程中，可能会涉及多方面的事情，我们需要将这些事情记录到checklist当中，避免踩坑。
j9九游会老哥俱乐部app接口文档对接口提供者，和接口调用者来说，都非常重要。
如果你没有接口文档，别人咋知道你接口的地址是什么，接口参数是什么，请求方式时什么，接口多个参数分别代码什么含义，返回值有哪些字段等等。
他们不知道，必定会多次问你，无形当中，增加了很多沟通的成本。
如果你的接口文档写的不好，写得别人看不懂，接口文档有很多错误，比如：输入参数的枚举值，跟实际情况不一样。
这样不光把自己坑了，也会把别人坑惨。
因此，写接口文档一定要写好，尽量不要马马虎虎应付差事。
如果对写接口文档比较感兴趣，可以看看我的另一篇文章《瞧瞧别人家的API接口，那叫一个优雅》，里面有详细的介绍。
我们在设计接口的时候，要跟业务方或者产品经理确认一下请求量。
假如你的接口只能承受100qps，但实际上产生了1000qps。
这样你的接口，很有可能会承受不住这么大的压力，而直接挂掉。
我们需要对接口做压力测试，预估接口的请求量，需要部署多少个服务器节点。
压力测试的话，可以用jmeter、loadRunner等工具。
此外，还需要对接口做限流，防止别人恶意调用你的接口，导致服务器压力过大。
限流的话，可以基于用户id、ip地址、接口地址等多个维度同时做限制。
可以在nginx层，或者网关层做限流。
我们在设计接口时，一定要考虑并发调用的情况。
比如：用户在前端页面，非常快的点击了两次保存按钮，这样就会在极短的时间内调用你两次接口。
如果不做幂等性设计，在数据库中可能会产生两条重复的数据。
还有一种情况时，业务方调用你这边的接口，该接口发生了超时，它有自动重试机制，也可能会让你这边产生重复的数据。
因此，在做接口设计时，要做幂等设计。
当然幂等设计的方案有很多，感兴趣的小伙伴可以看看我的另一篇文章《高并发下如何保证接口的幂等性？》。
如果接口并发量不太大，推荐大家使用在表中加唯一索引的方案，更加简单。
有时候我们提供的接口，需要调整参数。
比如：新增加了一个参数，或者参数类型从int改成String，或者参数名称有status改成auditStatus，参数由单个id改成批量的idList等等。
建议涉及到接口参数修改一定要慎重。
修改接口参数之前，一定要先评估调用端和影响范围，不要自己偷偷修改。如果出问题了，调用方后面肯定要骂娘。
我们在做接口参数调整时，要做一些兼容性的考虑。
其实删除参数和修改参数名称是一个问题，都会导致那个参数接收不到数据。
因此，尽量避免删除参数和修改参数名。
对于修改参数名称的情况，我们可以增加一个新参数，来接收数据，老的数据还是保留，代码中做兼容处理。
我们在调用第三方接口时，由于存在远程调用，可能会出现接口超时的问题。
如果接口超时了，你不知道是执行成功，还是执行失败了。
这时你可以增加自动重试机制。
接口超时会抛一个connection_timeout或者read_timeout的异常，你可以捕获这个异常，用一个while循环自动重试3次。
这样就能尽可能减少调用第三方接口失败的情况。
当然调用第三方接口还有很多其他的坑，感兴趣的小伙伴可以看看我的另一篇文章《我调用第三方接口遇到的13大坑》，里面有详细的介绍。
有时候，线上数据出现了问题，我们需要修复数据，但涉及的数据有点多。
这时建议在处理线上数据前，一定要先备份数据。
备份数据非常简单，可以执行以下sql：