開發模式的轉變

現在雖然不怎么使用很傳統的軟件開發模型了，但是好歹也要敏捷開發吧。事實上，我這個小廠甚至做的更絕。全程無UML。。。

需要一天：

1.項目組長與客戶進行需求對接。

2.項目組長然后就找我來講述需求，我就直接制作出原型圖（這里用的Axure，不知道有沒有更快的）。（這個原型圖畫的時間很快，差不多一個上午，也就是兩個小時的認真畫）

畫原型，我會問清楚的東西1. 這東西是給誰用的？或者說這個功能意義是？原本流程是這樣的，你現在新需求了流程變成咋樣了呢？
2. 得有哪些功能？（沒啥好問的）
3. 頁面上該放啥？（比如按鈕放哪、輸入框要幾個、點了之后跳去哪）
4. 點一下按鈕會發生啥？（比如點提交后要不要彈個提示、加載的時候要不要轉圈圈）
5. 技術上能不能實現？（比如別設計個太復雜的動畫，你們技術做不了）（設計階段再說）

需要一天：

3.然后大家會被組長安排負責某些功能（開發計劃.xlsx）。如果需求很多，還會開個會，照著原型給大家解釋一下。

4.大家去gitlab拉下原型圖，就可以研究一下了。

需要一天：

5.自己設計庫表。如果之前庫表的字段，就延用之前的，拷貝。

6.想一想這些增刪改查接口的大概代碼方案，自己寫一個代碼設計文檔（先想一下注釋）。

我自己增刪改查接口的固定模板：1.校驗參數（allget取出來）
2.校驗權限（這個接口是不是管理員才能用的接口）
3.校驗存在（操作的數據庫記錄，一定要存在）
4.業務操作（業務校驗或者操作。比如，章節號必須遞增，，，）
5.操作數據庫

需要一天：

7.編寫代碼，我喜歡開個feat分支，一個接口就一個commit。

8.寫完后，交給測試大哥。大概測過了，就pull origin?dev、rebase dev、merge --no-ff、最后push到dev分支

需要一天：

9.之后就等bug了。慢慢修bug

團隊代碼協作

我git用的比較熟練。但還是覺得git真的要好好學一下。這么混亂的git歷史。

要么就是：

1.push的前一秒！！！沒有先把自己本地的當前分支的代碼更新到最新狀態（沒有pull拉）。導致到處都是落后的分支，再一條線merge到西天。。。巨難看

2.還有不要提交配置代碼。

我自己會這么做：1.自己commit的時候，遵循常見的commit規范，.gitmessage模板。
其實分支也可以這么取名。我就常用feat和fix。
我自己用的commit模板
# ? feat: 新功能   | 🐛 fix: 修復缺陷
# 📚 docs: 文檔     | 🎨 style: 格式
# ?? refactor: 重構 | ? perf: 性能
# ? test: 測試     | 🔧 chore: 雜務
# 🔥 revert: 回滾   | 🚨 BREAKING: 破壞性變更2.然后自己push的前一秒，確保自己的本地分支狀態是最新的代碼。也就是push的前10秒內，pull拉一下代碼。
我個人的提交喜好就是（假設有feat-login、dev兩個分支，feat-login是我開發了的分支）
git switch dev
git pullgit switch feat-login
git rebase devgit switch dev
git merge --no-ff feat-logingit pull
git pushgit branch -d feat-login
git branch -d origin/feat-login --remote
git push --delete orgin feat-login1-2是去把dev代碼弄到最新狀態
3-4是把feat-login的commit歷史，變成一條線，放在dev分支后面
5-6是到dev中合并feat-login這個分支
7-8是push代碼，不過push前pull拉了一下，能double check一下，會不會有人更新了dev分支
9-11是刪除分支，這個分支沒有啥用了，已經開發完了

• gitlab

• teamcity

• pm2

• justauth集成釘釘OAuth2

• shiro + sa-token