系统模块划分设计的思考

前言

首先明确一下，这里所说的系统模块划分，是针对client，service，common这样的技术划分，而不是针对具体业务的模块划分。避免由于歧义，造成你的时间浪费。

直接原因

公司内部某技术团队，在引用我们系统的client包时，启动失败。
失败原因是由于client下有一个cache相关的依赖，其注入失败导致的。

然后，就发出了这样一个疑问：我只是希望使用一个hsf接口，为什么还要引入诸如缓存，web处理工具等不相关的东西。

这也就自然地引出了前辈对我的一句教导：对外的client需要尽可能地轻便。

很明显，我们原有的client太重了，包含了对外的RPC接口，相关模型（如xxxDTO），工具包等等。

可能有人就要提出，直接RPC+模型一个包，其它内容一个包不就OK了嘛？

问题真的就这么简单嘛？

根本原因

其实出现上述问题，是因为在系统设计之初，并没有深入思考client包的定位，以及日后可能遇到的情况。

这也就导致了今天这样的局面，所幸目前的外部引用并不多，更多是内部引用。及时调整，推广新的依赖，与相关规范为时不晚。

常见模块拆分

先说说我以前的模块拆分。最早的拆分是每个业务模块主要拆分为：

• xxx-service：具体业务实现模块。

• xxx-client：对外提供的RPC接口模块。

• xxx-common：对外的工具，以及模型。

这种拆分方式，是我早期从一份微服务教程中看到的。优点是简单明了，调用方可选择性地选择需要的模块引入。

至于一些通用的组件，如统一返回格式（如ServerResponse，RtObject），则放在了最早的核心（功能核心，但内容很少）模块上。

后来，认为这样并不合适，不应该将通用组件放在一个业务模块上。所以建立了一个base模块，用来将通用的组件，如工具，统一返回格式等都放入其中。

另外，将每个服务都有的xxx-common模块给取消了。将其中的模型，放入了xxx-client，毕竟是外部调用需要的。将其中的工具，根据需要进行拆分：

• base：多个服务都会使用的。

• xxx-service：只有这个服务本身使用

• xxx-client：有限的服务使用，并且往往是服务提供方和服务调用方都要使用。但是往往这种情况，大多是由于接口设计存在问题导致的。所以多为过渡方案。

上述这个方案，也就是我在负责某物联网项目时采用的最终模块划分方式。

在当时的业务下，该方案的优点是模块清晰，较为简洁，并且尽可能满足了迪米特原则（可以参考《阿里Java开发手册相关实践》）。缺点则是需要一定的技术水平，对组件的功能域认识清晰。并且需要有一定的设计思考与能力（如上述工具拆分的第三点-xxx-client，明白为什么这是设计缺陷导致，并能够解决）。

新的问题

那么，既然上述的方案挺不错的，为什么不复用到现在的项目呢？

因为业务变了，导致应用场景变了。而这也带来了新的问题，新的考虑角度。

原先的物联网业务规模并不大，所以依赖也较为简单，也并不需要进行依赖的封装等，所以针对主要是client的内/外这一维度考虑的。

但是现有的业务场景，由于规模较大，模块依赖层级较多，导致上层模块引入过多的依赖。如有一个缓存模块，依赖tair-starter（一个封装的key-value的存储），然后日志模块依赖该缓存模块（进行性能优化），紧接着日志模块作为一个通用模块，被放入了common模块中。依赖链路如下：

调用方 -> common模块 -> 日志模块 -> 缓存模块 -> tair-starter依赖

但是有的调用方表示，根本就不需要日志模块，却引入了tair-starter这一重依赖（starter作为封装，都比较重），甚至由于tair-starter的内部依赖与自身原有依赖冲突，得去排查依赖，进行exclude。
但是同时，也有的调用方，系统通过rich客户端，达到性能优化等目标。

所以，现有的业务场景除了需要考虑client的内/外这一维度，还需要考虑client的pool/rich这一维度。

可能有的小伙伴，看到这里有点晕乎乎的，这两个维度考量的核心在哪里？

内/外，考虑的是按照内外这条线，尽量将client设计得简洁，避免给调用方引入无用依赖。

而pool/rich，考虑的是性能，用户的使用成本（是否开箱即用）等。

最终解决方案

最终的解决方案是对外提供3+n

• xxx-client（1个）：所有外部系统引用都需要的内容，如统一返回格式等。

• xxx-yyy-client（n个）：对具体业务依赖的引用，进行了二次拆分。如xxx-order-client（这里是用订单提花那你一下，大家理解意思就OK）。

• xxx-pool-client（1个）：系统引用所需要的基本依赖，如Lindorm的依赖等。

• xxx-rich-client（1个）：系统引用所需要的依赖与对应starter，如一些自定义的自动装载starter（不需要用户进行配置）。

这个方案，换个思路，理解也简单。
我们提供相关的能力，具体如何选择，交给调用方决定。

其实，讨论中还提到了BOM方案（通过DependentManagement进行jar包版本管理）。不过分析后，我们认为BOM方案更适合那些依赖集比较稳定的client，如一些中间件。而我们目前的业务系统，还在快速发展，所以并不适用。

总结

简单来说，直接从用户需求考虑（这里的用户就是调用方）：

• 外部依赖：

  • 额外引入的依赖尽可能地少，最好只引入二方依赖（我们提供的jar），不引入第三方依赖。

  • 引入的二方依赖不“夹带”私货（如二方jar引入了一堆大第三方依赖）。

• 自动配置：

  • 可以傻瓜式使用。如引入对应的starter依赖，就可以自动装配对应默认配置。

  • 也可以自定义配置。用户可以在自定义配置，并不用引入无效的配置（因为starter经常引入不需要的依赖）。

• 性能：

  • 可以通过starter，提供一定的封装，保证一定的性能（如接口缓存，请求合并等）。

  • 可以自定义实现基础功能。因为有些人并不放心功能封装（虽然只是少数，但是稳定性前辈提出的）。

补充

这里补充一点，我对讨论中一个问题的回答，这里提一下。

有人提到工具类，应该如何划分。因为有的工具类，是不依赖于服务状态的，如CookieUtil进行Cookie处理。有的工具类，是依赖于服务状态的，如RedisUtil包含RedisPool状态，直连Redis，处理Redis请求与响应。

其实这里有两个细节：

• 工具应该按照上面的方式进行划分为两种。单一模块系统，不依赖服务状态的工具往往置于util包，依赖服务状态的工具往往置于common包中。这里还有一个明显的区分点：前者的方法可以设为static，而后者并不能（因为依赖于new出来的状态）。

• 依赖于状态的工具类，其实是一种拆分不完全的体现。如RedisUtil，可以拆分为连接状态管理的RedisPool与请求响应处理的RedisUitl。两者的组合方式有很多，取决于使用者的需要，以后有机会写一篇相关的博客。不过，我希望大家记住 面向接口编程的原则。

愿与诸君共进步。

原文链接：https://blog.csdn.net/cureking/article/details/105663951

周四晚上的时候，看到消息说4月9日起要采用新的核酸检查系统，要推出一个新的码，叫：核酸码。

当晚就有很多网友发现随申办上已经有入口了，但点进去是报错的：

但是因为还没投入真正使用，所以也没啥大的反馈，大家就瞎讨论了技术栈和这个错误可能的原因啥的。

我也顺带瞎扯了一句：可能会出性能问题（因为我一直觉得国内擅长Hibernate的开发者比较少）。

谁想到，今天在获取核酸码的时候真的碰到各种困难，在获取核酸码的时候，就一直刷不出来，有时候显示人多，有时候504错误：

上面我是12点尝试的，后来16、17点还看到很多朋友圈反应各种卡住，刷不出来。

可能这个系统确实太赶了，所以没做好？不过这个谁知道呢？作为一名技术博主就不瞎猜了。

顺手分享一下为什么我觉得用spring data jpa，很可能会挂？

先说说常规国内用的比较多的技术MyBatis，因为大家都是用直接写SQL的方式来实现数据读写的，这个时候团队里DBA、数据库专家、或者实力强点的开发，往往自己已经能够把SQL执行优化到比较好的地步了。这个是否能做好，与我们对SQL、Java这些知识的掌握程度有关

而当我们用Spring Data JPA这样的框架时候，开发者在框架的帮助下，好多SQL都被隐藏了，喜欢些Java代码来替代SQL的开发过程是挺爽的，但也因为这个原因，他可能并不知道最终自己写的代码真正会执行的SQL具体是怎么样的。

这的时候对于优化就带了很大的难度，对于专业DBA来说，他一般都是不具备Spring Data JPA代码到SQL转化的认识，他是很难帮你做静态分析的。而开发者一侧也有这个问题，如果不是很熟悉Hibernate的话，就很容易写出低性能的代码（不代表框架实现的低性能，核心还是使用姿势的问题）。

所以，我一直建议在高并发系统中对数据访问框架的选型一定要慎重，不是说Spring Data JPA不行，而是需要有熟悉的人来把握（特别提这点的原因是国好多是半调子）。不然就比较容易出现性能问题，但是MyBatis的话，对于国内开发者来说，因为直接写SQL，所以还是相对还是更容易理解和把控一些。

好了，借今天核酸码的现象，跟大家聊聊这两个框架的想法，不知道你是否认同？欢迎留言区说说你的观点。

来源：https://mp.weixin.qq.com/s/43bE8juIRQbQLO3vBTUKWA

前言

有一本书叫《代码整洁之道》，不知你看过没？

初次听闻此书，并未激发我的阅读欲。再次听闻，不免心想：代码竟还整洁之道？我倒要瞧瞧，怎么个整洁法。

我是怀着试探地心看了这本书，结果收获了满脑子糟糕的代码。天呐！这代码我貌似一句也看不懂，幸好还有文字，尚可宽慰我这颗被代码撞乱的心，于是咬咬牙读了下去。

这本书里面讲了很多代码整洁之道，关于有意义的命名、函数、注释、格式、错误处理、边界等共十七大篇章。如果你感兴趣，可以去看看。我只是粗略地看了一下，因为有些我也看不大明白。特别是当某些代码脱离了计算机而存在的时候，我好像不认识它们了，它们变得异常陌生。恕我我孤陋寡闻了，哎。

尽管如此，此书第四章中，关于“注释”的代码整洁之道，却给我留下了异常深刻的印象。Why? 因为里面关于注释的观点刷新了我的认知，与我的思想产生了一点点灵魂的碰撞，并且说服了我，还驱动我写下了这篇文章。

一、被注释吸引

下面是“注释”篇章的开头两段，特意贴了上来，因为我就是被这样的开头吸引了。希望它能带给你一点点启发。

不知你读完以上两段，作何感想？

我的感想是：如果你的代码写得足够优秀，是不需要过多注释的。注释最多可以证明糟糕的代码。

额，此刻我很想找一个捂脸的表情。与此同时，我在脑海里迅速地回忆了一遍注释之于我的心历路程：从最初知道“注释”这么个神奇玩意儿时的欣喜，到步步沦陷“注释”的魔爪，以致如今看着满屏的代码，不写点儿注释都感觉空落落的......

收回来，继续品。 作者开篇的观点约莫如下：

• 注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败

• 如果你发现自己需要写注释，再想想是否有办法翻盘，用代码来表达

• 注释会撒谎，代码在变动演化，但注释不能总是跟着走

• 只有代码是唯一准确的信息来源

注意，作者用来了“失败”一词。你无法找到表达自我的恰当方法，所以就要用注释，这并不值得庆祝。当然，这并不意味作者就完全否定了注释的价值，程序员应当负责将代码保持在可维护、有关联、精确的高度。只不过作者更倾向于把力气用在写清楚代码上，直接保证无须编写注释，或者花心思减少注释量。

二、好的注释

有些注释是必须的，作者列举了一些值得写的注释。

• 公司代码规范要求编写与法律有关的注释

• 提供基本信息的注释

• 对意图的解释

• 阐释：把晦涩难明的参数或返回值的意义翻译为某种可读形式

• 警示：用于警告其他程序员会出现某种后果的注释

• TODO 注释：是一种程序员认为应该做，但由于某些原因目前还没做的工作

• 放大：放大某种看起来不合理之物的重要性的注释

• 公共 API 中的 Javadoc

尽管如此，作者一再强调：唯一真正好的注释是你想办法不去写的注释。足见作者对注释之深恶痛疾，对糟糕代码之嫌弃，对代码整洁要求之高。你可以细品。

三、坏的注释

果然是有代码洁癖的人，作者用了更多的篇幅来描述坏的注释。

• 喃喃自语：因为过程需要就添加注释，就是无谓之举

• 多余的注释：并不比代码本身提供更多的信息，甚至比读代码所花时间长

• 误导性注释：写出不够精确的注释误导读者

• 循规式注释：每个函数都要有 Javadoc 或每个变量都要有注释的规则愚不可及

• 日志式注释：每次编辑代码时，在模块开始处添加一条注释，应当全部删除

• 废话注释：喋喋不休，废话连篇的注释，一旦代码修改，将变成一堆谎言

• 能用函数或变量时就别用注释：建议重构代码，删掉注释

• 位置标记：在源代码中标记某个特别位置，多数实属无理又鸡零狗碎

• 括号后面的注释：如果你发现自己想标记右括号，其实应该做的是缩短函数

• 归属与署名：源代码控制系统是这类信息最好的归属地

• 注释掉的代码：注释掉的代码堆积在一起，就像酒瓶底的渣滓一般

• HTML 注释：源代码注释中的 HTML 标记是一种厌物

• 非本地信息：假如你一定要写注释，请确保它描述了离它最近的代码

• 信息过多：别在注释中添加有趣的历史性话题或无关的细节描述

