关于后端:悄咪咪提高团队幸福感-Surprise

6次阅读

共计 6606 个字符，预计需要花费 17 分钟才能阅读完成。

本文的灵感是在几个月以前工作不忙（摸鱼）时想到的，老是本人一个人往前冲冲冲也没啥意思，须要想一点方法，来进步团队的效率，进步团队的幸福感（效率起来了，单位工夫内代码写的更多，那不就幸福啦 ????），通过几个月的摸索，总结出了几个小点，如果大家有更好的形式，欢送一起探讨~

我司的产品次要分为 Saas 端和公有平台，别离部署在公网和客户的公有环境，先来说说公有环境的问题：不晓得真正部署的我的项目版本，说来很可笑，运维同学在部署的时候必定是记录过各个客户的代码版本的，但也就是这么可笑，有时候就是会弄错，可能是因为降级流程不够欠缺，或者工作失误等等，总之，想个办法解决。

人靠不住，但还有代码。Git曾经成为代码治理的事实标准，这就不多说了，即然人治理不好版本，那还是从 Git 自身动手吧，悄咪咪的给所有我的项目依赖（POM.XML）减少一个插件：

<!-- Git Version 插件 -->
<plugin>
    <groupId>pl.project13.maven</groupId>
    <artifactId>git-commit-id-plugin</artifactId>
    <version>4.0.0</version>
    <executions>
        <execution>
            <id>get-the-git-infos</id>
            <phase>initialize</phase>
            <goals>
                <goal>revision</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <dotGitDirectory>${project.basedir}/.git</dotGitDirectory>
        <verbose>false</verbose>
        <dateFormat>yyyy-MM-dd HH:mm:ss</dateFormat>
        <prefix>git</prefix>
        <generateGitPropertiesFile>true</generateGitPropertiesFile>
        <generateGitPropertiesFilename>${project.build.outputDirectory}/${project.name}.build.json</generateGitPropertiesFilename>
        <format>json</format>
        <gitDescribe>
            <skip>false</skip>
            <always>false</always>
            <dirty>-dirty</dirty>
        </gitDescribe>
    </configuration>
</plugin>

插件将会在每次构建时生成一个版本相干文件，内容如下：

{
  "git.branch" : "master",
  "git.build.host" : "Kerwin",
  "git.build.time" : "2020-08-12 23:24:59",
  "git.build.user.email" : "34807944+kkzhilu@users.noreply.github.com",
  "git.build.user.name" : "kkzhilu",
  "git.build.version" : "1.0.0-SNAPSHOT",
  "git.closest.tag.commit.count" : "","git.closest.tag.name":"",
  "git.commit.id" : "4981afb5dfeee6f835dcf9a7a135083d8e973090",
  "git.commit.id.abbrev" : "4981afb",
  "git.commit.id.describe" : "4981afb",
  "git.commit.id.describe-short" : "4981afb",
  "git.commit.message.full" : "Commit git-version",
  "git.commit.message.short" : "Commit git-version",
  "git.commit.time" : "2020-08-04 18:18:47",
  "git.commit.user.email" : "34807944+kkzhilu@users.noreply.github.com",
  "git.commit.user.name" : "kexianming",
  "git.dirty" : "false",
  "git.local.branch.ahead" : "0",
  "git.local.branch.behind" : "0",
  "git.remote.origin.url" : "https://github.com/kkzhilu/KerwinBoots.git",
  "git.tags" : "","git.total.commit.count":"9"
}

插件名字叫：git-commit-id-plugin，至于细节应用就本人去搜寻啦，它能够实现的成果即在每次打包时生成相应的 Git 相干信息，这样无论运维同学是否把代码升错，咱们都能够晓得 代码到底是什么版本

当前终于听不到共事之间因为代码版本扯皮的事件了????

回到刚刚说的 Saas 端生产环境，因为各种起因，咱们团队常常须要保护不是本人写的我的项目，很多时候一些细节逻辑齐全摸不着头脑，而且没有日志，最要命的是在测试环境还不复现，肿么办？

以前的解决方案是各种喊人，而后硬看代码寻找上下文，尽可能的找到蛛丝马迹，总之效率十分感人，解决的慢了就是一个事变，全员挨批评，咋办呢？我就始终在寻找这种问题的解决办法，终于我发现了一个神器：Arthas

用过这个工具的人就晓得它有多弱小，阿里出品，官网文档链接：https://arthas.gitee.io/comma…

咱们能够通过其提供的局部命令，如：tt，获取办法执行数据的时空隧道，它能够记录下指定办法每次调用的入参和返回信息 ，想想它的帮忙有多大， 记录每一个办法的入参和出参，如果真遇上没日志的状况，晓得这些信息其实配合代码就能够很快定位问题了，所以，听过没用过的敌人，都去试试吧，真的很无敌。

下次共事有难时，你就用这个工具去帮他，他说不定会请你吃顿饭????

