開箱體驗: Web研發從石器時代過渡青銅時代&覆盤心得[勘誤ing,歡迎評論]

蕭子山發表於2020-04-02

分享本猿暈暈乎乎的三週時間.

近期因為一個專案在和 CDK8S 合作, 經授權閉源使用 CDK8S 提供的 Web快開框架 sculptor-boot-generator 開發過程中我的每一個毛孔都是舒爽的 (後續會詳細介紹這個框架), 原來Java快開領域不止 JHipster 構建模型上也不止 JDL, 在享受新框架的給我帶來的快感時, CDK8S 的研發理念把身在石器時代的我震撼了. 千言萬語歸根結底一句話 Web 已死, 我們需要能提高效率的快開框架, 更符合時代的開發理念 !

下文介紹詳細經歷

如果拿到一個同樣的專案需求, 身在石器時代的後端開發狀態....

石器時代

石器時代的第一週
1. 產品經理加班熬夜弄出來原型圖&UI圖zip包, 發給專案經理過邊需求看看能不能實現, 並要求根據經驗評估工時.
2. 產品經理拿到評估後的工時在禪道或者別的專案管理工具上規定截至日期, 有的還會規定明確的里程碑日期.
3. 開發們一看被規定了明確的交付日期, 心裡有點發毛, 然後開始吭哧吭哧幹起來了, 後端根據原型圖設計表結構. PC端,APP端,微信公眾號端開始畫靜態頁面.
4. 大約過了兩三天表結構設計完了, 開始在前端們的要介面的催促下. 花了一天設計介面文件.
5. 前端們拿到介面文件開始用 JSON 模擬介面返回欄位. 但是前端們並不知道頁面的跳轉情況. 就開始騷擾產品經理, 可能產品經理也是熬夜堆的UI方案, 沒有用文字標記跳轉, 細節也欠缺考慮.
6. 快到週五了, 專案經理會過來看看每個開發的進度. 如果進度跟不上的會被暗示週末加班. 想要在家辦公? 為了集中內網用SVN, 所以 Working For Home 不存在的!
石器時代的第二週
1. 後端開始從別的專案裡copy程式碼以及jar包. 構建一個全新的專案
2. 前端還是在催介面聯調, 後端的幾個 CRUD Boy 加了幾個通宵後睡眼朦朧的在寫(Ctrl+C&Ctrl+V) 增刪改查, 因為工期緊急自然不會考慮什麼效能了. 多層For迴圈走起.
3. CRUD Boy 在後期寫介面的時候,發現介面文件有錯誤, 或許少了個引數,或許引數名不準確, 就會去開發群裡發新的開發文件. 當然前端也不是沒事, 都在忙著寫靜態頁面和產品扯皮呢, 至於更新後的介面文件看不看的見就不一定了.
4. 快到週五了, 專案經理會過來看看每個開發的進度. 如果進度跟不上的會被暗示週末加班. 想要在家辦公? 為了集中內網用SVN, 所以 Working For Home 不存在的!
石器時代的第三週
1. 後端緊趕慢趕搞完了一個重要模組. 拉上搞完這個模組的前端開始聯調(踩坑) , 這個時候或許是前端的介面引數對錯了, 或許是後端的程式碼出bug了, 但是更可能的是介面文件的引數出現變更後沒有及時更改.
2. 又到週五了, 匆匆忙忙發個版到聯調環境, 將專案打成 war包, 登入 FTP 伺服器, 放到 Tomcat Webapp , 然後啟動 start.sh . 如果有運維的話這件事是交給運維的.
3. 前端也打個版本出來, 丟個包給測試,
4. 測試過來驗收里程碑,美約其名 敏捷開發.
5. 測試開始測試,發現一堆bug, 比如: 頁面顯示問題, 輸入邊界問題, 還有測試不瞭解需求自己給自己提的bug, 一股腦的指給專案經理, 專案經理說這些bug 先不管, 只要這個模組主要功能能跑通就行.
6. 快到週五了, 專案經理會過來看看每個開發的進度. 如果進度跟不上的會被暗示週末加班.想要在家辦公? 為了集中內網用SVN, 所以 Working For Home 不存在的!
石器時代的第N周
1. 在周而復始的研發過程中, 逐漸做完了專案, 開始部署測試服測試, 開發們(運維)開始裝測試服的資料庫, 伺服器, 靜態資源伺服器等, 如果使用者多還可能用叢集, 就更麻煩了.
2. 但是終於在公司成員的努力(加班)下完成了, 當然還有一堆隱藏Bug等著呢 !
3. 正準備給客戶交付呢, 客戶打電話過來商量需求變更的事情.....
4. 開發們: wsl (畢竟是外包,客戶要的是結果...)