• 不明显的关系：注释及其描述的代码之间的联系应该显而易见

• 函数头：短函数不需要太多的描述，选个好的函数名胜于写函数头注释

一言以蔽之：用整理代码的决心替代创造废话的冲动吧。 你会发现自己成为更优秀、更快乐的程序员。

小结

作者把“注释”拎出来，说了这么多，最终还是回归到了代码本身。

那如何才能写出整洁的代码呢？如果你不明白整洁对代码的意义，尝试去写整洁代码就毫无意义。如果你明白糟糕的代码给你带来的代价，你就会明白，花时间保持代码整洁不但有关效率，还有关生存。争取让营地比你来时更干净吧！

最后，贴上书中震撼我的一隅，希望它能指引你逐渐走向代码整洁之道，与君共勉！

作者：linwanxia
来源：https://juejin.cn/post/7083029096615116837

大家好，我叫小杜杜，作为一名小前端，只需要好好写代码，至于部署相关的操作，我们通常接触不到，正所谓专业的人干专业的事，我们在工作中并不需要去配置，但这并不代表不需要了解，相信大家都多多少少听过nginx，所以今天就聊聊，还请大家多多支持～

Nginx是什么？

Nginx (engine x) 是一个轻量级、高性能的HTTP和反向代理服务器,同时也是一个通用代理服务器(TCP/UDP/IMAP/POP3/SMTP),最初由俄罗斯人Igor Sysoev编写。

简单的说：

• Nginx是一个拥有高性能HTTP和反向代理服务器，其特点是占用内存少，并发能力强，并且在现实中，nginx的并发能力要比在同类型的网页服务器中表现要好

• Nginx专为性能优化而开发，最重要的要求便是性能，且十分注重效率，有报告nginx能支持高达50000个并发连接数

正向代理和反向代理

Nginx 是一个反向代理服务器，那么反向代理是什么呢？我们先看看什么叫做正向代理

正向代理：局域网中的电脑用户想要直接访问网络是不可行的，只能通过代理服务器（Server）来访问，这种代理服务就被称为正向代理。

就好比我们俩在一块，直接对话即可，但如果我和你分隔两地，我们要想对话，必须借助一个通讯设备（如：电话）来沟通，那么这个通讯设备就是"代理服务器"，这种行为称为“正向代理”

那么反向代理是什么呢？

反向代理：客户端无法感知代理，因为客户端访问网络不需要配置，只要把请求发送到反向代理服务器，由反向代理服务器去选择目标服务器获取数据，然后再返回到客户端，此时反向代理服务器和目标服务器对外就是一个服务器，暴露的是代理服务器地址，隐藏了真实服务器IP地址。

在正向代理中，我向你打电话，你能看到向你打电话的电话号码，由电话号码知道是我给你打的，那么此时我用虚拟电话给你打过去，你看到的不再是我的手机号，而是虚拟号码,你便不知道是我给你打的，这种行为变叫做"反向代理"。

在以上述的例子简单的说下：

• 正向代理：我通过我的手机（proxy Server）去给你打电话，相当于我和我的手机是一个整体，与你的手机（Server）是分开的

• 反向代理：我通过我的手机（proxy Server）通过软件转化为虚拟号码去给你打电话，此时相当于我的手机和你的手机是一个整体，和我是分开的

负载均衡

负载均衡：是高可用网络基础架构的关键组件，通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。

如果没有负载均衡，客户端与服务端的操作通常是：客户端请求服务端，然后服务端去数据库查询数据，将返回的数据带给客户端：

但随着客户端越来越多，数据，访问量飞速增长，这种情况显然无法满足，我们从上图发现，客户端的请求和相应都是通过服务端的，那么我们加大服务端的量，让多个服务端分担，是不是就能解决这个问题了呢？

但此时对于客户端而言，他去访问这个地址就是固定的，才不会去管那个服务端有时间，你只要给我返回出数据就OK了，所以我们就需要一个“管理者“，将这些服务端找个老大过来，客户端直接找老大，再由老大分配谁处理谁的数据，从而减轻服务端的压力，而这个”老大“就是反向代理服务器，而端口号就是这些服务端的工号。

向这样，当有15个请求时，反向代理服务器会平均分配给服务端，也就是各处理5个，这个过程就称之为：负载均衡

动静分离

当客户端发起请求时，正常的情况是这样的：

就好比你去找客服，一般先是先说一大堆官方的话，你问什么，他都会这么说，那么这个就叫静态资源（可以理解为是html，css）

而回答具体的问题时，每个回答都是不同的，而这些不同的就叫做动态资源（会改变，可以理解为是变量）

在未分离的时候，可以理解为每个客服都要先说出官方的话，在打出具体的回答，这无异加大了客服的工作量，所以为了更好的有效利用客服的时间，我们把这些官方的话分离出来，找个机器人，让他代替客服去说，这样就减轻了客服的工作量。

也就是说，我们将动态资源和静态资源分离出来，交给不同的服务器去解析，这样就加快了解析的速度，从而降低由单个服务器的压力

安装 Nginx

关于 nginx 如何安装，这里就不做过多的介绍了，感兴趣的小伙伴看看这篇文章：【Linux】中如何安装nginx

这里让我们看看一些常用的命令：

• 查看版本：./nginx -v

• 启动：./nginx

• 关闭：./nginx -s stop(推荐) 或 ./nginx -s quit

• 重新加载nginx配置：./nginx -s reload

Nginx 的配置文件

配置文件分为三个模块：

• 全局块：从配置文件开始到events块之间，主要是设置一些影响nginx服务器整体运行的配置指令。（按道理说：并发处理服务的配置时，值越大，可支持的并发处理量越多，但此时会受到硬件、软件等设备等的制约）

• events块：影响nginx服务器与用户的网络连接，常用的设置包括是否开启对多workprocess下的网络连接进行序列化，是否允许同时接收多个网络连接等等

• http块：如反向代理和负载均衡都在此配置

location 的匹配规则

共有四种方式：

    location[ = | ~ | ~* | ^~ ] url {
    
    }
复制代码

• = ：精确匹配，用于不含正则表达式的url前，要求字符串与url严格匹配，完全相等时，才能停止向下搜索并处理请求

• ^~：用于不含正则表达式的url前，要求ngin服务器找到表示url和字符串匹配度最高的location后，立即使用此location处理请求，而不再匹配

• ~ ：最佳匹配，用于表示url包含正则表达式，并且区分大小写。

• ~*：与~一样，只是不区分大小写

注意：

• 如果 url 包含正则表达式，则不需要~ 作为开头表示

• nginx的匹配具有优先顺序，一旦匹配上就会立马退出，不再进行向下匹配

End

关于具体的配置可以参考：写给前端的nginx教程

致此，有关Nginx相关的知识就已经完成了，相信对于前段而言已经足够了，喜欢的点个赞👍🏻支持下吧(●￣(ｴ)￣●)

作者：小杜杜
来源：https://juejin.cn/post/7082655545491980301

1.使用缓存行（Cache Line）填充前后对比

伪共享和缓存行填充，我们先看一个例子，让大家感受一下了解底层知识后，你的代码可以快到起飞的感jio： 在类中定义看似无用的成员属性，速度有质的提升。 如下是未使用缓存行（Cache Line）填充方法运行的结果，可以看到耗时是3579毫秒：

而在其变量x的前后加上7个long类型到变量（在变量x前56Byte，后面也是56Byte，这就是缓存行填充，下面章节会详细介绍），当然这个14个变量是不会在代码中被用到的，但是为什么速度会提升将近2倍呢，如下图所示，可以看到耗时为1280毫秒：

ps：上面两个截图中的完整代码见章节5，大家也可以直接跳转到章节去看下完整的代码。

为什么会这么神奇，这里为先提前说下结论，具体的大家可以往后看。

• 缓存一致性是根据缓存行(Cache line)为单元来进行同步的，即缓存中的传输单元为缓存行，一个缓存行大小通常为64Byte;

• 缓存行的内容一发生变化，就需要进行缓存同步;

• 所以虽然用到的不是同一个数据，但是他们（数据X和数据Y）在同一个缓存行中，缓存行的内容一发生变化，就需要进行缓存同步，这个同步是需要时间的。

2.内存、缓存与寄存器之间如何传输数据

为什么会这样呢？前面我们提到过缓存一致性的问题，见笔者该篇博文：“了解高并发底层原理”，面试官：讲一下MESI（缓存一致性协议）吧，点击文字即可跳转。 其中内存、缓存与寄存器之间的关系图大致如下：

硬盘中的可执行文件加载到寄存器中进行运算的过程如下：

1. 硬盘中的可执行文件（底层存储还是二进制的）加载到内存中，操作系统为其分配资源，变成了一个进程A，此时还没有跑起来；

2. 过了一段时间之后，CPU0的时间片分配给了进程A，此时CPU0进行线程的装载，然后把需要用到的数据先从内存中读取到缓存中，读取的单元为一个缓存行，其大小现在通常为64字节（记住这个缓存行大小为64字节，这个非常重要，在后面会多次用到这个数值）。

3. 然后数据再从缓存中读取到寄存器中，目前缓存一般为三级缓存，这里不具体画出。

4. 寄存器得到了数据之后送去ALU（arithmetic and logic unit）做计算。

这里说一下为什么要设计三级缓存：

• 电脑通过使用时钟来同步指令的执行。时钟脉冲在一个固定的频率（称为时钟频率）。当你买了一台1.5GHz的电脑，1.5GHz就是时钟频率，即每秒15亿次的时钟脉冲，一次完整的时钟脉冲称为一个周期（cycle），时钟并不记录分和秒。它以不变的速率简单跳动。

• 其主要原因还是因为CPU方法内存消耗的时间太长了，CPU从各级缓存和内存中读取数据所需时间如下：

3.缓存中数据共享问题（真实共享和伪共享）

3.1 真实共享（不同CPU的寄存器中都到了同一个变量X）

首先我们先说数据的真实共享，如下图，我们在CPU0和CPU1中都用到了数据X，现在不考虑数据Y。

如果不考虑缓存一致性，会出现如下问题： 在多线程情况下，此时由两个cpu同时开始读取了long X =0，然后同时执行如下语句，会出现如下情况：

int X = 0;
X++;

刚开始，X初始化为0，假设有两个线程A，B，

1. A线程在CPU0上进行执行，从主存加载X变量的数值到缓存，然后从缓存中加载到寄存器中，在寄存器中执行X+1操作，得到X的值为1，此时得到X等于1的值还存放在CPU0的缓存中；

2. 由于线程A计算X等于1的值还存放在缓存中，还没有刷新会内存，此时线程B执行在CPU1上，从内存中加载i的值，此时X的值还是0，然后进行X+1操作，得到X的值为1，存到CPU1的缓存中，

3. A，B线程得到的值都是1，在一定的时间周期之后刷新回内存

4. 写回内存后，两次X++操作之后，其值还是1；

可以看到虽然我们做了两次++X操作，但是只进行了一次加1操作，这就是缓存不一致带来的后果。

如何解决该问题：

• 具体的我们可以通过MESI协议（详情见笔者该篇博文：blog.csdn.net/MrYushiwen/…）来保证缓存的一致性，如上图最中间的红字所示，在不同寄存器的缓存中，需要考虑数据的一致性问题，这个需要花费一定的时间来同步数据，从而达到缓存一致性的作用。

3.2伪共享（不同CPU的寄存器中用到了不同的变量，一个用到的是X，一个用到的是Y，并且XY在同一个缓存行中）

• 缓存一致性是根据缓存行(Cache line)为单元来进行同步的，即缓存中的传输单元为缓存行，一个缓存行大小通常为64Byte;

• 缓存行的内容一发生变化，就需要进行缓存同步;

• 在3.1中，我们在寄存器用到的数据是同一个X，他们肯定是在同一个缓存行中的，这个是真实的共享数据的，共享的数据为X。

• 而在3.2中，不同CPU的寄存器中用到了不同的变量，一个用到的是X，一个用到的是Y，但是变量X、Y在同一个缓存行中（一次读取64Byte，见3.1中的图），缓存一致性是根据缓存行为单元来进行同步的，所以虽然用到的不是同一个数据，但是他们（数据X和数据Y）在同一个缓存行中，他们的缓存同步也需要时间。

4.伪共享解决办法（缓存行填充或者使用@Contended注解）

4.1.缓存行填充

如章节一所示，我们可以在x变量前后进行缓存行的填充，：

public volatile long A,B,C,D,E,F,G;
public volatile long x = 1L;
public volatile long a,b,c,d,e,f,g;

添加后，3.2章节中的截图将会变成如下样子：

不论如何进行缓存行的划分，包括x在内的连续64Byte，也就是一个缓存行不可能存在变量Y，同样变量Y所在的缓存行不可能存在x，这样就不存在伪共享的情况，他们之间就不需要考虑缓存一致性问题了，也就节省了这一部分时间。

4.2.Contended注解

在Java 8中，提供了@sun.misc.Contended注解来避免伪共享，原理是在使用此注解的对象或字段的前后各增加128字节大小的padding，使用2倍于大多数硬件缓存行的大小来避免相邻扇区预取导致的伪共享冲突。我们目前的缓存行大小一般为64Byte，这里Contended注解为我们前后加上了128字节绰绰有余。 注意：如果想要@Contended注解起作用，需要在启动时添加JVM参数-XX:-RestrictContended 参数后 @sun.misc.Contended 注解才有。

然而在java11中@Contended注解被归类到模块java.base中的包jdk.internal.vm.annotation中，其中定义了Contended注解类型。笔者用的是java12，其注解如下：

加上该注解，如下，也能达到缓存行填充的效果