这个问题是因为之前共事重写了一块业务逻辑，后果线上展示层耗时大略 30s，oh，天哪！在测试环境明明是一瞬间的，咋办？

造成这种问题的起因，必定是 SQL 写的不好，或者业务解决哪里做了很多不必要的动作（咱们没有灰度测试），然而生产环境又不能轻易动，也不能断点调试，从日志也只能看到耗时很长，然而慢在哪里不晓得。

当一个办法外面通过了 N 个外部办法后，你不晓得到底是哪一个导致这么长的耗时，当无奈复现的时候怎么办呢？其实还是利用下面的那个工具 Arthas，还是一样的命令tt，它不仅能够记录入参和出参信息， 还能够记录每一个办法的耗时，如许的弱小。

所以我是为了再次揭示，这些性能只是 Arthas 的一点皮毛，咱们要学会正当应用开源工具

正文是文字，难以表白如流程图个别的成果，所以该怎么办呢？我找到了两种解决方案，目前在我的项目中应用成果十分之好，第一钟是利用ASCII 正文工具，该工具的地址：http://asciiflow.com/

成果如下：

正文如下：

+-------------------------------+
|                               |
|  +-------------------------+  |
|  |                         |  |
|  |           Demo          |  |
|  |                         |  |
|  |                         |  |
|  +------------+------------+  |
|               |               |
|               |               |
|               |               |
|               |               |
|               |               |
|               |               |
|               |               |
|               |               |
|               |               |
|               +------> False  |
|               |               |
|               |               |
|    True   <---+               |
|                               |
+-------------------------------+

这玩意画进去的图是能够间接复制成文本的，管制好尺寸就能够解决大部分状况，也能够设想之前网上有一些很奇葩的正文是不是就是用这个工具或者同样的原理画进去的，附上一副之前文章缺的一张图：

上亿数据怎么玩深度分页？兼容 MySQL + ES + MongoDB：https://juejin.im/post/685003…

这篇文章写完的时候，我本人计划的图还没画好，所以很多敌人问我用 id 实现不了什么的，这次就顺便展现一下我的计划

解决方案之二，利用 MarkDown 的原生画图性能，我不晓得要公布文章的平台支不反对，所以用截图来代替了（Typora 反对）

不晓得的同学搜一下，MarkDown绘图语法，拿一个适宜的改就好了，没必要专门去学，放到代码里看看成果：

有一个小 Tips，应用 IDEA 的时候， 利用鼠标滚动键能够按块复制，这样一来能够间接复制到指定的正文内容 ，而后把它复制到任何一个失常的MarkDown 工具里，就能够展现流程图了，几乎不要太完满，想测试的敌人能够复制以下代码去一些工具里试试，须要设置代码品种为：mermaid

 sequenceDiagram
    Note over Boot: 启动类
    Note over PDFThread: 线程类
    Note over PDFWorker: 执行类
      Boot->>PDFThread: Boot 类启动线程
    PDFThread->>PDFWorker: 线程类调用真正工作 Worker
    loop 队列解决
        PDFThread->PDFThread: 思考胜利与失败状况解决计划
    end
    
    PDFWorker-->>PDFThread: Worker 响应执行后果
    Note right of PDFWorker: 留神参数校验 <br/> 文件格式校验

你将来的共事保护代码的时候会爱上你，如果是女生，可能还会嫁给你????

空想有一天你老大跑过来问你，你这写的正文都是些什么玩意，而后你一复制一粘贴，一张图就进去了！下次涨薪会没有你？

（反正我涨了，还不少????）

PS：我思考写一个反对间接复制而后渲染成流程图的IDEA 插件，如果有现成的请分割我，就省的我去写了，嘿嘿✌