如果拿到一個同樣的專案需求, 身在青桐時代的後端開發狀態....

青銅時代

青銅時代的第一週
1. 產品經理和需求方協商業務, 輸出需求文件(明確需求範圍), 並在合同上籤訂變更宣告, 協商通過後開始畫原型圖以及UE圖.
2. 交付 UI工程師開始用UI圖描述細節, UI圖,UE圖,原型圖,需求文件交付後
3. 產品部內部 check 一遍需求, 然後交由專案經理. 拆分需求為需求列表並同步到 ShowDoc 指定給開發者.
4. 由開發者對頁面詳細評估, 一個介面區分非常複雜,複雜,簡單等級, 頁面也是同樣, 根據這種可量化的指標來控制時間. 並使用 Tapd 來分配優先順序.
5. 而專案經理則會將專案適用的架構和難點, 給攻克.
6. 開發工具上: 使用 Maven私服管理 Jar包, GitLab 分散式管理程式碼, sculptor-boot-generator 根據表結構生成 CRUD 程式碼, 如果有特殊SDK模組則提前封裝 SpringBoot Stater.
7. 基於 PgSql 設計表結構, 有需求文件 UE圖 UI圖設計起來當然是輕鬆多了.
8. 快到週五了, 專案經理會用 Tapd 看看每個開發的進度. 發現大家的進度都很快速, 如果有個別摸魚黨, 則可因為內網是 Git 可以選擇在家辦公 !
青銅時代的第二週
1. 根據 SQL 模型, 設計 yapi , 內容包括請求Url, 請求引數, 響應資料格式(支援 mock) 大概一兩天設計完成. 然後根據實際情況 check一遍引數與返回值.
2. 前端還沒有反應過來就迅雷不及掩耳的交付 yapi 開發文件, 前端直接把 baseUrl 切為 yapi, 簡直何真實介面一樣絲滑.
3. 進入api開發階段, 使用 sculptor-boot-generator 按需生成基礎 CRUD 程式碼以及對應運營平臺. 當然最優配置的框架也是生成好了的(redis快取可選). 開發業務程式碼 ing
4. 業務程式碼開發好了催著前端進行聯調. 前端切換 yapi 地址為真實地址聯調後, Tapd 上對應的需求泳道向前遊?,
5. 快到週五了, 專案經理會用 Tapd 看看每個開發的進度. 發現大家的進度都很快速, 如果有個別摸魚黨, 則可因為內網是 Git 可以選擇在家辦公 !
青銅時代的第三週
1. 使以前做好的 Docker 映象配置測試服. PgSql, Nginx, Redis 應有盡有而且還開機自啟 !
2. 因為一開始就是科學的分配任務, 當然沒有特別趕時間, 程式碼質量相對較高, 測試並沒有測試出很多bug !
3. 使用 ShowDoc Yapi TAPD 有效的沉澱了文件, 可維護性變強好了.
4. 開始考慮建立索引,單元測試覆蓋,快取等可優化項.
5. 開發們在開發專案的過程中王者榮耀又升段位了 !

覆盤心得

石器時代是曾經絕望中的呼喊,青銅時代是經過修飾的理想狀態, 一切並非一帆風順, 但我們終將抵達彼岸, 既然作為覆盤, 就是事後追求精進.下面細數我犯了那些錯誤 !