5.完整代码（利用缓存行填充和没用缓存行填充）

大家自己也可以跑一下如下代码，看利用缓存行填充后的神奇效果。

5.1没用缓存行填充代码如下：

package mesi;

import java.util.concurrent.CountDownLatch;

/**
 * @Author: YuShiwen
 * @Date: 2022/2/27 2:52 PM
 * @Version: 1.0
 */

public class NoCacheLineFill {

    public volatile long x = 1L;
}

class MainDemo {

    public static void main(String[] args) throws InterruptedException {
        // CountDownLatch是在java1.5被引入的，它是通过一个计数器来实现的，计数器的初始值为线程的数量。
        // 每当一个线程完成了自己的任务后，调用countDown方法，计数器的值就会减1。
        // 当计数器值到达0时，它表示所有的线程已经完成了任务，然后调用await的线程就可以恢复执行任务了。
        CountDownLatch countDownLatch = new CountDownLatch(2);

        NoCacheLineFill[] arr = new NoCacheLineFill[2];
        arr[0] = new NoCacheLineFill();
        arr[1] = new NoCacheLineFill();

        Thread threadA = new Thread(() -> {
            for (long i = 0; i < 1_000_000_000L; i++) {
                arr[0].x = i;
            }
            countDownLatch.countDown();
        }, "ThreadA");

        Thread threadB = new Thread(() -> {
            for (long i = 0; i < 100_000_000L; i++) {
                arr[1].x = i;
            }
            countDownLatch.countDown();
        }, "ThreadB");

        final long start = System.nanoTime();
        threadA.start();
        threadB.start();
        //等待线程A、B执行完毕
        countDownLatch.await();
        final long end = System.nanoTime();
        System.out.println("耗时：" + (end - start) / 1_000_000 + "毫秒");

    }
}

5.2利用缓存行填充代码如下：

package mesi;

import java.util.concurrent.CountDownLatch;

/**
 * @Author: YuShiwen
 * @Date: 2022/2/27 3:45 PM
 * @Version: 1.0
 */

public class UseCacheLineFill {

    public volatile long A, B, C, D, E, F, G;
    public volatile long x = 1L;
    public volatile long a, b, c, d, e, f, g;
}

class MainDemo01 {

    public static void main(String[] args) throws InterruptedException {
        // CountDownLatch是在java1.5被引入的，它是通过一个计数器来实现的，计数器的初始值为线程的数量。
        // 每当一个线程完成了自己的任务后，调用countDown方法，计数器的值就会减1。
        // 当计数器值到达0时，它表示所有的线程已经完成了任务，然后调用await的线程就可以恢复执行任务了。
        CountDownLatch countDownLatch = new CountDownLatch(2);

        UseCacheLineFill[] arr = new UseCacheLineFill[2];
        arr[0] = new UseCacheLineFill();
        arr[1] = new UseCacheLineFill();

        Thread threadA = new Thread(() -> {
            for (long i = 0; i < 1_000_000_000L; i++) {
                arr[0].x = i;
            }
            countDownLatch.countDown();
        }, "ThreadA");

        Thread threadB = new Thread(() -> {
            for (long i = 0; i < 1_000_000_000L; i++) {
                arr[1].x = i;
            }
            countDownLatch.countDown();
        }, "ThreadB");

        final long start = System.nanoTime();
        threadA.start();
        threadB.start();
        //等待线程A、B执行完毕
        countDownLatch.await();
        final long end = System.nanoTime();
        System.out.println("耗时：" + (end - start) / 1_000_000 + "毫秒");

    }
}

作者：YuShiwen
来源：https://juejin.cn/post/7083030159304949767

前言

毕业快三年了，前后也待过几家公司，碰到各种各样的同事。见识过各种各样的代码，优秀的、垃圾的、不堪入目的、看了想跑路的等等，所以这篇文章记录一下一个优秀的后端 Java 开发应该有哪些好的开发习惯。

拆分合理的目录结构

受传统的 MVC 模式影响，传统做法大多是几个固定的文件夹 controller、service、mapper、entity，然后无限制添加，到最后你就会发现一个 service 文件夹下面有几十上百个 Service 类，根本没法分清业务模块。正确的做法是在写 service 上层新建一个 modules 文件夹，在 moudles 文件夹下根据不同业务建立不同的包，在这些包下面写具体的 service、controller、entity、enums 包或者继续拆分。

等以后开发版本迭代，如果某个包可以继续拆领域就继续往下拆，可以很清楚的一览项目业务模块。后续拆微服务也简单。

封装方法形参

当你的方法形参过多时请封装一个对象出来...... 下面是一个反面教材，谁特么教你这样写代码的！

public void updateCustomerDeviceAndInstallInfo(long customerId, String channelKey,
                   String androidId, String imei, String gaId,
                   String gcmPushToken, String instanceId) {}

写个对象出来

public class CustomerDeviceRequest {
    private Long customerId;
    //省略属性......
}

为什么要这么写？比如你这方法是用来查询的，万一以后加个查询条件是不是要修改方法？每次加每次都要改方法参数列表。封装个对象，以后无论加多少查询条件都只需要在对象里面加字段就行。而且关键是看起来代码也很舒服啊！

封装业务逻辑

如果你看过“屎山”你就会有深刻的感触，这特么一个方法能写几千行代码，还无任何规则可言......往往负责的人会说，这个业务太复杂，没有办法改善，实际上这都是懒的借口。不管业务再复杂，我们都能够用合理的设计、封装去提升代码可读性。下面贴两段高级开发（假装自己是高级开发）写的代码

@Transactional
public ChildOrder submit(Long orderId, OrderSubmitRequest.Shop shop) {
    ChildOrder childOrder = this.generateOrder(shop);
    childOrder.setOrderId(orderId);
    //订单来源 APP/微信小程序
    childOrder.setSource(userService.getOrderSource());
    // 校验优惠券
    orderAdjustmentService.validate(shop.getOrderAdjustments());
    // 订单商品
    orderProductService.add(childOrder, shop);
    // 订单附件
    orderAnnexService.add(childOrder.getId(), shop.getOrderAnnexes());
    // 处理订单地址信息
    processAddress(childOrder, shop);
    // 最后插入订单
    childOrderMapper.insert(childOrder);
    this.updateSkuInventory(shop, childOrder);
    // 发送订单创建事件
    applicationEventPublisher.publishEvent(new ChildOrderCreatedEvent(this, shop, childOrder));
    return childOrder;
}
@Transactional
public void clearBills(Long customerId) {
    // 获取清算需要的账单、deposit等信息
    ClearContext context = getClearContext(customerId);
    // 校验金额合法
    checkAmount(context);
    // 判断是否可用优惠券，返回可抵扣金额
    CouponDeductibleResponse deductibleResponse = couponDeducted(context);
    // 清算所有账单
    DepositClearResponse response = clearBills(context);
    // 更新 l_pay_deposit
    lPayDepositService.clear(context.getDeposit(), response);
    // 发送还款对账消息
    repaymentService.sendVerifyBillMessage(customerId, context.getDeposit(), EventName.DEPOSIT_SUCCEED_FLOW_REMINDER);
    // 更新账户余额
    accountService.clear(context, response);
    // 处理清算的优惠券，被用掉或者解绑
    couponService.clear(deductibleResponse);
    // 保存券抵扣记录
    clearCouponDeductService.add(context, deductibleResponse);
}

这段两代码里面其实业务很复杂，内部估计保守干了五万件事情，但是不同水平的人写出来就完全不同，不得不赞一下这个注释，这个业务的拆分和方法的封装。一个大业务里面有多个小业务，不同的业务调用不同的 service 方法即可，后续接手的人即使没有流程图等相关文档也能快速理解这里的业务，而很多初级开发写出来的业务方法就是上一行代码是 A 业务的，下一行代码是 B业务的，在下面一行代码又是 A 业务的，业务调用之间还嵌套这一堆单元逻辑，显得非常混乱，代码还多。

判断集合类型不为空的正确方式

很多人喜欢写这样的代码去判断集合

if (list == null || list.size() == 0) {
  return null;
}

当然你硬要这么写也没什么问题......但是不觉得难受么，现在框架中随便一个 jar 包都有集合工具类，比如 org.springframework.util.CollectionUtils、com.baomidou.mybatisplus.core.toolkit.CollectionUtils 。 以后请这么写

if (CollectionUtils.isEmpty(list) || CollectionUtils.isNotEmpty(list)) {
  return null;
}

集合类型返回值不要 return null

当你的业务方法返回值是集合类型时，请不要返回 null，正确的操作是返回一个空集合。你看 mybatis 的列表查询，如果没查询到元素返回的就是一个空集合，而不是 null。否则调用方得去做 NULL 判断，多数场景下对于对象也是如此。

映射数据库的属性尽量不要用基本类型

我们都知道 int/long 等基本数据类型作为成员变量默认值是 0。现在流行使用 mybatisplus 、mybatis 等 ORM 框架，在进行插入或者更新的时候很容易会带着默认值插入更新到数据库。我特么真想砍了之前的开发，重构的项目里面实体类里面全都是基本数据类型。当场裂开......

封装判断条件

