分享本猿暈暈乎乎的三週時間.
下文介紹詳細經歷
如果拿到一個同樣的項目需求, 身在石器時代的後端開發狀態…
石器時代
- 石器時代的第一週
- 產品經理加班熬夜弄出來原型圖&UI圖zip包, 發給項目經理過邊需求看看能不能實現, 並要求根據經驗評估工時.
- 產品經理拿到評估後的工時在 禪道或者別的項目管理工具上規定截至日期, 有的還會規定明確的里程碑日期.
- 開發們一看被規定了明確的交付日期, 心裏有點發毛, 然後開始吭哧吭哧幹起來了, 後端根據原型圖設計表結構. PC端,APP端,微信公衆號端開始畫靜態頁面.
- 大約過了兩三天表結構設計完了, 開始在 前端們的要接口的催促下. 花了一天設計接口文檔.
- 前端們 拿到接口文檔開始用 JSON 模擬接口返回字段. 但是前端們並不知道頁面的跳轉情況. 就開始騷擾產品經理, 可能產品經理也是熬夜堆的UI方案, 沒有用文字標記跳轉, 細節也欠缺考慮.
- 快到週五了, 項目經理會過來看看每個開發的進度. 如果進度跟不上的會被暗示週末加班. 想要在家辦公? 爲了集中 內網用SVN, 所以
Working For Home
不存在的!
- 石器時代的第二週
- 後端開始從別的項目裏copy代碼以及jar包. 構建一個全新的項目
- 前端還是在催接口聯調, 後端的幾個 CRUD Boy 加了幾個通宵後睡眼朦朧的在寫(Ctrl+C&Ctrl+V) 增刪改查, 因爲工期緊急自然不會考慮什麼性能了. 多層For循環走起.
- CRUD Boy 在後期寫接口的時候,發現接口文檔有錯誤, 或許少了個參數,或許參數名不準確, 就會去開發羣裏發新的開發文檔. 當然前端也不是沒事, 都在忙着寫靜態頁面和產品扯皮呢, 至於更新後的接口文檔看不看的見就不一定了.
- 快到週五了, 項目經理會過來看看每個開發的進度. 如果進度跟不上的會被暗示週末加班. 想要在家辦公? 爲了集中 內網用SVN, 所以
Working For Home
不存在的!
- 石器時代的第三週
- 後端緊趕慢趕搞完了一個重要模塊. 拉上搞完這個模塊的前端開始聯調(踩坑) , 這個時候或許是前端的接口參數對錯了, 或許是後端的代碼出bug了, 但是更可能的是接口文檔的參數出現變更後沒有及時更改.
- 又到週五了, 匆匆忙忙發個版到聯調環境, 將項目打成 war包, 登錄 FTP 服務器, 放到 Tomcat Webapp , 然後啓動
start.sh
. 如果有運維的話這件事是交給運維的. - 前端也打個版本出來, 丟個包給測試,
- 測試過來驗收里程碑,美約其名 敏捷開發.
- 測試開始測試,發現一堆bug, 比如: 頁面顯示問題, 輸入邊界問題, 還有測試不瞭解需求自己給自己提的bug, 一股腦的指給項目經理, 項目經理說這些bug 先不管, 只要這個模塊主要功能能跑通就行.
- 快到週五了, 項目經理會過來看看每個開發的進度. 如果進度跟不上的會被暗示週末加班.想要在家辦公? 爲了集中 內網用SVN, 所以
Working For Home
不存在的!
- 石器時代的第N周
- 在週而復始的研發過程中, 逐漸做完了項目, 開始部署測試服測試, 開發們(運維)開始裝 測試服的 數據庫, 服務器, 靜態資源服務器 等, 如果用戶多還可能用 集羣, 就更麻煩了.
- 但是終於在公司成員的努力(加班)下完成了, 當然還有一堆隱藏Bug等着呢 !
- 正準備給客戶交付呢, 客戶打電話過來商量需求變更的事情…
- 開發們: wsl (畢竟是外包,客戶要的是結果…)
如果拿到一個同樣的項目需求, 身在青銅時代的後端開發狀態…
青銅時代
- 青銅時代的第一週
- 產品經理和需求方協商業務, 輸出需求文檔(明確需求範圍), 並在合同上籤訂變更聲明, 協商通過後開始畫原型圖以及UE圖.
- 交付 UI工程師開始用UI圖描述細節, UI圖,UE圖,原型圖,需求文檔交付後
- 產品部內部 check 一遍需求, 然後交由 項目經理. 拆分需求爲 需求列表並同步到 ShowDoc 指定給 開發者.
- 由開發者對 頁面詳細評估, 一個接口區分非常複雜,複雜,簡單等級, 頁面也是同樣, 根據這種可量化的指標來控制時間. 並使用 Tapd 來分配優先級.
- 而項目經理則會將項目適用的架構和難點, 給攻克.
- 開發工具上: 使用 Maven私服管理 Jar包, GitLab 分佈式管理代碼, sculptor-boot-generator 根據表結構生成 CRUD 代碼, 如果有特殊SDK模塊則提前封裝 SpringBoot Stater.
- 基於 PgSql 設計表結構, 有需求文檔 UE圖 UI圖設計起來當然是輕鬆多了.
- 快到週五了, 項目經理會用 Tapd 看看每個開發的進度. 發現大家的進度都很快速, 如果有個別摸魚黨, 則可因爲內網是 Git 可以選擇在家辦公 !
- 青銅時代的第二週
- 根據 SQL 模型, 設計 yapi , 內容包括 請求Url, 請求參數, 響應數據格式(支持 mock) 大概一兩天設計完成. 然後根據實際情況 check一遍參數與返回值.
- 前端還沒有反應過來就迅雷不及掩耳的交付 yapi 開發文檔, 前端直接把 baseUrl 切爲 yapi, 簡直何真實接口一樣絲滑.
- 進入api開發階段, 使用 sculptor-boot-generator 按需生成基礎 CRUD 代碼以及對應運營平臺. 當然最優配置的框架也是生成好了的(redis緩存可選). 開發業務代碼 ing
- 業務代碼開發好了催着前端進行聯調. 前端切換 yapi 地址爲真實地址聯調後, Tapd 上對應的需求 泳道向前遊🏊,
- 快到週五了, 項目經理會用 Tapd 看看每個開發的進度. 發現大家的進度都很快速, 如果有個別摸魚黨, 則可因爲內網是 Git 可以選擇在家辦公 !
- 青銅時代的第三週
- 使以前做好的 Docker 鏡像配置測試服. PgSql, Nginx, Redis 應有盡有而且還開機自啓 !
- 因爲一開始就是科學的分配任務, 當然沒有特別趕時間, 代碼質量相對較高, 測試並沒有測試出很多bug !
- 使用 ShowDoc Yapi TAPD 有效的沉澱了文檔, 可維護性變強好了.
- 開始考慮建立索引,單元測試覆蓋,緩存等可優化項.
- 開發們在開發項目的過程中 王者榮耀又升段位了 !
覆盤心得
石器時代是曾經絕望中的呼喊,青銅時代是經過修飾的理想狀態, 一切並非一帆風順, 但我們終將抵達彼岸,
既然作爲覆盤, 就是事後追求精進.下面細數我犯了那些錯誤 !
- 架構選型上要用最能發展生產力的真正穩定技術, 而不是滯後生產力的所謂穩定技術 !
- 因爲以前沒有用過 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
✔ 如果你需要 Https 的Gitlab 可以參考 (ps:注意證書名要與 hostname一致)
【docker】開啓gitlab + nginx + https之旅
🎈 解決 因爲 內存原因導致的gitlab 502 錯誤(2核4G以下都會有的錯誤)
🎉一些好的Gitlab 優化建議 !
NGINX
因爲鏡像中自帶了NGINX, 所以我沒有使用 NGINX 容器化, 下面介紹用 NGINX 做 gitlab 容器的 二級域名 HTTPS轉發, 望舉一反三.
GitLab HTTPS 的配置轉發.
-
首先你需要在 阿里Y上 申請免費的DV證書, 當然如果你有通配符證書的話可以跳過這一步…
-
其次確保你的NGINX 是可以被外網訪問的,(運行NGINX並開放安全組以及端口), 排查工程中有可能是 NGINX-DNS 出現了錯誤導致無法訪問.
-
在阿里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 經驗
Tapd
專業版支持主流的敏捷產品研發模式和方法論(如Scrum/XP),結合騰訊互聯網產品研發的特色,幫助產品團隊以敏捷迭代、小步快跑的研發方式進行產品規劃、項目管理、質量跟蹤等研發管理工作,幫助團隊更好更快完成產品交付併發布上線運營。
專業版包含需求、迭代、故事牆、缺陷、報表、文檔等6個核心應用,還支持通過移動端管理工作。
瞭解更多 -> TAPD 專業版 | 產品文檔
掃碼回覆 “加羣” 和我一起月入 20K+
深入淺出分享 Java 乾貨 , 找回對代碼的 Passion , 助力月入 20K+