程序员版本的八荣八耻~

点击上方“芋道源码”，选择“设为星标”

管她前浪，还是后浪？

能浪的浪，才是好浪！

每天 10:33 更新文章，每天掉亿点点头发...

源码精品专栏

• 原创 | Java 2021 超神之路，很肝~
  

• 中文详细注释的开源项目
  

• RPC 框架 Dubbo 源码解析

• 网络应用框架 Netty 源码解析
  

• 消息中间件 RocketMQ 源码解析
  

• 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析

• 作业调度中间件 Elastic-Job 源码解析

• 分布式事务中间件 TCC-Transaction 源码解析

• Eureka 和 Hystrix 源码解析

• Java 并发源码

• 前言

• 1. 以接口兼容为荣，以接口裸奔为耻

• 2. 以规范日志为荣，以乱打日志为耻

• 3. 以代码自测为荣，以过度自信为耻

• 4. 以参数校验为荣，以运行异常为耻

• 5. 以设计模式为荣，以代码重复为耻

• 6. 以优化代码为荣，以复制粘贴为耻

• 7. 以定义常量为荣，以魔法数字为耻

• 8. 以总结思考为荣，以混水摸鱼为耻。

前言

大家好，最近整理了一个关于程序员日常开发版本的八荣八耻，还挺有意思的。给大家分享一下，哈哈~

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能。

项目地址：https://github.com/YunaiV/ruoyi-vue-pro

1. 以接口兼容为荣，以接口裸奔为耻

以接口兼容 为荣，怎么理解呢？

很多bug都是因为修改了对外旧接口 ，但是却不做兼容 导致的。关键这个问题多数是比较严重的，可能直接导致系统发版失败的。新手程序员很容易犯这个错误。所以我们修改老接口的时候，一般要做好兼容 。

如果你的需求是在原来接口上修改，尤其这个接口是对外提供服务的话，一定要考虑接口兼容。举个例子吧，比如dubbo接口，原本是只接收A，B参数，现在你加了一个参数C，就可以考虑这样处理：

//老接口
void oldService(A,B){
  //兼容新接口，传个null代替C
  newService(A,B,null);
}

//新接口，暂时不能删掉老接口，需要做兼容。
void newService(A,B,C){
  ...
}

我们还要以接口裸奔 为耻。为了保证接口报文的安全性，拒绝接口报文裸奔。因此，我们可以使用https协议，还建议对接口加签验签处理，数据加密等。

接口签名很简单，就是把接口请求相关信息（请求报文，包括请求时间戳、版本号、appid等） ，客户端私钥加签，然后服务端用公钥验签，验证通过才认为是合法的、没有被中间人篡改过的请求。

基于微服务的思想，构建在 B2C 电商场景下的项目实战。核心技术栈，是 Spring Boot + Dubbo 。未来，会重构成 Spring Cloud Alibaba 。

项目地址：https://github.com/YunaiV/onemall

2. 以规范日志为荣，以乱打日志为耻

我们的业务逻辑代码需要日志保驾护航 。比如：你实现转账业务，转个几百万，然后转失败了，接着客户投诉，然后你还没有打印到日志，想想那种水深火热的困境下，你却毫无办法。。。

因此大家要打好日志，比如日志级别使用恰当，日志格式，在哪些地方打日志，参数打印哪个 等等。不能乱打日志，要以规范日志为荣，乱打日志为耻。

3. 以代码自测为荣，以过度自信为耻

修改完代码，要自测一下，这个是每个程序必备的素养，即使你只是修改了一个变量或者一个字段。

要杜绝过度自信，尤其不要抱有这种侥幸心理：我只是改了一个变量或者我只改了一行配置的代码，不用自测了，怎么可能有问题 。

因此，我们要以代码自测为荣，以过度自信为耻 。

4. 以参数校验为荣，以运行异常为耻

参数校验是每个程序员必备的基本素养。你的方法处理，必须先校验参数。比如入参是否允许为空，入参长度是否符合你的预期长度。因此，我们要以参数校验为荣 。

比如你的数据库表字段设置为varchar(16),对方传了一个32位的字符串过来，如果你不校验参数，插入数据库直接异常了。

我们要以运行时异常为耻 。

比如你没有做好一些非空校验，数组边界校验等等，导致的空指针异常、数组边界异常，尤其这些运行时异常还发生在生产环境 的话，在有经验的程序员看来，这些错误行为会显得特别低级。

所以，我们要以参数校验为荣，以运行异常为耻 。

5. 以设计模式为荣，以代码重复为耻

日常工作中，我们要以设计模式为荣。

比如策略模式、工厂模式、模板方法模式、观察者模式、单例模式、责任链模式 等等，都是很常用的。在恰当的业务场景，我们还是把设计模式用上吧。设计模式可以让我们的代码更优雅、更具有扩展性。但是不要过度设计哈，不要硬套设计模式。

我们还要以重复代码为耻 。重复代码，我相信每个程序员都讨厌的，尤其有时候你的开发工具还会给你提示出来。我们可以抽取公共方法，抽取公用变量、扩展继承类 等方式去消除重复代码。

6. 以优化代码为荣，以复制粘贴为耻

日常开发中，很多程序员在实现某个功能时，如果看到老代码有类似的功能，他们很喜欢复制粘贴过来。这样很容易产生重复代码，所以我们要以复制粘贴为耻。一般建议加自己的思考，怎么优化这部分代码，怎么抽取公用方法，用什么设计模式等等。

个人觉得，优化代码的过程，可以让自己取得更大的进步。因此我们要以优化代码为荣，以复制粘贴为耻。

7. 以定义常量为荣，以魔法数字为耻

大家平时工作中，是不是经常看到魔法数字。魔法数字（Magic Number）是指拥有特殊意义，却又不能明确表现出这种意义的数字。程序里面存在魔法数字，易读性很差，且非常难以维护。

如下：

if(type==1){
   System.out.println("关注公众号：芋道源码");
}else if(type==2){
   System.out.println("关注公众号：程序员芋艿");
}else{
   System.out.println("关注其他公众号");
}

代码中的1、2就表示魔法数字，我们可以用常量取代魔法数 ，或者定义枚举 去代替魔法数字哈。

8. 以总结思考为荣，以混水摸鱼为耻。

我们要以总结思考为荣。

比如你看完田螺哥的文章，可以总结思考一下，或者做做笔记，或者放到收藏夹，茶余饭后再看看。再比如你日常工作中，看到一段不错的代码，也可以思考一下亮点在哪里，如果是你自己来写的话，怎么写出更好的代码。反正就是要多总结，多思考，多复习，温故而知新 嘛。

我们要以混水摸鱼为耻。比如工作中，一些小伙伴喜欢混水摸鱼，当一天和尚敲一天钟，代码多是复制粘贴，做完需求就摸鱼。实际上这个不可取的。

我们要在工作中成长，通过认真工作，使自己会得更多，将来换工作也可以拿到更高的薪水，对吧，加油吧,小伙子，以总结思考为荣，以混水摸鱼为耻 。

欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：

已在知识星球更新源码解析如下：

最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。

提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。

获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。

文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）