public void method(LoanAppEntity loanAppEntity, long operatorId) {
  if (LoanAppEntity.LoanAppStatus.OVERDUE != loanAppEntity.getStatus()
          && LoanAppEntity.LoanAppStatus.CURRENT != loanAppEntity.getStatus()
          && LoanAppEntity.LoanAppStatus.GRACE_PERIOD != loanAppEntity.getStatus()) {
    //...
    return;
  }

这段代码的可读性很差，这 if 里面谁知道干啥的？我们用面向对象的思想去给 loanApp 这个对象里面封装个方法不就行了么？

public void method(LoanAppEntity loan, long operatorId) {
  if (!loan.finished()) {
    //...
    return;
  }

LoanApp 这个类中封装一个方法，简单来说就是这个逻辑判断细节不该出现在业务方法中。

/**
 * 贷款单是否完成
 */
public boolean finished() {
  return LoanAppEntity.LoanAppStatus.OVERDUE != this.getStatus()
          && LoanAppEntity.LoanAppStatus.CURRENT != this.getStatus()
          && LoanAppEntity.LoanAppStatus.GRACE_PERIOD != this.getStatus();
}

控制方法复杂度

推荐一款 IDEA 插件 CodeMetrics ，它能显示出方法的复杂度，它是对方法中的表达式进行计算，布尔表达式，if/else 分支，循环等。

点击可以查看哪些代码增加了方法的复杂度，可以适当进行参考，毕竟我们通常写的是业务代码，在保证正常工作的前提下最重要的是要让别人能够快速看懂。当你的方法复杂度超过 10 就要考虑是否可以优化了。

使用 @ConfigurationProperties 代替 @Value

之前居然还看到有文章推荐使用 @Value 比 @ConfigurationProperties 好用的，吐了，别误人子弟。列举一下 @ConfigurationProperties 的好处。

• 在项目 application.yml 配置文件中按住 ctrl + 鼠标左键点击配置属性可以快速导航到配置类。写配置时也能自动补全、联想到注释。需要额外引入一个依赖 org.springframework.boot:spring-boot-configuration-processor 。

• @ConfigurationProperties 支持 NACOS 配置自动刷新，使用 @Value 需要在 BEAN 上面使用 @RefreshScope 注解才能实现自动刷新

• @ConfigurationProperties 可以结合 Validation 校验，@NotNull、@Length 等注解，如果配置校验没通过程序将启动不起来，及早的发现生产丢失配置等问题。

• @ConfigurationProperties 可以注入多个属性，@Value 只能一个一个写

• @ConfigurationProperties 可以支持复杂类型，无论嵌套多少层，都可以正确映射成对象

相比之下我不明白为什么那么多人不愿意接受新的东西，裂开......你可以看下所有的 springboot-starter 里面用的都是 @ConfigurationProperties 来接配置属性。

推荐使用 lombok

当然这是一个有争议的问题，我的习惯是使用它省去 getter、setter、toString 等等。

不要在 AService 调用 BMapper

我们一定要遵循从 AService -> BService -> BMapper，如果每个 Service 都能直接调用其他的 Mapper，那特么还要其他 Service 干嘛？老项目还有从 controller 调用 mapper 的，把控制器当 service 来处理了。。。

尽量少写工具类

为什么说要少写工具类，因为你写的大部分工具类，在你无形中引入的 jar 包里面就有，String 的，Assert 断言的，IO 上传文件，拷贝流的，Bigdecimal 的等等。自己写容易错还要加载多余的类。

不要包裹 OpenFeign 接口返回值

搞不懂为什么那么多人喜欢把接口的返回值用 Response 包装起来......加个 code、message、success 字段，然后每次调用方就变成这样

CouponCommonResult bindResult = couponApi.useCoupon(request.getCustomerId(), order.getLoanId(), coupon.getCode());
if (Objects.isNull(bindResult) || !bindResult.getResult()) {
  throw new AppException(CouponErrorCode.ERR_REC_COUPON_USED_FAILED);
}

这样就相当于

1. 在 coupon-api 抛出异常

2. 在 coupon-api 拦截异常，修改 Response.code

3. 在调用方判断 response.code 如果是 FAIELD 再把异常抛出去......

你直接在服务提供方抛异常不就行了么。。。而且这样一包装 HTTP 请求永远都是 200，没法做重试和监控。当然这个问题涉及到接口响应体该如何设计，目前网上大多是三种流派

• 接口响应状态一律 200

• 接口响应状态遵从HTTP真实状态

• 佛系开发，领导怎么说就怎么做

不接受反驳，我推荐使用 HTTP 标准状态。特定场景包括参数校验失败等一律使用 400 给前端弹 toast。下篇文章会阐述一律 200 的坏处。

写有意义的方法注释

这种注释你写出来是怕后面接手的人瞎么......

/**
* 请求电话验证
*
* @param credentialNum
* @param callback
* @param param
* @return PhoneVerifyResult
*/

要么就别写，要么就在后面加上描述......写这样的注释被 IDEA 报一堆警告看着蛋疼

和前端交互的 DTO 对象命名

什么 VO、BO、DTO、PO 我倒真是觉得没有那么大必要分那么详细，至少我们在和前端交互的时候类名要起的合适，不要直接用映射数据库的类返回给前端，这会返回很多不必要的信息，如果有敏感信息还要特殊处理。

推荐的做法是接受前端请求的类定义为 XxxRequest，响应的定义为 XxxResponse。以订单为例：接受保存更新订单信息的实体类可以定义为 OrderRequest，订单查询响应定义为 OrderResponse，订单的查询条件请求定义为 OrderQueryRequest。

尽量别让 IDEA 报警

我是很反感看到 IDEA 代码窗口一串警告的，非常难受。因为有警告就代表代码还可以优化，或者说存在问题。 前几天捕捉了一个团队内部的小bug，其实本来和我没有关系，但是同事都在一头雾水的看外面的业务判断为什么走的分支不对，我一眼就扫到了问题。

因为 java 中整数字面量都是 int 类型，到集合中就变成了 Integer，然后 stepId 点上去一看是 long 类型，在集合中就是 Long，那这个 contains 妥妥的返回 false，都不是一个类型。

你看如果注重到警告，鼠标移过去看一眼提示就清楚了，少了一个生产 bug。

尽可能使用新技术组件

我觉得这是一个程序员应该具备的素养......反正我是喜欢用新的技术组件，因为新的技术组件出现必定是解决旧技术组件的不足，而且作为一个技术人员我们应该要与时俱进~~ 当然前提是要做好准备工作，不能无脑升级。举个最简单的例子，Java 17 都出来了，新项目现在还有人用 Date 来处理日期时间...... 都什么年代了你还在用 Date

结语

本篇文章简单介绍我日常开发的习惯，当然仅是作者自己的见解。暂时只想到这几点，以后发现其他的会更新。

作者：暮色妖娆丶
来源：https://juejin.cn/post/7072252275002966030

我是3y，一年CRUD经验用十年的markdown程序员👨🏻‍💻常年被誉为优质八股文选手

花了几天搭了个后台管理页面，今天分享下我的搭建过程，全文非技术向，就当跟大家吹吹水吧。

1、我的前端技术

老读者可能知道我是上了大学以后，才了解什么是编程。在这之前，我对编程一无所知，甚至报考了计算机专业之后也未曾了解过它是做什么的。

在大一的第一个学期，我印象中只开了一门C++的编程课（其他的全是数学）。嗯，理所当然，我是听不懂的，也不知道用来干什么。

刚进大学的时候，我对一切充满了未知，在那时候顺其自然地就想要进几个社团玩玩。但在众多社团里都找不到我擅长的领域，等快到截止时间了。我又不想大学期间什么社团都没有参加，最后报了两个：乒乓球社团和计算机协会。

这个计算机协会绝大多数的人员都来自于计算机专业，再后来才发现这个协会的主要工作就是给人「重装系统」，不过这是后话啦。

当时加入计算机协会还需要满足一定的条件：师兄给了一个「网站」我们这群人，让我们上去学习，等到国庆回来后看下我们的学习进度再来决定是否有资格加入。

那个网站其实就是对HTML/CSS/JavaScript的入门教程，是一个国外的网站，具体的地址我肯定是忘了。不过那时候，我国庆闲着也没事干，于是就开始学起来了。我当时的进度应该是学到CSS，能简单的页面布局和展示图片啥的

刚开始的时候，觉得蛮有趣的：我改下这个代码，字体的颜色就变了，图片就能展示出来了。原来我平时上网的网站是这样弄出来的啊！ （比什么C++有趣多了）

国庆后回来发现：考核啥的并不重要，只要报名了就都通过了。

有了基本的认知后，我对这个也并不太上心，没有持续地学下去。再后来，我实在是太无聊，就开始想以后毕业找工作的事了，自己也得在大学充实下自己，于是我开始在知乎搜各种答案「如何入门编程」。

在知乎搜了各种路线并浪费了大量时间以后，我终于开始看视频入门。我熬完了JavaSE基础之后，我记得我是看方立勋老师入门的JavaWeb，到前端的课程以后，我觉得前端HTML/CSS/JavaScript啥的都要补补，于是又去找资源学习（那时候信奉着技多不压身）。

印象中是看韩顺平老师的HTML/CSS/JavaScript，那时候还手打代码的阶段，把我看得一愣一愣的（IDE都不需要的）。随着学习，发现好像还得学AJAX/jQuery，于是我又去找资源了，不过我已经忘了看哪个老师的AJAX和jQuery课程。

在这个学习的过程中，我曾经用纯HTML/CSS/JavaScript跟着视频仿照过某某网站，在jQuery的学习时候做过各种的轮播图动画。还理解了margin和padding的区别。临近毕业的时候，也会点BootStrap来写个简单的页面（丑就完事了）

等我进公司了以后，技术架构前后端是分离的，虽然我拉了前端的代码，但我看不懂，期间我也没学。以至于我两年多是没碰过前端的，我对前端充满着敬畏（刚毕业那段时间，前端在飞速发展）

2、AUSTIN前端选型

从我筹划要写austin项目的时候，我就知道我肯定要写一个「后台管理页面」，但我迟迟没下手。一方面是我认为「后端」才是我的赛道，另一方面我「前端」确实菜，不想动手。

我有想过要不找个小伙伴帮我写，但是很快就被我自己否定了：还得给小伙伴提需求，算了。

当我要面临前端的时，我第一时间就想到：肯定是有什么框架能够快速搭建出一个管理页面的。我自己不知道，但是，我的朋友圈肯定是有人知道的啊。于是，我果断求助：

我被安利了很多框架，简单列举下出场率比较高的。

注：大多数我只是粗略看了下，没有仔细研究。若有错误可以在评论区留言，轻喷

2.1 renren-fast

官网文档：http://www.renren.io/guide#getdo…

它这个框架是前后端分离的，后端还可以生成对应的CRUD代码，前端基于vue和element-ui开发。

当时其实我有点想选它的，但考虑到我要再部署个后端，还得学点vue，我就搁置了

2.2 RuoYi

官方文档：doc.ruoyi.vip/ruoyi/

RuoYi给我安利的也很多，这个貌似最近非常火？感觉我被推荐了以后，到处都能看到它的身影。

我简单刷了下文档，感觉他做的事比renren-fast要多，文档也很齐全，但是没找到我想要的东西：我打开一个文档，我希望能看到它的系统架构，系统之间的交互或者架构层面上的东西，但我没快速找到。

项目齐全和复杂对我来说或许并不是一件好事，很可能意味着我的学习成本可能会更大。于是，我也搁置着。

2.3 Vue相关

vue-element-admin

官方文档：panjiachen.github.io/vue-element…

Vue Antd Admin

官方文档：iczer.gitee.io/vue-antd-ad…

Ant Design Pro

官方文档：pro.antdv.com/docs/gettin…

这几个项目被推荐率也是极高的，从第一行介绍我基本就知道需要去学Vue的语法，奈何我太懒了，搁置着。

2.4 layui

有好几小伙伴们听说我会jQuery，于是给我推荐了layui。我以前印象中好像听过这个框架，但一直没了解过他。但是，当我搜到它的时候，它已经不维护了

GitHub地址：github.com/sentsin/lay…

我简单浏览下文档，其实它也有对应的一套”语法“，需要一定的学习成本，但不高。

第一感觉有点类似我以前写过的BootStrap，我对这不太感冒，感觉如果要接入可能还是需要自己写比较多的代码。

2.5 其他

还有些小伙伴推荐或者我看到的文章推荐：x-admin/D2admin/smartchart/JEECG-BOOT/Dcat-admin/iview-admin等等等，在这里面还有些依赖着PHP/Python

总的来说，我还是觉得这些框架有一定的学习成本（我真的是懒出天际了）。可能需要我去部署后端，也可能需要我学习前端的框架语法，也可能让我学Vue

看到这里，可能你们很好奇我最后选了什么作为austin的前端，都已经被我筛了这么多了。在公布之前，我想说的是：如果想要页面好看和灵活性高还是得学习Vue。从上面我被推荐的框架中，好多都是在Vue的基础上改动的，并且我敢肯定：还有很多基于Vue且好用的后台是我不知道的。

注：我这里指代跟我一样不懂前端的（如果本身就已经懂前端，你说啥都对）

3、AMIS框架

我最后选择了amis作为austin的前端。这个框架在我朋友圈只有一个小伙伴推荐，我第一次打开文档的时候，确实惊艳到我了

文档地址：baidu.gitee.io/amis/zh-CN/…

它是一个低代码前端框架：amis 的渲染过程是将 json 转成对应的 React 组件

我花了半天粗略地刷了下文档，大概知道了JSON的结构（说实话，他这个文档写得挺可以的），然后我去GitHub找了一份模板，就直接开始动手了，readme十分简短。

GitHub：github.com/aisuda/amis…

这个前端低代码工具还有个好处就是可以通过可视化编辑器拖拉生成JSON代码，将生成好的代码直接往自己本地一贴，就完事了，确实挺方便的。

可视化编辑器的地址：aisuda.github.io/amis-editor…

4、使用感受

其实没什么好讲的，无非就是在页面上拖拉得到一个页面，然后调用API的时候看下文档的姿势。

在这个过程中我也去看了下这个框架的评价，发现百度内部很多系统就用的这个框架来搭建页面的，也看到Bigo也有在线上使用这个框架来搭建后台。有一线/二线公司都在线上使用该框架了，我就认为问题不大了。

总的来说，我这次搭建austin后台实际编码时间没多少，都在改JSON配置和查文档。我周六下午2点到的图书馆，新建了GitHub仓库，在6点闭馆前就已经搭出个大概页面了，然后在周日空闲时间里再完善了几下，感觉可以用了

austin-amis仓库地址：github.com/ZhongFuChen…

在搭建的过程中，amis低代码框架还是有地方可吐槽的，就是它的灵活性太低。我们的接口返回值需要迎合它的主体结构，当我们如果有嵌套JSON这种就变得异常难处理，表单无法用表达式进行回显等等。

它并不完美，很可能需要我用些奇怪的姿势妥协，不要问我接口返回的时候为啥转了一层Map

不管怎么说，这不妨碍我花了极短的时间就能搭出一个能看的后台管理页面(CRUD已齐全)

5、总结

目前搭好的前端能用，也只能用一点点，后面会逐渐完善它的配置和功能的。我后面有链路追踪的功能，肯定要在后台这把清洗后的数据提供给后台进行查询，但也不会花比较长的篇幅再来聊前端这事了。

我一直定位是在后端的代码上，至于前端我能学，但我又不想学。怎么说呢，利益最大化吧。我把学前端的时间花在学后端上，或许可能对我有更大的受益。现在基本前后端分离了，在公司我也没什么机会写前端。

下一篇很有可能是聊分布式定时任务框架上，我发现我的进度可以的，这个季度拿个4.0应该问题不大了。

都看到这里了，点个赞一点都不过分吧？我是3y，下期见。

austin项目源码Gitee链接：gitee.com/austin

austin项目源码GitHub链接：github.com/austin

作者：Java3y
来源：https://juejin.cn/post/7076231399669235725

1.前言

你是否对大厂展示的五花八门，花花绿绿的架构设计图所深深吸引，当我们想用几张图来介绍下业务系统，是不是对着画布不知从何下手？作为技术扛把子的筒子们是不是需要一张图来描述系统，让系统各个参与方都能看的明白？如果有这样的困惑，本文将介绍一些画图的方法论，让技术图纸更加清晰。

2. 架构的定义

• 系统架构是概念的体现，是对物/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所做的定义;

• 架构就是对系统中的实体以及实体之间的关系所进行的抽象描述，是一系列的决策;

• 架构是结构和愿景.

在TOGAF企业架构理论中， 架构是从公司战略层面，自顶向下的细化的一部分，从战略=> 业务架构=>应用/数据/技术架构，当然老板层关注的是战略与业务架构，我们搬砖的需要聚焦到应用/数据/技术架构这一层。

• 业务架构: 由业务架构师负责，也可以称为业务领域专家、行业专家，业务架构属于顶层设计，其对业务的定义和划分会影响组织架构和技术架构;

• 应用架构: 由应用架构师负责，需要根据业务场景需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维护性的同时，确保应用满足非功能属性的要求如性能、安全、稳定性等。

• 技术架构: 描述了需要哪些服务；选择哪些技术组件来实现技术服务；技术服务以及组件之间的交互关系;

• 数据架构: 描述了数据模型、分布、数据的流向、数据的生命周期、数据的管理等关系;

3.架构图的分类

系统架构图是为了抽象的表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界，以及软件系统的物理部署和软件系统的演进方向的整体视图。好的架构图可以让干系人理解、遵循架构决策，就需要把架构信息传递出去。那么，画架构图是为了：解决沟通障碍/达成共识/减少歧义。比较流行的是4+1视图和C4视图。

3.1 4+1视图

3.1.1 场景视图

用于描述系统的参与者与功能用例间的关系,反映系统的最终需求和交互设计，通常由用例图表示;

3.1.2 逻辑视图

用于描述系统软件功能拆解后的组件关系，组件约束和边界，反映系统整体组成与系统如何构建的过程，通常由UML的组件图和类图来表示。

3.1.3 物理视图

用于描述系统软件到物理硬件的映射关系,反映出系统的组件是如何部署到一组可计算机器节点上，用于指导软件系统的部署实施过程。

3.1.4 处理流程视图

用于描述系统软件组件之间的通信时序,数据的输入输出,反映系统的功能流程与数据流程,通常由时序图和流程图表示。

3.1.5 开发视图

开发视图用于描述系统的模块划分和组成,以及细化到内部包的组成设计,服务于开发人员,反映系统开发实施过程。

5 种架构视图从不同角度表示一个软件系统的不同特征，组合到一起作为架构蓝图描述系统架构。

3.2 C4视图

下面的案例来自C4官网，然后加上了一些笔者的理解。

C4 模型使用容器（应用程序、数据存储、微服务等）、组件和代码来描述一个软件系统的静态结构。这几种图比较容易画，也给出了画图要点，但最关键的是，我们认为，它明确指出了每种图可能的受众以及意义。

3.2.1 语境图(System Context Diagram)

用于描述要我们要构建的系统是什么，用户是谁，需要如何融入已有的IT环境。这个图的受众可以是开发团队的内部人员、外部的技术或非技术人员。

3.2.2 容器图(Container Diagram)

容器图是把语境图里待建设的系统做了一个展开描述，主要受众是团队内部或外部的开发人员或运维人员，主要用来描述软件系统的整体形态，体现了高层次的技术决策与选型，系统中的职责是如何分布的，容器间是如何交互的。

3.2.3 组件图(Component Diagram)

组件图是把某个容器进行展开，描述其内部的模块，主要是给内部开发人员看的，怎么去做代码的组织和构建，描述了系统由哪些组件/服务组成，了组件之间的关系和依赖，为软件开发如何分解交付提供了框架。

4.怎么画好架构图

上面的分类是前人的经验总结，图也是从网上摘来的，那么这些图画的好不好呢？是不是我们要依葫芦画瓢去画这样一些图？先不去管这些图好不好，我们通过对这些图的分类以及作用，思考了一下，总结下来，我们认为，明确这两点之后，从受众角度来说，一个好的架构图是不需要解释的，它应该是自描述的，并且要具备一致性和足够的准确性，能够与代码相呼应。

4.1 视图的受众

在画出一个好的架构图之前， 首先应该要明确其受众，再想清楚要给他们传递什么信息 ，所以，不要为了画一个物理视图去画物理视图，为了画一个逻辑视图去画逻辑视图，而应该根据受众的不同，传递的信息的不同，用图准确地表达出来，最后的图可能就是在这样一些分类里。那么，画出的图好不好的一个直接标准就是：受众有没有准确接收到想传递的信息。

4.2 视图的元素区分

可以看到架构视图是由方框和线条等元素构成，要利用形状、颜色、线条变化等区分元素的含义，避免混淆。架构是一项复杂的工作，只使用单个图表来表示架构很容易造成莫名其妙的语义混乱。

让我们一起画出好的架构图！

参考资料

• c4model.com/

• 《程序员必读之软件架构》

• 为什么需要软件架构图

作者：代码的色彩
来源：https://juejin.cn/post/7062662600437268493

前言

说起KFC，大家都知道是肯德基🍟，但面试官问你什么是BFC、IFC、GFC和FFC的时候，你是否能够像回答KFC是肯德基时的迅速，又或者说后面这些你根本就没听说过，作为一名前端开发工程师，以上这些FC(Forrmatting Context)你都得知道，而且必须得做到像肯德基这样印象深刻。下面我将会带大家一起揭开这些FC的真面目，如果你已经了解的请奖励自己一顿肯德基～（注意文明用语，这里别用语气词😂）

FC的全称是：Formatting Contexts，译作格式化上下文，是W3C CSS2.1规范中的一个概念。它是页面中的一块渲染区域，并且有一套渲染规则，它决定了其子元素将如何定位，以及和其他元素的关系和相互作用。

CSS2.1中只有BFC和IFC，CSS3中才有GFC和FFC。

如果这篇文章有帮助到你，❤️关注+点赞❤️鼓励一下作者，文章公众号首发，关注 前端南玖 第一时间获取最新的文章～

前置概念

在学习各种FC之前，我们先来了解几个基本概念：

Box（CSS布局基本单位）

简单来讲，我们看到的所有页面都是由一个个Box组合而成的，元素的类型和display属性决定了Box的类型。

• block-level Box： 当元素的 CSS 属性 display 为 block, list-item 或table 时，它是块级元素 block-level。块级元素（比如<p>)视觉上呈现为块，竖直排列。 每个块级元素至少生成一个块级盒（block-level Box）参与 BFC ，称为主要块级盒(principal block-level box)。一些元素，比如<li>，生成额外的盒来放置项目符号，不过多数元素只生成一个主要块级盒。

• Inline-level Box： 当元素的 CSS 属性 display 的计算值为inline,inline-block 或inline-table 时，称它为行内级元素。视觉上它将内容与其它行内级元素排列为多行。典型的如段落内容，有文本或图片，都是行内级元素。行内级元素生成行内级盒(inline-level boxes)，参与行内格式化上下文 IFC 。

• flex container： 当元素的 CSS 属性 display 的计算值为 flex 或 inline-flex ，称它为弹性容器。display:flex这个值会导致一个元素生成一个块级（block-level）弹性容器框。display:inline-flex这个值会导致一个元素生成一个行内级（inline-level）弹性容器框。

• grid container：*当元素的 CSS 属性 display 的计算值为 grid 或inline-grid，称它为*栅格容器。

块容器盒（block container box）

只包含其它块级盒，或生成一个行内格式化上下文(inline formatting context)，只包含行内盒的叫做块容器盒子。

也就是说，块容器盒要么只包含行内级盒，要么只包含块级盒。

块级盒（block-level Box）是描述元素跟它的父元素与兄弟元素之间的表现。

块容器盒（block container box）描述元素跟它的后代之间的影响。

块盒（BLock Boxes）

同时是块容器盒的块级盒称为块盒(block boxes)

行盒(Line boxes)

行盒由行内格式化上下文(inline formatting context)产生的盒，用于表示一行。在块盒里面，行盒从块盒一边排版到另一边。 当有浮动时, 行盒从左浮动的最右边排版到右浮动的最左边。

OK，了解完上面这些概念，我们再来看我们本篇文章的重点内容（终于要揭开各种FC的庐山真面目了，期待～）

BFC（Block Formatting Contexts）块级格式化上下文

什么是BFC？

BFC 全称：Block Formatting Context， 名为 块级格式化上下文。

W3C官方解释为：BFC它决定了元素如何对其内容进行定位，以及与其它元素的关系和相互作用，当涉及到可视化布局时，Block Formatting Context提供了一个环境，HTML在这个环境中按照一定的规则进行布局。

如何触发BFC？

• 根元素或其它包含它的元素

• 浮动 float: left/right/inherit

• 绝对定位元素 position: absolute/fixed

• 行内块display: inline-block

• 表格单元格 display: table-cell

• 表格标题 display: table-caption

• 溢出元素 overflow: hidden/scroll/auto/inherit

• 弹性盒子 display: flex/inline-flex

BFC布局规则

• 内部的Box会在垂直方向，一个接一个地放置。

• Box垂直方向的距离由margin决定。属于同一个BFC的两个相邻Box的margin会发生重叠。

• 每个元素的margin box的左边， 与包含块border box的左边相接触(对于从左往右的格式化，否则相反)。即使存在浮动也是如此。

• BFC的区域不会与float box重叠。

• BFC就是页面上的一个隔离的独立容器，容器里面的子元素不会影响到外面的元素。反之也如此。

• 计算BFC的高度时，浮动元素也参与计算

BFC应用场景

解决块级元素垂直方向margin重叠

我们来看下面这种情况：

<style>
  .box{
    width:180px;
    height:180px;
    background:rosybrown;
    color:#fff;
    margin: 60px auto;
  }
</style>
<body>
    <div class="box">nanjiu</div>
    <div class="box">南玖</div>
</body>

按我们习惯性思维，上面这个box的margin-bottom是60px，下面这个box的margin-top也是60px，那他们垂直的间距按道理来说应该是120px才对。（可事实并非如此，我们可以来具体看一下）

从图中我们可以看到，两个box的垂直间距只有60px，并不是120px!

这种情况下的margin边距为两者的最大值，而不是两者相加，那么我们可以使用BFC来解决这种margin塌陷的问题。

<style>
  .box{
    width:180px;
    height:180px;
    background:rosybrown;
    color:#fff;
    margin: 60px auto;
  }
  .outer_box{
    overflow: hidden;
  }
</style>
<body>
    <div class="outer_box">
        <div class="box">nanjiu</div>
    </div>
    <div class="box">南玖</div>
</body>

由上面可以看到，我们通过给第一个box外面再包裹一层容器，并触发它形成BFC，此时的两个box就不属于同一个BFC了，它们的布局互不干扰，所以这时候他们的垂直间距就是两者间距相加了。

解决高度塌陷问题

我们再来看这种情况，内部box使用float脱离了普通文档流，导致外层容器没办法撑起高度，使得背景颜色没有显示出来。

<style>
  .box{
    float:left;
    width:180px;
    height:180px;
    background:rosybrown;
    color:#fff;
    margin: 60px;
  }
  .outer_box{
    background:lightblue;
  }
</style>
<body>
    <div class="outer_box">
        <div class="box">nanjiu</div>
        <div class="box">南玖</div>
    </div>
</body>

从这张图，我们可以看到此时的外层容器的高度为0，导致背景颜色没有渲染出来，这种情况我们同样可以使用BFC来解决，可以直接为外层容器触发BFC，我们来看看效果：

<style>
  .box{
    float:left;
    width:180px;
    height:180px;
    background:rosybrown;
    color:#fff;
    margin: 60px;
  }
.outer_box{
  display:inline-block;
  background:lightblue;
}
</style>
<body>
    <div class="outer_box">
        <div class="box">nanjiu</div>
        <div class="box">南玖</div>
    </div>
</body>

清除浮动

在早期前端页面大多喜欢用浮动来布局，但浮动元素脱离普通文档流，会覆盖旁边内容：

<style>
.aside {
  float: left;
  width:180px;
  height: 300px;
  background:lightpink;
  }
  .container{
    width:500px;
    height:400px;
    background:mediumturquoise;
  }
</style>
<body>
    <div class="outer_box">
        <div class="aside">nanjiu</div>
        <div class="container">南玖</div>
    </div>
</body>

我们可以通过触发后面这个元素形成BFC，从而来清楚浮动元素对其布局造成的影响

<style>
.aside {
  float: left;
  width:180px;
  height: 300px;
  background:lightpink;
  }
  .container{
    width:500px;
    height:400px;
    background:mediumturquoise;
    overflow: hidden;
  }
</style>
<body>
    <div class="outer_box">
        <div class="aside">nanjiu</div>
        <div class="container">南玖</div>
    </div>
</body>

IFC（Inline Formatting Contexts）行内级格式化上下文

什么是IFC？

IFC全称：Inline Formatting Context，名为行级格式化上下文

如何触发IFC？

• 块级元素中仅包含内联级别元素

形成条件非常简单，需要注意的是当IFC中有块级元素插入时，会产生两个匿名块将父元素分割开来，产生两个IFC。

IFC布局规则

• 在一个IFC内，子元素是水平方向横向排列的，并且垂直方向起点为元素顶部。

• 子元素只会计算横向样式空间，【padding、border、margin】，垂直方向样式空间不会被计算，【padding、border、margin】。

• 在垂直方向上，子元素会以不同形式来对齐（vertical-align）

• 能把在一行上的框都完全包含进去的一个矩形区域，被称为该行的行框（line box）。行框的宽度是由包含块（containing box）和与其中的浮动来决定。

• IFC中的line box一般左右边贴紧其包含块，但float元素会优先排列。

• IFC中的line box高度由 CSS 行高计算规则来确定，同个IFC下的多个line box高度可能会不同。

• 当 inline boxes的总宽度少于包含它们的line box时，其水平渲染规则由 text-align 属性值来决定。

• 当一个inline box超过父元素的宽度时，它会被分割成多个boxes，这些boxes分布在多个line box中。如果子元素未设置强制换行的情况下，inline box将不可被分割，将会溢出父元素。

IFC应用场景

元素水平居中

当一个块要在环境中水平居中时，设置其为inline-block则会在外层产生IFC，通过text-align则可以使其水平居中。

<style>
    /* IFC */
  .text_container{
    width: 650px;
    border: 3px solid salmon;
    margin-top:60px;
    text-align: center;
  }
  strong,span{
    /* border:1px solid cornflowerblue; */
    margin: 20px;
    background-color: cornflowerblue;
    color:#fff;
  }
</style>
<body>
    <div class="text_container">
        <strong>众里寻他千百度，南玖需要你关注</strong>
        <span>蓦然回首，那人却在，南玖前端交流群</span>
    </div>
</body>

多行文本水平垂直居中

创建一个IFC，然后设置其vertical-align:middle，其他行内元素则可以在此父元素下垂直居中。

<style>
.text_container{
  text-align: center;
  line-height: 300px;
  width: 100%;
  height: 300px;
  background-color: turquoise;
  font-size: 0;
  }
  p{
    line-height: normal;
    display: inline-block;
    vertical-align: middle;
    background-color: coral;
    font-size: 18px;
    padding: 10px;
    width: 360px;
    color: #fff;
  }
</style>
<body>
  <div class="text_container">
    <p>
      东风夜放花千树，更吹落，星如雨。宝马雕车香满路。凤箫声动，玉壶光转，一夜鱼龙舞。蛾儿雪柳黄金缕，笑语盈盈暗香去。
      <strong>众里寻他千百度，蓦然回首，那人却在，灯火阑珊处。</strong>
    </p>
  </div>
</body>

GFC（Grid Formatting Contexts）栅格格式化上下文

什么是GFC？

GFC全称：Grids Formatting Contexts，名为网格格式上下文

简介： CSS3引入的一种新的布局模型——Grids网格布局，目前暂未推广使用，使用频率较低，简单了解即可。 Grid 布局与 Flex 布局有一定的相似性，都可以指定容器内部多个项目的位置。但是，它们也存在重大区别。 Flex 布局是轴线布局，只能指定"项目"针对轴线的位置，可以看作是一维布局。Grid 布局则是将容器划分成"行"和"列"，产生单元格，然后指定"项目所在"的单元格，可以看作是二维布局。Grid 布局远比 Flex 布局强大。

如何触发GFC？

当为一个元素设置display值为grid或者inline-grid的时候，此元素将会获得一个独立的渲染区域。

GFC布局规则

通过在网格容器（grid container）上定义网格定义行（grid definition rows）和网格定义列（grid definition columns）属性各在网格项目（grid item）上定义网格行（grid row）和网格列（grid columns）为每一个网格项目（grid item）定义位置和空间（具体可以在MDN上查看）

GFC应用场景

任意魔方布局

这个布局使用用GFC可以轻松实现自由拼接效果，换成其他方法，一般会使用相对/绝对定位，或者flex来实现自由拼接效果，复杂程度将会提升好几个等级。

<style>

.magic{

  display: grid;

  grid-gap: 2px;

  width:300px;

  height:300px;

  }

  .magic div{

    border: 1px solid coral;

  }

  .m_1{

    grid-column-start: 1;

    grid-column-end: 3;

  }

  .m_3{

    grid-column-start: 2;

    grid-column-end: 4;

    grid-row-start: 2;

    grid-row-end: 3;

  }

</style>

<body>

  <div>

    <div>1</div>

    <div>2</div>

    <div>3</div>

    <div>4</div>

    <div>5</div>

    <div>6</div>

    <div>7</div>

  </div>

</body>

FFC（Flex Formatting Contexts）弹性格式化上下文

什么是FFC？

FFC全称：Flex Formatting Contexts，名为弹性格式上下文

简介： CSS3引入了一种新的布局模型——flex布局。 flex是flexible box的缩写，一般称之为弹性盒模型。和CSS3其他属性不一样，flexbox并不是一个属性，而是一个模块，包括多个CSS3属性。flex布局提供一种更加有效的方式来进行容器内的项目布局，以适应各种类型的显示设备和各种尺寸的屏幕，使用Flex box布局实际上就是声明创建了FFC(自适应格式上下文)

如何触发FFC？

当 display 的值为 flex 或 inline-flex 时，将生成弹性容器（Flex Containers）, 一个弹性容器为其内容建立了一个新的弹性格式化上下文环境（FFC）

FFC布局规则

• 设置为 flex 的容器被渲染为一个块级元素

• 设置为 inline-flex 的容器被渲染为一个行内元素

• 弹性容器中的每一个子元素都是一个弹性项目。弹性项目可以是任意数量的。弹性容器外和弹性项目内的一切元素都不受影响。简单地说，Flexbox 定义了弹性容器内弹性项目该如何布局

⚠️注意：FFC布局中，float、clear、vertical-align属性不会生效。

Flex 布局是轴线布局，只能指定"项目"针对轴线的位置，可以看作是一维布局。Grid 布局则是将容器划分成"行"和"列"，产生单元格，然后指定"项目所在"的单元格，可以看作是二维布局。Grid 布局远比 Flex 布局强大。

FFC应用场景

这里只介绍它对于其它布局所相对来说更方便的特点，其实flex布局现在是非常普遍的，很多前端人员都喜欢用flex来写页面布局，操作方便且灵活，兼容性好。

自动撑开剩余高度/宽度

看一个经典两栏布局：左边为侧边导航栏，右边为内容区域，用我们之前的常规布局，可能就需要使用到css的calc方法来动态计算剩余填充宽度了，但如果使用flex布局的话，只需要一个属性就能解决这个问题：

calc动态计算方法：

<style>
.outer_box {
    width:100%;
} 
.aside {
  float: left;
  width:180px;
  height: 300px;
  background:lightpink;
}
.container{
  width:calc(100% - 180px);
  height:400px;
  background:mediumturquoise;
  overflow: hidden;
 }
</style>
<body>
        <div class="outer_box">
        <div class="aside">nanjiu</div>
        <div class="container">南玖</div>
    </div>
</body>

使用FFC：

<style>
.outer_box {
  display:flex;
    width:100%;
} 
.aside {
  float: left;
  width:180px;
  height: 300px;
  background:lightpink;
}
.container{
  flex: 1;
  height:400px;
  background:mediumturquoise;
  overflow: hidden;
 }
</style>
<body>
        <div class="outer_box">
        <div class="aside">nanjiu</div>
        <div class="container">南玖</div>
    </div>
</body>

总结

一般来说，FFC能做的事情，通过GFC都能搞定，反过来GFC能做的事通过FFC也能实现。 通常弹性布局使用FFC，二维网格布局使用GFC，所有的FFC与GFC也是一个BFC，在遵循自己的规范的情况下，向下兼容BFC规范。

现在所有的FC都介绍完了，了解清楚的去奖励自己一顿KFC吧😄～

推荐阅读

• 前端常见的安全问题及防范措施

• 为什么大厂前端监控都在用GIF做埋点？

• 介绍回流与重绘（Reflow & Repaint），以及如何进行优化?

• Promise、Generator、Async有什么区别？

• 2022年了你还不了解箭头函数与普通函数的区别吗？

• 从如何使用到如何实现一个Promise

• 超详细讲解页面加载过程

作者：南玖
来源：https://juejin.cn/post/7072174649735381029

在 select 语句之前增加 explain 关键字，MySQL 会在查询上设置一个标记，执行查询时，会返回执行计划的信息，而不是执行这条SQL（如果 from 中包含子查询，仍会执行该子查询，将结果放入临时表中）

CREATE TABLE `film` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(10) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


CREATE TABLE `actor` (
  `id` int(11) NOT NULL,
  `name` varchar(45) DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


CREATE TABLE `film_actor` (
  `id` int(11) NOT NULL,
  `film_id` int(11) NOT NULL,
  `actor_id` int(11) NOT NULL,
  `remark` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_film_actor_id` (`film_id`,`actor_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

两个变种

explain extended

会在 explain 的基础上额外提供一些查询优化的信息。

紧随其后通过 show warnings 命令可以 得到优化后的查询语句，从而看出优化器优化了什么。

额外还有 filtered 列，是一个半分比的值，rows * filtered/100 可以估算出将要和 explain 中前一个表进行连接的行数（前一个表指 explain 中的id值比当前表id值小的表）

mysql> explain extended select * from film where id = 1;

mysql> show warnings;

explain partitions

相比 explain 多了个 partitions 字段，如果查询是基于分区表的话，会显示查询将访问的分区。

id列

id列的编号是 select 的序列号，有几个 select 就有几个id，并且id的顺序是按 select 出现的顺序增长的。

一般是使用了覆盖索引(索引包含了所有查询的字段)。对于innodb来说，如果是辅助索引性能会有不少提高

mysql> explain select film_id from film_actor where film_id = 1;

Using where

查询的列未被索引覆盖，where筛选条件非索引的前导列

mysql> explain select * from actor where name = 'a';

Using where Using index

查询的列被索引覆盖，并且where筛选条件是索引列之一但是不是索引的前导列，意味着无法直接通过索引查找来查询到符合条件的数据

mysql> explain select film_id from film_actor where actor_id = 1;

NULL

查询的列未被索引覆盖，并且where筛选条件是索引的前导列，意味着用到了索引，但是部分字段未被索引覆盖，必须通过“回表”来实现，不是纯粹地用到了索引，也不是完全没用到索引

mysql>explain select * from film_actor where film_id = 1;

Using index condition

与Using where类似，查询的列不完全被索引覆盖，where条件中是一个前导列的范围；

mysql> explain select * from film_actor where film_id > 1;

Using temporary

mysql需要创建一张临时表来处理查询。出现这种情况一般是要进行优化的，首先是想到用索引来优化。

1. actor.name没有索引，此时创建了张临时表来distinct

mysql> explain select distinct name from actor;

1. film.name建立了idx_name索引，此时查询时extra是using index,没有用临时表

mysql> explain select distinct name from film;

Using filesort

mysql 会对结果使用一个外部索引排序，而不是按索引次序从表里读取行。

此时mysql会根据联接类型浏览所有符合条件的记录，并保存排序关键字和行指针，然后排序关键字并按顺序检索行信息。

这种情况下一般也是要考虑使用索引来优化的。

1. actor.name未创建索引，会浏览actor整个表，保存排序关键字name和对应的id，然后排序name并检索行记录。

mysql> explain select * from actor order by name;

1. film.name建立了idx_name索引,此时查询时extra是using index

mysql> explain select * from film order by name;

作者：程序员段飞
来源：https://juejin.cn/post/7074030240904773645

前言

毕业快三年了，前后也待过几家公司，碰到各种各样的同事。见识过各种各样的代码，优秀的、垃圾的、不堪入目的、看了想跑路的等等，所以这篇文章记录一下一个优秀的后端 Java 开发应该有哪些好的开发习惯。

拆分合理的目录结构

受传统的 MVC 模式影响，传统做法大多是几个固定的文件夹 controller、service、mapper、entity，然后无限制添加，到最后你就会发现一个 service 文件夹下面有几十上百个 Service 类，根本没法分清业务模块。正确的做法是在写 service 上层新建一个 modules 文件夹，在 moudles 文件夹下根据不同业务建立不同的包，在这些包下面写具体的 service、controller、entity、enums 包或者继续拆分。

等以后开发版本迭代，如果某个包可以继续拆领域就继续往下拆，可以很清楚的一览项目业务模块。后续拆微服务也简单。

封装方法形参

当你的方法形参过多时请封装一个对象出来...... 下面是一个反面教材，谁特么教你这样写代码的！

public void updateCustomerDeviceAndInstallInfo(long customerId, String channelKey,
                   String androidId, String imei, String gaId,
                   String gcmPushToken, String instanceId) {}

写个对象出来

public class CustomerDeviceRequest {
    private Long customerId;
    //省略属性......
}

为什么要这么写？比如你这方法是用来查询的，万一以后加个查询条件是不是要修改方法？每次加每次都要改方法参数列表。封装个对象，以后无论加多少查询条件都只需要在对象里面加字段就行。而且关键是看起来代码也很舒服啊！

封装业务逻辑

如果你看过“屎山”你就会有深刻的感触，这特么一个方法能写几千行代码，还无任何规则可言......往往负责的人会说，这个业务太复杂，没有办法改善，实际上这都是懒的借口。不管业务再复杂，我们都能够用合理的设计、封装去提升代码可读性。下面贴两段高级开发（假装自己是高级开发）写的代码

@Transactional
public ChildOrder submit(Long orderId, OrderSubmitRequest.Shop shop) {
    ChildOrder childOrder = this.generateOrder(shop);
    childOrder.setOrderId(orderId);
    //订单来源 APP/微信小程序
    childOrder.setSource(userService.getOrderSource());
    // 校验优惠券
    orderAdjustmentService.validate(shop.getOrderAdjustments());
    // 订单商品
    orderProductService.add(childOrder, shop);
    // 订单附件
    orderAnnexService.add(childOrder.getId(), shop.getOrderAnnexes());
    // 处理订单地址信息
    processAddress(childOrder, shop);
    // 最后插入订单
    childOrderMapper.insert(childOrder);
    this.updateSkuInventory(shop, childOrder);
    // 发送订单创建事件
    applicationEventPublisher.publishEvent(new ChildOrderCreatedEvent(this, shop, childOrder));
    return childOrder;
}
@Transactional
public void clearBills(Long customerId) {
    // 获取清算需要的账单、deposit等信息
    ClearContext context = getClearContext(customerId);
    // 校验金额合法
    checkAmount(context);
    // 判断是否可用优惠券，返回可抵扣金额
    CouponDeductibleResponse deductibleResponse = couponDeducted(context);
    // 清算所有账单
    DepositClearResponse response = clearBills(context);
    // 更新 l_pay_deposit
    lPayDepositService.clear(context.getDeposit(), response);
    // 发送还款对账消息
    repaymentService.sendVerifyBillMessage(customerId, context.getDeposit(), EventName.DEPOSIT_SUCCEED_FLOW_REMINDER);
    // 更新账户余额
    accountService.clear(context, response);
    // 处理清算的优惠券，被用掉或者解绑
    couponService.clear(deductibleResponse);
    // 保存券抵扣记录
    clearCouponDeductService.add(context, deductibleResponse);
}

这段两代码里面其实业务很复杂，内部估计保守干了五万件事情，但是不同水平的人写出来就完全不同，不得不赞一下这个注释，这个业务的拆分和方法的封装。一个大业务里面有多个小业务，不同的业务调用不同的 service 方法即可，后续接手的人即使没有流程图等相关文档也能快速理解这里的业务，而很多初级开发写出来的业务方法就是上一行代码是 A 业务的，下一行代码是 B业务的，在下面一行代码又是 A 业务的，业务调用之间还嵌套这一堆单元逻辑，显得非常混乱，代码还多。

判断集合类型不为空的正确方式

很多人喜欢写这样的代码去判断集合

if (list == null || list.size() == 0) {
  return null;
}

当然你硬要这么写也没什么问题......但是不觉得难受么，现在框架中随便一个 jar 包都有集合工具类，比如 org.springframework.util.CollectionUtils、com.baomidou.mybatisplus.core.toolkit.CollectionUtils 。 以后请这么写

if (CollectionUtils.isEmpty(list) || CollectionUtils.isNotEmpty(list)) {
  return null;
}

集合类型返回值不要 return null

当你的业务方法返回值是集合类型时，请不要返回 null，正确的操作是返回一个空集合。你看 mybatis 的列表查询，如果没查询到元素返回的就是一个空集合，而不是 null。否则调用方得去做 NULL 判断，多数场景下对于对象也是如此。

映射数据库的属性尽量不要用基本类型

我们都知道 int/long 等基本数据类型作为成员变量默认值是 0。现在流行使用 mybatisplus 、mybatis 等 ORM 框架，在进行插入或者更新的时候很容易会带着默认值插入更新到数据库。我特么真想砍了之前的开发，重构的项目里面实体类里面全都是基本数据类型。当场裂开......

封装判断条件

public void method(LoanAppEntity loanAppEntity, long operatorId) {
  if (LoanAppEntity.LoanAppStatus.OVERDUE != loanAppEntity.getStatus()
          && LoanAppEntity.LoanAppStatus.CURRENT != loanAppEntity.getStatus()
          && LoanAppEntity.LoanAppStatus.GRACE_PERIOD != loanAppEntity.getStatus()) {
    //...
    return;
  }

这段代码的可读性很差，这 if 里面谁知道干啥的？我们用面向对象的思想去给 loanApp 这个对象里面封装个方法不就行了么？

public void method(LoanAppEntity loan, long operatorId) {
  if (!loan.finished()) {
    //...
    return;
  }

LoanApp 这个类中封装一个方法，简单来说就是这个逻辑判断细节不该出现在业务方法中。

/**
 * 贷款单是否完成
 */
public boolean finished() {
  return LoanAppEntity.LoanAppStatus.OVERDUE != this.getStatus()
          && LoanAppEntity.LoanAppStatus.CURRENT != this.getStatus()
          && LoanAppEntity.LoanAppStatus.GRACE_PERIOD != this.getStatus();
}

控制方法复杂度

推荐一款 IDEA 插件 CodeMetrics ，它能显示出方法的复杂度，它是对方法中的表达式进行计算，布尔表达式，if/else 分支，循环等。

点击可以查看哪些代码增加了方法的复杂度，可以适当进行参考，毕竟我们通常写的是业务代码，在保证正常工作的前提下最重要的是要让别人能够快速看懂。当你的方法复杂度超过 10 就要考虑是否可以优化了。

使用 @ConfigurationProperties 代替 @Value

之前居然还看到有文章推荐使用 @Value 比 @ConfigurationProperties 好用的，吐了，别误人子弟。列举一下 @ConfigurationProperties 的好处。

• 在项目 application.yml 配置文件中按住 ctrl + 鼠标左键点击配置属性可以快速导航到配置类。写配置时也能自动补全、联想到注释。需要额外引入一个依赖 org.springframework.boot:spring-boot-configuration-processor 。

• @ConfigurationProperties 支持 NACOS 配置自动刷新，使用 @Value 需要在 BEAN 上面使用 @RefreshScope 注解才能实现自动刷新

• @ConfigurationProperties 可以结合 Validation 校验，@NotNull、@Length 等注解，如果配置校验没通过程序将启动不起来，及早的发现生产丢失配置等问题。

• @ConfigurationProperties 可以注入多个属性，@Value 只能一个一个写

• @ConfigurationProperties 可以支持复杂类型，无论嵌套多少层，都可以正确映射成对象

相比之下我不明白为什么那么多人不愿意接受新的东西，裂开......你可以看下所有的 springboot-starter 里面用的都是 @ConfigurationProperties 来接配置属性。

推荐使用 lombok

当然这是一个有争议的问题，我的习惯是使用它省去 getter、setter、toString 等等。

不要在 AService 调用 BMapper

我们一定要遵循从 AService -> BService -> BMapper，如果每个 Service 都能直接调用其他的 Mapper，那特么还要其他 Service 干嘛？老项目还有从 controller 调用 mapper 的，把控制器当 service 来处理了。。。

尽量少写工具类

为什么说要少写工具类，因为你写的大部分工具类，在你无形中引入的 jar 包里面就有，String 的，Assert 断言的，IO 上传文件，拷贝流的，Bigdecimal 的等等。自己写容易错还要加载多余的类。

不要包裹 OpenFeign 接口返回值

搞不懂为什么那么多人喜欢把接口的返回值用 Response 包装起来......加个 code、message、success 字段，然后每次调用方就变成这样

CouponCommonResult bindResult = couponApi.useCoupon(request.getCustomerId(), order.getLoanId(), coupon.getCode());
if (Objects.isNull(bindResult) || !bindResult.getResult()) {
  throw new AppException(CouponErrorCode.ERR_REC_COUPON_USED_FAILED);
}

这样就相当于

1. 在 coupon-api 抛出异常

2. 在 coupon-api 拦截异常，修改 Response.code

3. 在调用方判断 response.code 如果是 FAIELD 再把异常抛出去......

你直接在服务提供方抛异常不就行了么。。。而且这样一包装 HTTP 请求永远都是 200，没法做重试和监控。当然这个问题涉及到接口响应体该如何设计，目前网上大多是三种流派

• 接口响应状态一律 200

• 接口响应状态遵从HTTP真实状态

• 佛系开发，领导怎么说就怎么做

不接受反驳，我推荐使用 HTTP 标准状态。特定场景包括参数校验失败等一律使用 400 给前端弹 toast。下篇文章会阐述一律 200 的坏处。

写有意义的方法注释

这种注释你写出来是怕后面接手的人瞎么......

/**
* 请求电话验证
*
* @param credentialNum
* @param callback
* @param param
* @return PhoneVerifyResult
*/

要么就别写，要么就在后面加上描述......写这样的注释被 IDEA 报一堆警告看着蛋疼

和前端交互的 DTO 对象命名

什么 VO、BO、DTO、PO 我倒真是觉得没有那么大必要分那么详细，至少我们在和前端交互的时候类名要起的合适，不要直接用映射数据库的类返回给前端，这会返回很多不必要的信息，如果有敏感信息还要特殊处理。

推荐的做法是接受前端请求的类定义为 XxxRequest，响应的定义为 XxxResponse。以订单为例：接受保存更新订单信息的实体类可以定义为 OrderRequest，订单查询响应定义为 OrderResponse，订单的查询条件请求定义为 OrderQueryRequest。

尽量别让 IDEA 报警

我是很反感看到 IDEA 代码窗口一串警告的，非常难受。因为有警告就代表代码还可以优化，或者说存在问题。 前几天捕捉了一个团队内部的小bug，其实本来和我没有关系，但是同事都在一头雾水的看外面的业务判断为什么走的分支不对，我一眼就扫到了问题。

因为 java 中整数字面量都是 int 类型，到集合中就变成了 Integer，然后 stepId 点上去一看是 long 类型，在集合中就是 Long，那这个 contains 妥妥的返回 false，都不是一个类型。

你看如果注重到警告，鼠标移过去看一眼提示就清楚了，少了一个生产 bug。

尽可能使用新技术组件

我觉得这是一个程序员应该具备的素养......反正我是喜欢用新的技术组件，因为新的技术组件出现必定是解决旧技术组件的不足，而且作为一个技术人员我们应该要与时俱进~~ 当然前提是要做好准备工作，不能无脑升级。举个最简单的例子，Java 17 都出来了，新项目现在还有人用 Date 来处理日期时间......

结语

本篇文章简单介绍我日常开发的习惯，当然仅是作者自己的见解。暂时只想到这几点，以后发现其他的会更新。

作者：暮色妖娆丶
来源：https://juejin.cn/post/7072252275002966030

在分布式、微服务盛行的今天，绝大部分项目都采用的微服务框架，前后端分离方式。题外话：前后端的工作职责越来越明确，现在的前端都称之为大前端，技术栈以及生态圈都已经非常成熟；以前后端人员瞧不起前端人员，那现在后端人员要重新认识一下前端，前端已经很成体系了。

一般系统的大致整体架构图如下：

需要说明的是，有些小伙伴会回复说，这个架构太简单了吧，太low了，什么网关啊，缓存啊，消息中间件啊，都没有。因为老顾这篇主要介绍的是API接口，所以我们聚焦点，其他的模块小伙伴们自行去补充。

接口交互

前端和后端进行交互，前端按照约定请求URL路径，并传入相关参数，后端服务器接收请求，进行业务处理，返回数据给前端。

针对URL路径的restful风格，以及传入参数的公共请求头的要求（如：app_version,api_version,device等），老顾这里就不介绍了，小伙伴们可以自行去了解，也比较简单。

着重介绍一下后端服务器如何实现把数据返回给前端？

返回格式

后端返回给前端我们一般用JSON体方式，定义如下：

{
    #返回状态码
    code:integer,       
    #返回信息描述
    message:string,
    #返回值
    data:object
}

CODE状态码

code返回状态码，一般小伙伴们是在开发的时候需要什么，就添加什么。
如接口要返回用户权限异常，我们加一个状态码为101吧，下一次又要加一个数据参数异常，就加一个102的状态码。这样虽然能够照常满足业务，但状态码太凌乱了

我们应该可以参考HTTP请求返回的状态码，下面是常见的HTTP状态码：

200 - 请求成功
301 - 资源（网页等）被永久转移到其它URL
404 - 请求的资源（网页等）不存在
500 - 内部服务器错误

我们可以参考这样的设计，这样的好处就把错误类型归类到某个区间内，如果区间不够，可以设计成4位数。

#1000～1999 区间表示参数错误
#2000～2999 区间表示用户错误
#3000～3999 区间表示接口异常

这样前端开发人员在得到返回值后，根据状态码就可以知道，大概什么错误，再根据message相关的信息描述，可以快速定位。

Message

这个字段相对理解比较简单，就是发生错误时，如何友好的进行提示。一般的设计是和code状态码一起设计，如

再在枚举中定义，状态码

状态码和信息就会一一对应，比较好维护。

Data

返回数据体，JSON格式，根据不同的业务又不同的JSON体。
我们要设计一个返回体类Result

控制层Controller

我们会在controller层处理业务请求，并返回给前端，以order订单为例

我们看到在获得order对象之后，我们是用的Result构造方法进行包装赋值，然后进行返回。小伙伴们有没有发现，构造方法这样的包装是不是很麻烦，我们可以优化一下。

美观优化

我们可以在Result类中，加入静态方法，一看就懂

那我们来改造一下Controller

代码是不是比较简洁了，也美观了。

优雅优化

上面我们看到在Result类中增加了静态方法，使得业务处理代码简洁了。但小伙伴们有没有发现这样有几个问题：

1、每个方法的返回都是Result封装对象，没有业务含义

2、在业务代码中，成功的时候我们调用Result.success，异常错误调用Result.failure。是不是很多余

3、上面的代码，判断id是否为null，其实我们可以使用hibernate validate做校验，没有必要在方法体中做判断。

我们最好的方式直接返回真实业务对象，最好不要改变之前的业务方式，如下图

这个和我们平时的代码是一样的，非常直观，直接返回order对象，这样是不是很完美。那实现方案是什么呢？

实现方案

小伙伴们怎么去实现是不是有点思路，在这个过程中，我们需要做几个事情

1、定义一个注解@ResponseResult，表示这个接口返回的值需要包装一下

2、拦截请求，判断此请求是否需要被@ResponseResult注解

3、核心步骤就是实现接口ResponseBodyAdvice和@ControllerAdvice，判断是否需要包装返回值，如果需要，就把Controller接口的返回值进行重写。

注解类

用来标记方法的返回值，是否需要包装

拦截器

拦截请求，是否此请求返回的值需要包装，其实就是运行的时候，解析@ResponseResult注解

此代码核心思想，就是获取此请求，是否需要返回值包装，设置一个属性标记。

重写返回体

上面代码就是判断是否需要返回值包装，如果需要就直接包装。这里我们只处理了正常成功的包装，如果方法体报异常怎么办？处理异常也比较简单，只要判断body是否为异常类。

怎么做全局的异常处理，篇幅原因，老顾这里就不做介绍了，只要思路理清楚了，自行改造就行。

重写Controller

在控制器类上或者方法体上加上@ResponseResult注解，这样就ok了，简单吧。到此返回的设计思路完成，是不是又简洁，又优雅。

总结

这个方案还有没有别的优化空间，当然是有的。如：每次请求都要反射一下，获取请求的方法是否需要包装，其实可以做个缓存，不需要每次都需要解析。

作者：码农出击HK
来源：https://juejin.cn/post/7068884412674342926

计算机网络把各地的计算机连接了起来，只要有一台可以上网的终端，比如手机、电脑，就可以访问互联网上任何一台服务器的资源（包括静态资源和动态的服务）。

作为开发者的我们，就是这些资源、服务的提供者，把资源上传到服务器，并把服务跑起来的过程就叫做部署。

代码部分的部署，需要先经过构建，也就是编译打包的过程，把产物传到服务器。

最原始的部署方式就是在本地进行 build，然后把产物通过 FTP 或者 scp（基于 SSH 的远程拷贝文件拷贝） 传到服务器上，如果是后端代码还需要重启下服务。

每个人单独构建上传，这样不好管理，也容易冲突，所以现在都会用专门的平台来做这件事构建和部署，比如 jenkins。

我们代码会提交到 gitlab 等代码库，然后 jenkins 从这些代码库里把代码下载下来进行 build，再把产物上传到服务器上。

流程和直接在本地构建上传差不多，只不过这样方便管理冲突、历史等，还可以跨项目复用一些东西。

构建、部署的过程最开始是通过 shell 来写，但写那个的要求还是很高的。后来就支持了可视化的编排，可以被编排的这个构建、部署的流程叫做流水线 pipeline。

比如这是 jenkins 的 pipeline 的界面：

除了构建、部署外，也可以加入一些自动化测试、静态代码检查等任务。

这种自动化了的构建、部署流程就叫做 CI（持续集成）、CD（持续部署）。

我们现在还是通过 scp / FTP 来上传代码做的部署，但是不同代码的运行环境是不同的，比如 Node.js 服务需要安装 node，Java 服务需要安装 JRE 等，只把代码传上去并不一定能跑起来。

那怎么办呢？怎么保证部署的代码运行在正确的环境？

把环境也给管理起来，作为部署信息的一部分不就行了？

现在流行的容器技术就是做这个的，比如 docker，可以把环境信息和服务启动方式放到 dockerfile 里，build 产生一个镜像 image，之后直接部署这个 docker image 就行。

比如我们用 nginx 作为静态服务器的时候，dockerfile 可能是这样的：

FROM nginx:alpine

COPY /nginx/ /etc/nginx/

COPY  /dist/ /usr/share/nginx/html/

EXPOSE 80

这样就把运行环境给管理了起来。

所以，现在的构建产物不再是直接上传服务器，而是生成一个 docker image，上传到 docker registry，然后把这个 docker image 部署到服务器。

还有一个问题，现在前端代码、后端代码都部署在了我们的服务器上，共享服务器的网络带宽，其中前端代码是不会变动的、流量却很大，这样使得后端服务的可用带宽变小、支持的并发量下降。

能不能把这部分静态资源的请求分离出去呢？最好能部署到离用户近一点的服务器，这样访问更快。

确实可以，这就是 CDN 做的事情。

网上有专门的 CDN 服务提供商，它们有很多分散在各地的服务器，可以提供静态资源的托管。这些静态资源最终还是从我们的静态资源服务器来拿资源的，所以我们的静态资源服务器叫做源站。但是请求一次之后就会缓存下来，下次就不用再请求源站了，这样就减轻了我们服务器的压力，还能加速用户请求静态资源的速度。

这样就解决了静态资源分去了太多网络带宽的问题，而且还加速了资源的访问速度。

此外，静态资源的部署还要考虑顺序问题，要先部署页面用到的资源，再部署页面，还有，需要在文件名加 hash 来触发缓存更新等，这些都是更细节的问题。

这里说的都是网页的部署方式，对于 APP/小程序它们是有自己的服务器和分发渠道的，我们构建完之后不是部署，而是在它们的平台提交审核，审核通过之后由它们负责部署和分发。

总结

互联网让我们能够用手机、PC 等终端访问任何一台服务器的资源、服务。而提供这些资源、服务就是我们开发者做的事情。把资源上传到服务器上，并把服务跑起来，就叫做部署。

对于代码，我们可以本地构建，然后把构建产物通过 FTP/scp 等方式上传到服务器。

但是这样的方式不好管理，所以我们会有专门的 CI/CD 平台来做这个，比如 jenkins。

jenkins 支持 pipeline 的可视化编排，比写 shell 脚本的方式易用很多，可以在构建过程中加入自动化测试、静态代码检查等步骤。

不同代码运行环境不同，为了把环境也管理起来，我们会使用容器技术，比如 docker。把环境信息写入 dockerfile，然后构建生成 docker image，上传到 registry，之后部署这个 docker image 就行。

静态资源和动态资源共享服务器的网络带宽，为了减轻服务器压力、也为了加速静态资源的访问，我们会使用 CDN 来对静态资源做加速，把我们的静态服务器作为源站。第一个静态资源的请求会请求源站并缓存下来，之后的请求就不再需要请求源站，这样就减轻了源站的压力。此外，静态资源的部署还要考虑顺序、缓存更新等问题。

对于网页来说是这样，APP/小程序等不需要我们负责部署，只要在它们的平台提交审核，然后由它们负责部署和分发。

当我们在谈部署的时候，主要就是在谈这些。

作者：zxg_神说要有光
来源：https://juejin.cn/post/7073826878858985479

软件版本阶段说明

• Alpha版

  此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改

• Beta版

  版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI

• RC版

  该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几

• Release版:

  该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(R)

在上面我们大致了解了软件从开发到交付会经历4个版本阶段，而当我们开始搭建一个新项目时，不可避免地要配置 package.json 文件，这个 version 怎么命名呢？

// package.json
{
    "name": "项目名称",
    "version": "0.1.0",
    "description": "项目描述",
    "author": "项目作者",
    "license": "MIT",
}

版本命名规范

在说版本命名规范之前，先说说比较流行的版本命名格式

• GNU 风格

• Windows 风格

• .Net Framework 风格

最常见的版本命名格式就是 GNU 风格，下面以 GNU 风格展开说明

主版本号.子版本号.修正（或阶段）版本号.日期版本号_希腊字母版本号

希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release

版本命名修改规则

项目初版本时，版本号可以为 0.1.0

• 希腊字母版本号(beta)

  此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号

• 日期版本号

  用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号（只有此版本号才可由开发人员决定是否修改）

• 修正（或阶段）版本号改动

  当项目在进行了局部修改或bug修正时，主版本号和子版本号都不变，修正版本号加1

  // package.json
  {
      "name": "项目名称",
      "version": "0.1.0",
      "version": "0.1.1",
  }

• 子版本号改动

  当项目在原有基础上增加了某些功能模块时，比如增加了对权限控制、增加自定义视图等功能，主版本号不变，子版本号加1，修正版本号复位为0

  // package.json
  {
      "name": "项目名称",
      "version": "0.1.8",
      "version": "0.2.0",
  }

• 主版本号改动

  当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，比如增加多个模块或者重构，主版本号加 1

  // package.json
  {
      "name": "项目名称",
      "version": "0.1.0",  // 一期项目
      "version": "1.1.0",  // 二期项目
      "version": "2.1.0",  // 三期项目
  }

文件命名规范

文件名称由四部分组成：第一部分为项目名称，第二部分为文件的描述，第三部分为当前软件的版本号，第四部分为文件阶段标识加文件后缀

例如：xx后台管理系统测试报告1.1.1.031222_beta_d.xls，此文件为xx后台管理系统的测试报告文档，版本号为：1.1.1.031222_beta

• 如果是同一版本同一阶段的文件修改过两次以上，则在阶段标识后面加以数字标识，每次修改数字加1，xx后台管理系统测试报告1.1.1.031222_beta_d1.xls

• 当有多人同时提交同一份文件时，可以在阶段标识的后面加入人名或缩写来区别，例如：xx后台管理系统测试报告 1.1.1.031222_beta_d_spp.xls。当此文件再次提交时也可以在人名或人名缩写的后面加入序号来区别，例如：xx后台管理系统测试报告1.1.1.031222_beta_d_spp2.xls

阶段标识

软件的每个版本中包括11个阶段，详细阶段描述如下：

作者：Jesse90s
来源：https://juejin.cn/post/7073902470585384990

题目描述

旧键盘上坏了几个键，于是在敲一段文字的时候，对应的字符就不会出现。现在给出应该输入的一段文字、以及实际被输入的文字，请你列出肯定坏掉的那些键。

输入格式

输入在 2 行中分别给出应该输入的文字、以及实际被输入的文字。每段文字是不超过 80 个字符的串，由字母 A-Z（包括大、小写）、数字 0-9、以及下划线 _（代表空格）组成。题目保证 2 个字符串均非空。

输出格式：

按照发现顺序，在一行中输出坏掉的键。其中英文字母只输出大写，每个坏键只输出一次。题目保证至少有 1 个坏键。

输入样例：

7_This_is_a_test
_hs_s_a_es

输出样例：

7TI

思路分析

这道题用哈希表标记输入状态的话会很简单，我就是把字符串中所有字符的ASCII码值映射到数组下标中去，0为未输入，1为已输入。
先将第二个字符串所有字符标记（因为是第二个字符串少了字符），为了方便进行比较和后面的输出，我在标记之前将所有字符统一全部转换成了大写字母
然后再遍历第一个字符串，把所有第一个字符串中存在而第二个字符串里不存在的字符输出，也就是第二个字符串里缺少的字符，不要忘了输出完标记为-1，不然会重复输出哦
PS:其实我刚开始的思路也不是用哈希表，是想用两层循环把两个字符串一个一个字符比较输出，但是还没能实现只输出一遍

AC代码

版本一

#include<bits/stdc++.h>
using namespace std;
int main()
{
    int keyboard[128]={0};//下标映射为ASCII码值，0：未输入，1：已输入
    string s1,s2;
    cin>>s1>>s2;
    for(char c2:s2)
        keyboard[toupper(c2)]=1;//已输入标记为1
    for(char c1:s1)
        if(keyboard[toupper(c1)]==0)
        {
            putchar(toupper(c1));
            keyboard[toupper(c1)]=-1;//该字符已输出，标记为-1，避免重复输出
        }
    return 0;
}

版本2

#include <ctype.h>
#include<iostream>
#include <string>
using namespace std;
int main()
{
    int keyboard[128] = {0};
    string s1;
    char c2;
    getline(cin, s1);//因为后面换行之后还要输入字符所以不能直接用cin
    while((c2 = getchar()) != '\n')//输入第二行字符串
        keyboard[toupper(c2)] = 1;

    for(char c1:s1)
        if(keyboard[toupper(c1)] == 0)
    {
            putchar(toupper(c1));
            keyboard[toupper(c1)] = -1;
        }
    return 0;
}

总结

用了一次Hash表，感觉也没有想象的那么困难嘛
看书上写的哈希散列可真是头疼，自己用一了遍反而好像也不难😂
真是纸上得来终觉浅，觉知此事要躬行。

作者：梦境无限
来源：https://juejin.cn/post/7074090679198023688

一、题目描述：

一种很奇怪的电梯，大楼的每一层楼都可以停电梯，而且第 i 层楼（1 ≤ i ≤ N）上有一个数字 Ki （0 ≤ Ki ≤ N）。电梯只有四个按钮：开，关，上，下。上下的层数等于当前楼层上的那个数字。当然，如果不能满足要求，相应的按钮就会失灵。例如： 3, 3, 1, 2, 5 代表了 Ki（K1=3, K2=3，……），从 1 楼开始。在 1 楼，按“上”可以到 4 楼，按“下”是不起作用的，因为没有 -2 楼。那么，从 A 楼到 B 楼至少要按几次按钮呢？

来源：洛谷 http://www.luogu.com.cn/problem/P11…

输入格式

共二行。 第一行为三个用空格隔开的正整数，表示 N, A, B（1≤N≤200，1≤A,B≤N ）。 第二行为 N 个用空格隔开的非负整数，表示 Ki。

5 1 5
3 3 1 2 5

输出格式

一行，即最少按键次数，若无法到达，则输出 -1。

3

二、思路分析：

首先看一下输入数据是什么意思，首先输入一个N, A, B，也就是分别输入楼层数（N）、开始楼层（A）、 终点楼层（B）。 在例子中，我们的 楼层数N是5，也就是说有5层楼，第二行就是这5层楼的每层楼的数字k。

1、题目中说到只有四个按钮：开，关，上，下，上下的层数等于当前楼层上的那个数字，众所周知，电梯的楼层到了的时候啊，它是会自动打开的，没有人进来的时候，也会自动关上，这里求的是最少按几个按钮，所以我们在这里不用看开关，也就是可以看作该楼层只有两个按钮 +k 、 -k

2、题目中提到最少按几次，很明显，这是一个搜索题。当出现最少的时候，我们就可以考虑用广搜了（也可以用深搜做的啦）

3、这里注意一下，就是我们在不同的按钮次数时遇到停在同一楼层，这时候就会出现一个重复的且没有必要的搜索，所以我们需要在搜索的时候加个条件。

三、AC 代码：

import java.util.*;

public class Main {
    public static void main(String[] args) {
        Scanner sr = new Scanner (System.in);
        int N = sr.nextInt();              
        int A = sr.nextInt();             
        int B = sr.nextInt();              
        
        // 广搜必备队列
        Queue<Fset> Q = new LinkedList<Fset>();
        // 一个记忆判断，看看这层楼是不是来过
        boolean[] visit = new boolean[N+1];
        // 来存楼梯按钮的，假设第3层的k是2，  那么 k[3][0]=2 (向上的按钮)、 k[3][1]=-2 (向下的按钮)
        int[][] k = new int [N+1][2];
        for(int i = 1 ; i <= N ; i++){
            k[i][0] = sr.nextInt();
            k[i][1] = -k[i][0];
        }   
        
        // 存一个起始楼层和按钮次数到队列
        Q.add(new Fset(A,0));
        // 当队列为空也就是所以能走的路线都走过了，没有找到就可以返回-1了
        while(!Q.isEmpty()){ 
            Fset t = Q.poll();
            // 找到终点楼层，不用找了直接输出并退出搜索
            if(t.floor == B){ 
                System.out.println(t.count);
                return;
            }
            // 
            for(int j = 0 ; j < 2 ; j++){
                // 按键后到的楼层
                int f = t.floor + k[t.floor][j];
                // 判断按键后到的楼层是否有效和是否走过
                if(f >= 1 && f <= N && visit[f]!=true) {
                    Q.add(new Fset(f,t.count+1));
                    // 做标记
                    visit[f]=true;
                }  
            }
        }
        // 没找到
        System.out.println(-1);
    }
}

class Fset{
    int floor; // 当前楼层
    int count; // 当前按键次数
    public Fset(int floor, int count) {
        this.floor = floor; 
        this.count = count;
    }
}