咱们公司没有专门的 DBA，所以SQL 语句的品质只把握在开发和开发组长的手上，有时候事件多，或者不仔细，或者模块不是很重要就容易大意，到了生产环境出大问题，针对这种状况的解决方案仍然是寻找工具，比方，我盯上了 小米的 `Soar

我的项目地址：https://github.com/XiaoMi/soar

官网的介绍：

跨平台反对
目前只反对 MySQL 语法族协定的 SQL 优化
反对基于启发式算法的语句优化
反对简单查问的多列索引优化（UPDATE、INSERT、DELETE、SELECT）

贴个图片展现一下成果：

这款工具能够进行对 SQL 进行打分，同时提供一些倡议，它的能力下限咱们还没有摸索进去，然而上限还是能够必定的，因而之后只须要关注索引是否正确应用，其余的就交给这个工具吧，低于 90 分，就改！

PS：这个开源我的项目举荐应用 docker 装置，简略粗犷无脑省工夫，命令如下：

# 装置镜像
docker pull becivells/soar-web

# 运行
docker run -d --name Soar-web -p 5077:5077 becivells/soar-web

想着有个工具会查看 SQL 品质了，是不是写的时候也认真多啦，幸福感提醒满满，哈哈~????

方案设计的文档不可能由工具去写，然而简略的数据库字段映射，或者接口文档总不须要开发去写吧？也是一样摸索摸索，找到了几个不太适宜然而靠边的开源我的项目，如：

apidoc：https://github.com/apidoc/apidoc

RESTful web API Documentation Generator.

JApiDocs：https://github.com/YeDaxia/JA…

A magical api documentation generator without annotation for springboot.

APIAuto：https://github.com/TommyLemon…

机器学习测试、主动生成代码、主动动态查看、主动生成文档与正文等，做最先进的接口管理工具

因为每个我的项目的状况不同，然而我又不想做大的改变，所以只能说是靠边，不能百分百适宜，但有了这些开源我的项目，我就能够改写其中的代码，让它适应以后我的项目的正文计划等等，总是，能节俭相当一部分的编写文档的工夫

这个确实是个大坑，谁让咱们是 CRUD 程序员呢，常常须要写重复性相当高，然而又有一点不同的代码，这里我的解决方案是利用模板 + 更适合的工具解决，如果只是数据库操作层反复代码多，咱们齐全能够利用 mybatis-plus 工具缩小反复代码，又或者写出 公共的操作层 缩小反复代码。

当用工具完不成的时候，我就会用上模板了，比方间接我写过一个简略的开源我的项目：

如同很厉害的生成器！一秒钟搞定一个我的项目：https://juejin.im/post/684490…

外围思路和要求如下：

基于数据库获取原始数据
基于模板 + 原始数据生成可运行的 SpringBoot 我的项目，反对界面 + 根本增删改查
提供拓展式接口，能够实现不批改代码生成全新的文件

那利用这种思路，其实齐全能够写一套更凋谢的代码生成模板，比方依据传递的 JSON 报文去解析数据，依据传递的 模板 去生成数据，这样的话又能够解决相当大一部分的反复工具，你，值得领有。

PS：同理，其实数据库字段映射文档也能够用这种形式，只须要一秒钟，几乎不要太难受????‍♂️

这个其实大家都无意识，然而有时候就是感觉可能用的不多，真要用起来的时候又没功夫去写脚本，比方进入一个 docker 容器，如果用命令行的话，至多要经验两步代码，十几秒的工夫，如果写一个脚本呢，当前进入容器只须要一秒钟，所以我给团队写了不少这种脚本，其实我一开始也不会，反正就复制来一个改一改就行，如下是进入 docker 容器 的

# 应用阐明，用来提醒输出参数
usage() {echo "Usage: sh 执行脚本.sh [rpcapp|tomcat|nginx|mysql]"
    exit 1
}

rpcapp(){DOCKER_ID=$(docker ps | grep "rpcapp" | awk '{print $1}')
  docker exec -it $DOCKER_ID bash
}

tomcat(){DOCKER_ID=$(docker ps | grep "tomcat" | awk '{print $1}')
  docker exec -it $DOCKER_ID bash
}

nginx(){DOCKER_ID=$(docker ps | grep "nginx" | awk '{print $1}')
  docker exec -it $DOCKER_ID bash
}

mysql(){DOCKER_ID=$(docker ps | grep "mysql" | awk '{print $1}')
  docker exec -it $DOCKER_ID bash
}

#依据输出参数，抉择执行对应办法，不输出则执行应用阐明
case "$1" in
  "rpcapp")
    rpcapp
    ;;
  "tomcat")
    tomcat
    ;;
  "nginx")
    nginx
    ;;
  "mysql")
    mysql
    ;;
  *)
    usage
    ;;
esac

从网上找了找，又找到一个开源我的项目用以记录罕用的脚本

useful-scripts：https://github.com/oldratlee/…

能主动的就不要每次都手写啦，节约工夫去摸鱼不高兴吗????

这可是我这么久以来总结的工夫治理神器，节俭的工夫拿去摸鱼学习，循环促成效率和能力，造成良性正反馈

这还不值得 来个赞???????????? 吗？嘿嘿~

另外能够搜寻公众号「是 Kerwin 啊」，一起提高！

也能够查看 Kerwin 的 GitHub 主页，关注一个小白程序员的提高，这货最近在折腾 Go~

正文完

后端

发表至：后端

2020-08-13

0

关于后端:锁屏面试题百日百刷Spark篇二十

关于后端:elasticsearch中使用bucket-script进行聚合

关于后端:Redis类型Type与编码Encoding

关于后端:MySQL-数据库索引技术原理初探

关于算法:int数值交换的几种方法

关于后端:悄咪咪提高团队幸福感-Surprise

前言

永恒解决不晓得是什么版本

永恒解决没打日志怎么办的问题

永恒解决哪里耗时这么长的问题

正文无奈表白流程图成果的解决方案

垃圾 SQL 的解决方案

懒得写文档的解决方案

重复性代码的解决方案

重复性的操作用脚本代码

最初

站内搜索