架構選型上要用最能發展生產力的真正穩定技術, 而不是滯後生產力的所謂穩定技術 !
因為以前沒有用過 sculptor-boot-generator 簡稱 sbg, 但是用過類似的框架如 JHipster , 我就用 JHipster 的開發經驗去套 sbg, 執行程式碼時發現一堆稀奇古怪的bug, 原來我沒有按著文件去開發, 而且我對 sbg 的技術棧也不夠了解, 就開始擼程式碼. 舉個最大的不同, sbg 用的是 MyBatis , Jhipster 用的是 Hibernate, 後來我有惡補了 MyBatis 的知識,才慢慢走上正軌.
我寫 Yapi 時並沒有考慮到實際需要用的引數和返回值情況, 導致前端缺返回值, 後來還因為命名規範問題多次改變 Yapi, 造成了不必要的聯調麻煩.
在寫程式碼時我沒有考慮到多端使用者多id 的情況, 多次出現使用者基本資訊查詢錯id 的情況. 我的程式碼規範也存在不小的問題.
在部署 Docker 時, 我配置 gitlab 的時候用到了 Docker 卷軸掛載:資料目錄, 我要修改其配置的時候直接在本機的資料目錄進行改變, 發現並無效果, 而且配置生效命令無效, 其實你要進入 Docker 裡了修改後配置命令即可生效, 外面配置就需要重啟Docker 容器.
在聯調過程中有人不斷犯錯請不要責怪他, 從自己身上找原因, 是不是自己介面設計的不合理, 文件不夠清晰易懂, 協作開發中還有什麼可以改進的地方, 思維不要被程式碼侷限, 抱怨解決不了問題.
專注一件事才能做好一件事, 時間寶貴!
程式碼不會騙人,寫程式碼需要認真思考之後仔細仔細再仔細 !

? 來一波乾貨 !

最近一段時間我在雲上使用了 Docker 搭建了一臺伺服器用於生產環境, 想起當初我接觸 CentOS 的時候正處於虛擬機器時代(石器時代) ,那時候容器這個概念還沒有普及只是少數大廠的寵兒, 頭幾年我們搭建環境都是用雲廠商的定製映象然後再執行下指令碼改改配置, 得益於雲端計算的普及這個過程遠遠比虛擬機器時代手動編譯原生伺服器軟體安裝來的輕鬆愜意, 在各廠隨隨便便 DAU 幾百萬的今天我們不滿足於此, Docker 容器化的出現讓伺服器軟體的開發者與使用者藉助容器使工作變的更加簡單, 接下來我會分享幾個不錯的 Docker 映象以及以及青銅時代的線上軟體.

來自官網的 Docker 容器簡介

容器是打包程式碼及其所有依賴項的標準軟體單元，因此應用程式可以從一個計算環境快速可靠地執行到另一個計算環境。 Docker容器映象是一個輕量級的，獨立的，可執行的軟體軟體包，其中包含執行應用程式所需的一切：程式碼，執行時，系統工具，系統庫和設定。

容器映象在執行時會成為容器，對於Docker容器，映象會在Docker Engine 上執行時成為容器。不論基礎架構如何，容器化軟體都可用於基於Linux和Windows的應用程式，始終執行相同。容器將軟體與其環境隔離開來，並確保儘管開發和生產之間存在差異，但軟體仍可以均勻執行。

以上提到了 3個重要的點, 映象 , 容器, 跨平臺

映象: 這個概念相信大家都不陌生吧, 每個人使用 VMware 安裝 CentOS 時都是基於官方給出的 .iso 映象安裝的. 在 Docker 中也有映象這個概念. Docker映象你可以理解為就像 SpringBoot 中的 Starter 一樣, 由作者將需要用到的資源按照 spi規則打包到一個 <Dependency/> 中供你呼叫! 開箱即用的它讓你無需考慮其中的依賴構建關係. 學到更多
容器: 容器是應用程式層的抽象，將程式碼和依賴項打包在一起。多個容器可以在同一臺機器上執行，並與其他容器共享OS核心，每個容器在使用者空間中作為隔離的程式執行。容器佔用的空間少於VM（容器映像的大小通常為幾十MB），可以處理更多的應用程式，並且需要的VM和作業系統更少, 其實可以抽象理解為一個定製映象你可以進入Docker 容器修修改改(裡面別有洞天) 當然如果沒有做 資料掛載 的話容器被重置了你修修改改的資料就沒了學到更多。
跨平臺: 注意是 Docker 跨平臺不是容器跨平臺, 意思是隻要 Docker 能在這個作業系統上執行, 那麼你基於 Docker 製作的映象也可以在這個系統上跑. 比如 Java的跨平臺不是 .class 跨平臺而是執行 .class 的 JVM 跨平臺學到更多.

✨作者推薦通過這個網站來學習 Docker 會事半功倍 -> 菜鳥教程 | Docker

GitLab

