總結：

1. 條件查詢可在數據庫層創建queryDto進行統一操作。

2. 代碼復用：若有代碼重復出現了三次，很大概率可以重構。（三則重構）

3. dto和entity中的賦值操作，可以寫成方法放在dto中。（充血模型）

4. dto中不寫id，id是前端另外傳過來或后端生成的。（冪等）

5. 取和存數據相同時，可只用entity一個數據傳輸對象。

6. 使用框架、工具類的代碼不可直接在業務層引入（業務就是業務，工具可以包裝調用），操作數據需統一通過持久化層進行封裝（持久層與業務層代碼隔離）。

7. 領域、對象的命名需使用名詞，不可有歧義。若命名不理想，需商討。（軟件設計很重要的一點：如何命名）

8. 接口對外暴露地址要語義明確，單詞間使用 “-” 分割（簡短精確！restful）

9. 當領域中有相似功能實現時，有三種數據庫設計方式：

? （1）將所有字段合并在一張表中，各業務留冗余為空的字段。【不使用】

? （2）抽離出公共屬性字段，獨立成表，在使用時關聯相關獨立業務表查詢。【符合第三范式，但在查詢時需要掃描連表查詢，使用較少】

? （3）在實際使用中，常常使用水平拆分，降低單庫（一張表）的數據量，使用反范式設計來滿足不同維度上的查詢需求。將兩張表中的查詢展示數據抽離在一張表中，保留一定的數據冗余，通過標志位區分不同業務。其余的一些下一階段的查詢存放于各自的單表中。實現冗余和查詢功能的中和。【使用較多】

10. 前后端有關時間類型的傳輸要保證準確，統一使用編程語言中的時間類型進行傳輸，而不采用String，具體使用再進行不同的轉化。

11. 每一個實體所包含的字段，應該具有該實體的唯一使用場景。如：游戲中的"預約數"，該字段雖為游戲本身屬性，但只針對"預約游戲"，而非所有的游戲（包含已上線的游戲），這時，應將 預約數量獨立出來，而非與"游戲"實體的固有屬性存放在一張數據庫表中。

12. 領域之間的松耦合：一個領域中使用一個service，同一個Repository只在對應領域中的一個service中出現。若兩個領域中有業務上的交互，那么應該由被調用方抽離出被調用的方法，提供調用接口（如：GameServiceFacade）給調用方使用。若業務不復雜或交互點不多時，也可直接進行service層的互調。

13. 測試

? （1）為了利于編碼測試，可以在業務層進行改造，改造方式有兩種：1、修改repo的注入方式，將mock包裹的repo對象注入service中的repo；2、修改業務層邏輯，將獨立的repo邏輯剔出，放在controller統一調用。

? （2）能不使用mock進行隔離則不進行mock隔離，保證代碼在功能上的獨立測試性。

關于測試：如果你的代碼功能不利于單元測試，那么你的代碼多半是有毛病的(很大的重構空間和優化空間)

14. k8s是個好東西，不要拒絕難度高的技術選型。
15. 允許數據結構上的字段冗余，權衡利弊，這個需要經驗。
16. 少用繼承（extents），多用組合（implement）。其實工作中我幾乎不會用繼承，徒增復雜度。

引用一下：我的觀點沒那么極端！之所以“多用組合少用繼承”這個口號喊得這么響，只是因為，長期以來，我們過度使用繼承。
還是那句話，組合并不完美，繼承也不是一無是處。只要我們控制好它們的副作用、發揮它們各自的優勢，在不同的場合下，恰當地選使用繼承還是組合，這才是我們所追求的境界。

更新：2021-10-19

總結

以上是生活随笔為你收集整理的恭喜你发现了宝藏，编程习惯-日积月累的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。