日常开发小小技巧

为了方便大家对异步通知返回参数的处理，对该验签功能进行统一封装，到时候大家只需要关注自己的业务逻辑即可。

内外网接口微服务隔离 将对外暴露的接口和对内暴露的接口分别放到两个微服务上，一个服务里所有的接口均对外暴露，另一个服务的接口只能内网服务间调用

最近在优化接口的响应时间，优化了代码之后，但是时间还是达不到要求；有一个诡异的100ms左右的耗时问题，在接口中打印了请求处理时间后，和调用方的响应时间还有差了100ms左右。比如程序里记录150ms

日常开发中，我们很多时候需要用到Java 8的java stream 流式数据处理，它允许把函数作为一个方法的参数，让我们的代码更优雅、更简洁。所以整理了一波工作中，我常用的，有哪些Stream`流式

在日常开发中，我们对一些代码的调用或者工具的使用会存在多种选择方式，在不确定他们性能的时候，我们首先想要做的就是去测量它。大多数时候，我们会简单的采用多次计数的方式来测量，来看这个方法的总耗时

xxl-job是一款非常优秀的任务调度中间件，轻量级、使用简单、支持分布式等优点，让它广泛应用在我们的项目中，解决了不少定时任务的调度问题

不知道大家有没有经历过维护一个已经离职的人的代码的痛苦，一个方法写老长，还有很多的if else ，根本无法阅读，更不知道代码背后的含义，最重要的是没有人可以问，此时只能心里默默地问候这个留坑的兄弟。

优雅的代码，犹如亭亭玉立的美女，让人赏心悦目。而糟糕的代码，却犹如屎山，让人避而远之。 如何写出优雅的代码呢？那就要理解并熟悉应用这6个设计原则啦：开闭原则、单一职责原则、接口隔离原则 、迪米特法则等

案例场景 假设银行提供了一些 API 接口，对参数的序列化有点特殊，不使用 JSON，而是需要我们把参数依次拼在一起构成一个大字符串按照银行提供的API文档顺序，将所有的参数构成定长的数据

想起刚开始接触JAVA面向对象编程时，若遇到大量流程判断语句，几乎满屏都是if-else语句，多得让自己都忘了哪里是头，哪里是尾，但是，纵然满屏是if-else，但彼时也没有觉得多别扭。

BeanUtils.copyProperties();确实为我们做了很多事情，虽然不能完美完成深拷贝，但是对于 po、vo、dto 的拷贝已经足够用了。可还是有一些不够完美的地方。

整洁的代码 来让我们思考一个问题，什么样的代码才算是好代码？ 关于这一点我大概整理了一些自己的看法。

前后端的工作职责越来越明确，现在的前端都称之为大前端，技术栈以及生态圈都已经非常成熟；以前后端人员瞧不起前端人员，那现在后端人员要重新认识一下前端，前端已经很成体系了。

在我们日常开发的程序中，为了各层之间解耦，一般会定义不同的对象用来在不同层之间传递数据，比如xxxDTO、xxxVO、xxxQO，当在不同层之间传输数据时，不可避免地经常需要将这些对象进行相互转

说到 Controller，相信大家都不陌生，它可以很方便地对外提供数据接口。它的定位，我认为是「不可或缺的配角」，说它不可或缺是因为无论是传统的三层架构还是现在的COLA架构

人们在围绕软件开发的讨论中，几乎不可避免会随口引用一两条原则。 你可能听过人们说：“这行不通，因为‘X法则’！”。或者“你不知道‘Y原则’吗？”你是哪种类型的软件开发人员？

将相似或重复请求在上游系统中合并后发往下游系统，可以大大降低下游系统的负载，提升系统整体吞吐率。文章介绍了三种请求合并技术，并通过其具体实现对比各自适用的场景。

这次给大家分享一些特别重要的设计原则，旨在用于提高代码质量。写出一手好的代码，能够实现高内聚，低耦合，易维护，易扩展

基本上每个程序员都会写代码，但写代码的速度不尽相同。 为什么有些人，一天只能写几百行代码？ 而有些人，一天可以写几千行代码？ 有没有办法，可以提升开发效率，在相同的时间内，写出更多的代码呢？

Java8 新增的 Stream 流大大减轻了我们代码的工作量，但是 Stream 流的用法较多，实际使用的时候容易遗忘，整理一下常用的方法供大家参考。