悄咪咪提升團隊幸福感 & Surprise!

前言

本文的靈感是在幾個月之前工做不忙(摸魚)時想到的,總是本身一我的往前沖沖衝也沒啥意思,須要想一點辦法,來提升團隊的效率,提升團隊的幸福感(效率起來了,單位時間內代碼寫的更多,那不就幸福啦 😜),通過幾個月的摸索,總結出了幾個小點,若是你們有更好的方式,歡迎一塊兒討論~html

<br/>mysql

永久解決不知道是什麼版本

我司的產品主要分爲Saas端和私有平臺,分別部署在公網和客戶的私有環境,先來講說私有環境的問題:不知道真正部署的項目版本,說來很好笑,運維同窗在部署的時候確定是記錄過各個客戶的代碼版本的,但也就是這麼好笑,有時候就是會弄錯,多是因爲升級流程不夠完善,或者工做失誤等等,總之,想個辦法解決。nginx

<br/>git

人靠不住,但還有代碼。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>

插件將會在每次構建時生成一個版本相關文件,內容以下:github

{
  "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相關信息,這樣不管運維同窗是否把代碼升錯,咱們均可以知道代碼究竟是什麼版本web

之後終於聽不到同事之間由於代碼版本扯皮的事情了🤪算法

<br/>spring

永久解決沒打日誌怎麼辦的問題

回到剛剛說的Saas端生產環境,因爲各類緣由,咱們團隊常常須要維護不是本身寫的項目,不少時候一些細節邏輯徹底摸不着頭腦,並且沒有日誌,最要命的是在測試環境還不復現,腫麼辦?sql

<br/>

之前的解決方案是各類喊人,而後硬看代碼尋找上下文,儘量的找到蛛絲馬跡,總之效率很是感人,處理的慢了就是一個事故,全員挨批評,咋辦呢?我就一直在尋找這種問題的解決辦法,終於我發現了一個神器:Arthas

<br/>

用過這個工具的人就知道它有多強大,阿里出品,官方文檔連接:https://arthas.gitee.io/comma...

咱們能夠經過其提供的部分命令,如:tt獲取方法執行數據的時空隧道,它能夠記錄下指定方法每次調用的入參和返回信息,想一想它的幫助有多大,記錄每個方法的入參和出參,若是真趕上沒日誌的狀況,知道這些信息其實配合代碼就能夠很快定位問題了,因此,聽過沒用過的朋友,都去試試吧,真的很無敵。

下次同事有難時,你就用這個工具去幫他,他說不定會請你吃頓飯🍗

<br/>

永久解決哪裏耗時這麼長的問題

這個問題是因爲以前同事重寫了一塊業務邏輯,結果線上展示層耗時大概30s,oh,天哪!在測試環境明明是一瞬間的,咋辦?

形成這種問題的緣由,確定是SQL寫的很差,或者業務處理哪裏作了不少沒必要要的動做(咱們沒有灰度測試),可是生產環境又不能隨便動,也不能斷點調試,從日誌也只能看到耗時很長,可是慢在哪裏不知道。

<br/>

當一個方法裏面通過了N個內部方法後,你不知道究竟是哪個致使這麼長的耗時,當沒法復現的時候怎麼辦呢?其實仍是利用上面的那個工具Arthas,仍是同樣的命令tt,它不只能夠記錄入參和出參信息,還能夠記錄每個方法的耗時,多麼的強大。

<br/>

因此我是爲了再次提醒,這些功能只是Arthas的一點皮毛,我們要學會合理使用開源工具

<br/>

註釋沒法表達流程圖效果的解決方案

註釋是文字,難以表達如流程圖通常的效果,因此該怎麼辦呢?我找到了兩種解決方案,目前在項目中使用效果很是之好,第一鍾是利用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/>文件格式校驗

你將來的同事維護代碼的時候會愛上你,若是是女生,可能還會嫁給你🧡

幻想有一天你老大跑過來問你,你這寫的註釋都是些什麼玩意,而後你一複製一粘貼,一張圖就出來了!下次漲薪會沒有你?

(反正我漲了,還很多😎)

<br/>

PS:我考慮寫一個支持直接複製而後渲染成流程圖的IDEA插件,若是有現成的請聯繫我,就省的我去寫了,嘿嘿✌

<br/>

垃圾SQL的解決方案

咱們公司沒有專門的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質量了,是否是寫的時候也認真多啦,幸福感提示滿滿,哈哈~😁

<br/>

懶得寫文檔的解決方案

方案設計的文檔不可能由工具去寫,可是簡單的數據庫字段映射,或者接口文檔總不須要開發去寫吧?也是同樣摸索摸索,找到了幾個不太適合可是靠邊的開源項目,如:

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

RESTful web API Documentation Generator.

<br/>

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

A magical api documentation generator without annotation for springboot.

<br/>

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

機器學習測試、自動生成代碼、自動靜態檢查、自動生成文檔與註釋等,作最早進的接口管理工具

<br/>

由於每一個項目的狀況不一樣,可是我又不想作大的改動,因此只能說是靠邊,不能百分百適合,但有了這些開源項目,我就能夠改寫其中的代碼,讓它適應當前項目的註釋方案等等,老是,能節省至關一部分的編寫文檔的時間

<br/>

重複性代碼的解決方案

這個的確是個大坑,誰讓我們是CRUD程序員呢,常常須要寫重複性至關高,可是又有一點不一樣的代碼,這裏個人解決方案是利用模板 + 更合適的工具解決,若是隻是數據庫操做層重複代碼多,咱們徹底能夠利用mybatis-plus工具減小重複代碼,又或者寫出公共的操做層減小重複代碼。

<br/>

當用工具完不成的時候,我就會用上模板了,好比直接我寫過一個簡單的開源項目:

好像很厲害的生成器!一秒鐘搞定一個項目:https://juejin.im/post/684490...

核心思路和要求以下:

  • 基於數據庫獲取原始數據
  • 基於模板 + 原始數據生成可運行的SpringBoot項目,支持界面 + 基本增刪改查
  • 提供拓展式接口,能夠實現不修改代碼生成全新的文件

<br/>

那利用這種思路,其實徹底能夠寫一套更開放的代碼生成模板,好比根據傳遞的JSON報文去解析數據,根據傳遞的模板去生成數據,這樣的話又能夠解決至關大一部分的重複工具,你,值得擁有。

PS:同理,其實數據庫字段映射文檔也能夠用這種方式,只須要一秒鐘,簡直不要太舒服🤷‍♂️

<br/>

重複性的操做用腳本代碼

這個其實你們都有意識,可是有時候就是感受可能用的很少,真要用起來的時候又沒功夫去寫腳本,好比進入一個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

<br/>

從網上找了找,又找到一個開源項目用以記錄經常使用的腳本

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

能自動的就不要每次都手寫啦,節約時間去摸魚不快樂嗎👏

<br/>

最後

這但是我這麼久以來總結的時間管理神器,節省的時間拿去摸魚學習,循環促進效率和能力,造成良性正反饋

這還不值得來個贊👍👍👍嗎?嘿嘿~

另外能夠搜索公衆號「 是Kerwin啊」,一塊兒進步!

也能夠查看Kerwin的GitHub主頁,關注一個小白程序員的進步,這貨最近在折騰Go~

相關文章
相關標籤/搜索