GitLab 是一個用於倉庫管理系統的開源專案，使用Git作為程式碼管理工具，並在此基礎上搭建起來的web服務。安裝方法是參考GitLab在GitHub上的Wiki頁面 , 它整合了許多用於軟體開發和部署以及專案管理的基本工具：

使用版本控制在儲存庫中託管程式碼。
使用功能齊全的問題跟蹤器跟蹤新實施的建議，錯誤報告和反饋。
組織和發行委員會的優先次序。
使用Review Apps檢視合併請求中每個分支的實時預覽更改中的程式碼。
使用內建的持續整合進行構建，測試和部署。
使用GitLab Pages部署個人和專業靜態網站。
通過使用GitLab容器登錄檔與Docker整合。
通過使用GitLab價值流分析跟蹤開發生命週期。
瞭解更多

下載 GitLab Dokcer 映象

docker pull gitlab/gitlab-ce:latest

執行Gitlab構建命令

執行前注意事項

-v 需要根據實際卷軸情況建立目錄(PS: 命令列引數不會自動建立目錄).
--hostname clone url 字首域名, 如果需要被外網正確訪問則新增.
--restart 容器執行中退出時（不是手動退出）,自動重啟

docker run -d  --hostname gitlab.xxx.com -p 1443:443  -p 1080:80   -p 1022:22  --name gitlab  --restart unless-stopped  -v /root/docker-volume/gitlab/etc:/etc/gitlab  -v /root/docker-volume/gitlab/log:/var/log/gitlab  -v /root/docker-volume/gitlab/data:/var/opt/gitlab  gitlab/gitlab-ce:latest
複製程式碼

註釋版

docker run -d \       # 後臺執行 -d
        --hostname gitlab.xxx.com \ # 指定 clone url 字首域名
    -p 1443:443 \          # 將容器內443埠對映到主機1443,提供https服務
    -p 1080:80 \           # 將容器內80埠對映到主機1080,提供http服務
    -p 1022:22 \           # 將容器內22埠對映到主機1022,提供ssh認證服務
    --name gitlab \         # 指定容器名稱
    --restart unless-stopped \      #容器執行中退出時（不是手動退出）,自動重啟
    -v /var/lib/docker/volumes/gitlab-data/etc:/etc/gitlab \       #  將本地/var/lib/docker/volumes/gitlab-data/etc掛載到容器內/etc/gitlab
    -v /var/lib/docker/volumes/gitlab-data/log:/var/log/gitlab \   # 將本地將本地/var/lib/docker/volumes/gitlab-data/log掛載到容器內/var/log/gitlab
    -v /var/lib/docker/volumes/gitlab-data/data:/var/opt/gitlab \  # 將本地將本地/var/lib/docker/volumes/gitlab-data/data掛載到容器內/var/opt/gitlab
    gitlab/gitlab-ce:latest 
複製程式碼

NGINX

因為映象中自帶了NGINX, 所以我沒有使用 NGINX 容器化, 下面介紹用 NGINX 做 gitlab 容器的二級域名 HTTPS轉發, 望舉一反三.

GitLab HTTPS 的配置轉發.

首先你需要在阿里Y上申請免費的DV證照, 當然如果你有萬用字元證照的話可以跳過這一步...
其次確保你的NGINX 是可以被外網訪問的,(執行NGINX並開放安全組以及埠), 排查工程中有可能是 NGINX-DNS 出現了錯誤導致無法訪問.
在阿里Y 域名控制檯新增二級域名對映(其他雲廠商也是同理)

Nginx配置域名阿里Y 新增二級域名

配置你的 NGINX檔案, 新增 443埠以及(80轉443)配置 (修改 todo 為部署域名並保證你的NGINX版本為 1.14.2及以上).

 # https 配置
 server {
    listen 443 ssl;
    server_name www.todo.com;

    #設定長連線
    keepalive_timeout   70;
        
    #HSTS策略
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
        
    #證照檔案
    ssl_certificate     ./ssl/www/todo.pem;
    #私鑰檔案
    ssl_certificate_key ./ssl/www/todo.key; 
    access_log /data/todo/access_nginx.log combined;
    root /data/todo; 
    index index.html index.htm index.jsp;
    #error_page 404 /404.html;
    #error_page 502 /502.html;
   
   #定義演算法
   ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4";
 
   ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
   #禁止伺服器自動解析資源型別
   add_header X-Content-Type-Options nosniff;	
   #防XSS攻擊
   add_header X-Xss-Protection 1;
   #減少點選劫持
   add_header X-Frame-Options DENY; 
   ssl_prefer_server_ciphers on;

  }

