为什么那么多程序员需要天天加班来完成任务呢？这两年从互联网公司离开后，去了企业搞ERP。最大的感受就是，互联网是搞智力的，ERP是搞体力的，码农这词估计就是从这些ERP从业者身上出来的吧。

大部分IT从业者往往注重技术而不注重设计，其实设计比技术要重要多了。我以前写代码从来不会出现nullPointException这个异常的，而且我很少判断对象是否为null，因为我们代码有规定，只有javaBean才能返回null，String必须是空字符串，Number使用0来表示，List为空数组，数据库默认值不能为Null(这个非常重要，很多菜鸟根本不懂数据库设计，反正什么都设置一个默认值Null，造成了大量的null判断)，与前端数据交互使用json，通过改写Jackson的StringDeserialize类，把返回的null字符串改为空字符串，非空的使用trim后返回。所以我们平时使用字符串的时候，压根不需要判断什么null，这得节省多少代码量？避免多少坑？

还有比较多的菜鸟喜欢使用诺依框架，那框架就是祸害人的，毫无设计可言，毒害了多少人，多少项目。这诺依凭一己之力把摧毁了rest的设计规范，摧毁了JWT的设计初衷和应用场景，使得网上一堆人说Java开发很臃肿。诺依的设计是，无论什么结果都会返回http状态码200和一个json，json里面又有一个code的字段和message字段，例如{"code":200,"message":"修改成功"}。而我的设计是没异常仅仅返回http状态码200。有异常则返回状态码400和json错误提示{"message":"修改失败:数据库连接失败"}，注意我说的状态码是指http状态码，而不是诺依的那个code字段的值。这个才是标准的rest设计规范，可以节省没必要的字符和流量。

JWT的应用场景其实是跨域，垮项目使用的，例如a.qq.com，想要访问b.qq.com的一张图片c.jpg，这张图片属于用户d的。a.qq.com跟b.qq.com是使用不同的数据库和redis的。b.qq.com只保存的图片c.jpg属于用户d这点信息，没有任何用户d的登录信息，那怎么办呢？这时候就需要使用JWT，b.qq.com只需要验证JWT的签名，就可以把图片返回了。而诺依则是选择了脱裤子放屁的设计方式，第一步验证了JWT，第二步从redis获取用户信息。这样的设计跟我直接使用token或者session有什么区别，为什么需要第一步？简直就是浪费cpu跟内存，他可能还没有搞懂什么是数字签名吧。

很多菜鸟使用了诺依框架后就知道缓存就肯定是使用redis，他们可能还不知道什么叫本地缓存吧，一个单体应用都使用redis，搞得程序不但慢，还浪费服务器。

还有csdn上面的druid的配置描述都是错的，误人子弟，改天再写篇文章吐槽一下。大家关注一下我，一起讨论程序设计，而不是程序技术，也可以一起分享一下那些恶心的设计