以接口兼容为荣,以接口裸奔为耻
很多bug都是因为修改了对外旧接口
,但是却不做兼容 导致的
。关键这个问题多数是比较严重
的,可能直接导致系统发版失败
的。新手程序员很容易犯这个错误。所以我们修改老接口的时候,一般要做好兼容
。
如果你的需求是在原来接口上修改,尤其这个接口是对外提供服务
的话,一定要考虑接口兼容
。举个例子吧,比如dubbo
接口,原本是只接收A,B参数
,现在你加了一个参数C
,就可以考虑这样处理:
//老接口
void oldService(A,B){
//兼容新接口,传个null代替C
newService(A,B,null);
}
//新接口,暂时不能删掉老接口,需要做兼容。
void newService(A,B,C){
...
}
还要以接口裸奔 为耻
。为了保证接口报文的安全性
,拒绝接口报文裸奔。因此,可以使用https协议
,还建议对接口加签验签
处理,数据加密
等。
接口签名
很简单,就是把接口请求相关信息(请求报文,包括请求时间戳、版本号、appid等)
,客户端
私钥加签
,然后服务端用公钥验签
,验证通过
才认为是合法的、没有被中间人篡改过的请求
。
以规范日志为荣,以乱打日志为耻
业务逻辑代码
需要日志保驾护航
。比如:你实现转账业务,转个几百万,然后转失败了,接着客户投诉,然后你还没有打印到日志,想想那种水深火热的困境下,你却毫无办法。。。
因此大家要打好日志
,比如日志级别使用恰当,日志格式
,在哪些地方打日志,参数打印哪个
等等。
不能乱打日志
,要以规范日志为荣,乱打日志为耻。
以代码自测为荣,以过度自信为耻
修改完代码,要自测一下
,这个是每个程序必备的素养
,即使你只是修改了一个变量或者一个字段
要杜绝过度自信
,尤其不要抱有这种侥幸心理
:我只是改了一个变量或者我只改了一行配置的代码,不用自测了,怎么可能有问题 。
以参数校验为荣,以运行异常为耻
参数校验
是每个程序员必备的基本素养
。你的方法处理
,必须先校验参数
。比如入参是否允许为空,入参长度是否符合你的预期长度
。因此,我们要以参数校验为荣 。
比如你的数据库表字段设置为varchar(16),对方传了一个32位的字符串过来
如果你不校验参数,插入数据库直接异常了。
以运行时异常
为耻 。
比如没有做好一些非空校验
,数组边界校验
等等,导致的空指针异常、数组边界异常
,尤其这些运行时异常还发生在生产环境 的
话,在有经验的程序员看来,这些错误行为会显得特别低级
以设计模式为荣,以代码重复为耻
比如策略模式、工厂模式、模板方法模式、观察者模式、单例模式、责任链模式
等等,都是很常用
的。在恰当的业务场景,还是把设计模式用上吧。设计模式可以让代码更优雅、更具有扩展性
。但是不要过度设计
哈,不要硬套设计模式。
还要以重复代码为耻
。重复代码,相信每个程序员都讨厌的,尤其有时候你的开发工具还会给你提示出来。可以抽取公共方法
,抽取公用变量、扩展继承类
等方式去消除重复代码
。
以优化代码为荣,以复制粘贴为耻
日常开发中,很多程序员在实现某个功能时,如果看到老代码有类似的功能,他们很喜欢复制粘贴过来。这样很容易产生重复代码,所以我们要以复制粘贴为耻。一般建议加自己的思考
,怎么优化这部分代码
,怎么抽取公用方法,用什么设计模式
等等。
以定义常量为荣,以魔法数字为耻
大家平时工作中,是不是经常看到魔法数字。魔法数字
(Magic Number)是指拥有特殊意义
,却又不能明确表现出这种意义的数字
。程序里面存在魔法数字,易读性很差
,且非常难以维护
if(type==1){
System.out.println("关注公众号:芋道源码");
}else if(type==2){
System.out.println("关注公众号:程序员芋艿");
}else{
System.out.println("关注其他公众号");
}
代码中的1、2就表示魔法数字,我们可以用常量取代魔法数 ,或者定义枚举 去代替魔法数字
以总结思考为荣,以混水摸鱼为耻
比如看完的文章,可以总结思考一下
,或者做做笔记
,或者放到收藏夹,茶余饭后再看看。再比如你日常工作中,看到一段不错的代码,也可以思考一下亮点在哪里
,如果是你自己来写的话,怎么写出更好的代码。反正就是要多总结,多思考,多复习,温故而知新
我们要以混水摸鱼为耻。比如工作中,一些小伙伴喜欢混水摸鱼,当一天和尚敲一天钟,代码多是复制粘贴,做完需求就摸鱼。实际上这个不可取的。