# 80轉443
server { 
    listen 80;
    server_name gitlab.todo.com;
    rewrite ^(.*)$ https://${server_name}$1 permanent;
} 
複製程式碼

修改你的NGINX gitlab https 監聽轉發配置

server {
        listen 443 ssl;
        server_name gitlab.todo.com;
        ssl_certificate     ./ssl/gitlab/todo.pem;
        ssl_certificate_key ./ssl/gitlab/todo.key; 
        location / {
                proxy_redirect off;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_pass https://127.0.0.1:1443;
        }
        access_log /data/todo/gitlab_nginx.log combined;
}
複製程式碼

Yapi

YApi 是高效、易用、功能強大的 api 管理平臺，旨在為開發、產品、測試人員提供更優雅的介面管理服務。可以幫助開發者輕鬆建立、釋出、維護 API，YApi 還為使用者提供了優秀的互動體驗，開發人員只需利用平臺提供的介面資料寫入工具以及簡單的點選操作就可以實現介面的管理。

基於 Json5 和 Mockjs 定義介面返回資料的結構和文件，效率提升多倍
扁平化許可權設計，即保證了大型企業級專案的管理，又保證了易用性
類似 postman 的介面除錯
自動化測試, 支援對 Response 斷言
MockServer 除支援普通的隨機 mock 外，還增加了 Mock
期望功能，根據設定的請求過濾規則，返回期望資料
支援 postman, har, swagger 資料匯入
免費開源，內網部署，資訊再也不怕洩露了
瞭解更多

Yapi 暫未推出官方Docker映象, 推薦使用 -> docke-YApi | DockeCompose

需要注意的地方

docker-YApi 預設 YAPI_CLOSE_REGISTER 為 true, 不支援新使用者註冊, 你可以使用 yapi-plugin-add-user 外掛閉環註冊 (ps: 4GB記憶體以下不建議安裝外掛). 當然如果你希望有遊客參與到你的專案中來可以預設為 false !

說句題外話, Yapi 確實比寫介面文件清爽, 還支援 Swagger 批量匯入 Yapi, 批量介面測試等特性 (缺點: 改介面內容太過方便, 這點我已經被吐槽過很多次 2333 :)
總結: 線上的api文件能減少因為資訊傳遞而產生的工作量, 總之愛了 !

ShowDoc

ShowDoc是什麼

每當接手一個他人開發好的模組或者專案，看著那些沒有寫註釋的程式碼，我們都無比抓狂。文件呢？！文件呢？！Show me the doc ！！
程式設計師都很希望別人能寫技術文件，而自己卻很不希望要寫文件。因為寫文件需要花大量的時間去處理格式排版，想著新建的word文件放在哪個目錄等各種非技術細節。
word文件零零散散地放在團隊不同人那裡，需要文件的人基本靠吼，吼一聲然後上qq或者郵箱接收對方丟過來的文件。這種溝通方式當然可以，只是效率不高。
ShowDoc就是一個非常適合IT團隊的線上文件分享工具，它可以加快團隊之間溝通的效率。
瞭解更多

我主要使用 ShowDoc 做資料字典設計以及各類開發文件的沉澱. 理由同上 減少因為資訊傳遞而產生的工作量 ,沒有文件的專案 3個月之後你就不認識它了 ?太真實了 ...

推薦安裝官方的 Docker -> ShowDoc | Docker

PostgreSQL

MySQL 的使用者群體性好於 PostgreSQL，特別是國內，更加容易上手。但是 PostgreSQL 從體驗上最大優勢就是外掛以及帶來的各種可能。
兩者的基準壓力測試工具不同，很難說測試資料對比是公平的，如果是通過 Java 程式碼測試同配置的 CURD，非極限情況下，兩者使用感受上差距不大。
PostgreSQL 在做統計分析上可以藉助各種函式、語法進行支援，所以在資料分析上有優勢
借用知乎上的一句總結 PostgreSQL 我覺得很合適：PostgreSQL 是一專多長的全棧資料庫：在可觀的規模內，都能做到一招鮮吃遍天
- 所以，作為中小企業我覺得完全可以依賴 PostgreSQL，特別是求活階段的企業

瞭解更多 -> MySQL 過渡 PostgreSQL 經驗