摘要:
寫在前面 前段時間跟領導討論技術債概念時不可避免地提到了代碼的質量,而影響代碼質量的因素向來都不是單一的,諸如項目因素、管理因素、技術選型、人員素質等等,因為是技術債務,自然就從技術角度來分析,單純從技術角度來看代碼質量,其實又細分很多原因,如代碼設計、代碼規范、編程技巧等等,但我個人覺得這些都是技 閱讀全文
寫在前面 前段時間跟領導討論技術債概念時不可避免地提到了代碼的質量,而影響代碼質量的因素向來都不是單一的,諸如項目因素、管理因素、技術選型、人員素質等等,因為是技術債務,自然就從技術角度來分析,單純從技術角度來看代碼質量,其實又細分很多原因,如代碼設計、代碼規范、編程技巧等等,但我個人覺得這些都是技 閱讀全文
posted @ 2024-07-03 21:01
糖拌西紅柿
閱讀(863)
評論(5)
推薦(8)

逐層拆分ElasticSearch的概念 Cluster:集群,Es是一個可以橫向擴展的檢索引擎(部分時候當作存儲數據庫使用),一個Es集群由一個唯一的名字標識,默認為“elasticsearch”。在配置文件中指定相同的集群名,Es會將相同集群名的節點組成一個集群。 Node:節點,集群中的任意一
以 AbstractBaseCronTask類為基礎,定義一個固定的子類BaseMethodLevelTask,并在其內部限定任務的執行方式,掃描所有標注了@MethodJob的方法及其所屬的Bean,連同Bean及方法的反射類作為構造函數,生成BaseMethodLevelTask對象,因為BaseMethodLevelTask也是AbstractBaseCronTask的子類,則可以以類級別定時任務的方式,將其生成定時任務,并進行管理。
本質還是管理的AbstractBaseCronTask子類在線程池中的具體對象,不同的地方是類級別定時任務是一個具體的任務類僅生成一個對象,class路徑即是唯一的標識,而方法級別的定時任務均基于BaseMethodLevelTask生成無數個對象,具體標識則是構造函數傳入的Bean的反射對象和方法名。
B+樹的最底層葉子節點包含了所有的索引項。從圖上可以看到,B+樹在查找數據的時候,由于數據都存放在最底層的葉子節點上,所以每次查找都需要檢索到葉子節點才能查詢到數據。所以在需要查詢數據的情況下每次的磁盤的IO跟樹高有直接的關系,但是從另一方面來說,由于數據都被放到了葉子節點,
接口服務主要由兩部分組成,即參數(輸入)部分,響應(輸出)部分。其中在SpringBoot中主要是Controller層作為API的開發處,其實在架構層面來講,Controller本身是一個最高的應用層,它的職責是調用、組裝下層的interface服務數據,核心是組裝和調用,不應該摻雜其他相關的邏輯。這里統一用一系列Controller的封裝處理來提供優化思路。優雅且規范的開發REST API需要做以下幾步:接口版本控制、參數校驗、異常捕獲處理、統一響應封裝、接口文檔的維護和更新
簡單講過程思維是數據結構加操作;對象思維則是一個整體,既包含數據結構又包含操作,也就是面向對象中的屬性和行為。 在進行面向對象設計和編碼的道路上,眾多知名前輩結合自己的實踐和認知高度抽象概況出了具有指導思想意義的設計原則。這里的每個原則細細品來都是意味深長,但是需要注意的是,就像數據庫范式一樣,它是個指導思想,并不是需要一板一眼遵守的“準則”。
企業里的研發部門、技術團隊其實更多的是軟件/互聯網公司的生產部門,好比實體產業的生產車間。生產車間可以通過更新車床、設備來提高生產力,這里的車床、設備即是“資產”,那么研發部門的“資產”類比一下就出來了,就是部門級的技術標準、工具。
對于團隊人效來說,統一的技術庫、技術組件能夠形成有效的技術隔離帶,節省很多二次學習成本。
適配器模式、代理模式、裝飾模式
寫在前面: 其實之前一直想匯總一篇關于自己對于面向對象的思考以及實踐的文章,但是苦于自己的“墨跡”,一延再延,最近機緣巧合下仔細了解了一下COLA的內容,這個想法再次被勾起,所以這次一鼓作氣,準備好好梳理一篇。至于標題,因為是被DDD和COLA喚起的,索性就叫這個吧。 思維:面向對象和面向過程 領域
浙公網安備 33010602011771號