為什麼watch機制不是銀彈?

2021-09-06 19:40:45 字數 597 閱讀 7422

幾乎所有構建系統都選擇使用watch機制來解決開發過程中需要反覆生成構建後檔案的問題,但在watch機制下,長期以來我們必須忍受修改完**,儲存完**必須喝口茶才能重新整理看看效果的問題。在這裡我們嘗試**為什麼watch不是銀彈,並嘗試尋找一種更好的方案來解決這個問題。

watch基於的事實
當乙個檔案修改,我們能知道其修改可能導致的檔案修改,那麼重新構建這些檔案即可。

通常對於檔案a,構建成檔案b這種場景,這種對應關係是極好確定的。但現實場景下,構建過程往往不是那麼簡單。例如:

檔案a + 檔案b(被檔案a引用) -> 檔案c
在這種場景下,檔案b的修改,可能難以定位哪些檔案需要重新跑構建任務,因為可能有很多檔案引用了檔案b。

除非我們建立乙個依賴樹,並在每次檔案更新的情況下更新依賴樹,並根據新的依賴樹觸發檔案構建。但這對每乙個外掛程式都需要自行實現這個機制,並且極易出錯。故實際上watch機制僅僅是重跑了整個task。所以當專案越來越大的時候,watch機制將越來越慢(因為越來越多檔案需要重新跑整個過程,即使通過快取減少了整個過程所需的耗時)。

解決方案

敏捷不是銀彈(一) 什麼是敏捷

什麼是敏捷?敏捷是指在動盪的業務環境中,適應變化並創造變化,從而獲得價值的一種能力。什麼是敏捷軟體開發?敏捷軟體開發又稱敏捷開發,是一種應對快速變化的需求的一種軟體開發能力,它強調在專案的整個生命週期中,擁抱並促進由於軟體進化式的發展所帶來的變化。敏捷自誕生10 年以來,經歷了三個發展階段 以極限程...

為什麼要用Zero Copy機制

考慮這樣一種常用的情形 你需要將靜態內容 類似 檔案 展示給使用者。那麼這個情形就意味著你需要先將靜態內容從磁碟中拷貝出來放到乙個記憶體buf中,然後將這個buf通過socket傳輸給使用者,進而使用者或者靜態內容的展示。這看起來再正常不過了,但是實際上這是很低效的流程,我們把上面的這種情形抽象成下...

a 與 a 是不是左值?為什麼?

來自csdn的討論帖 貼上某人的總結 1.什麼是左值 int a 2 這句話裡面2是乙個 值 a是乙個變數,它有乙個4位元組的記憶體區域,這個記憶體區域裡面裝著2,這就暗示這個記憶體區域可以被改寫,可以被賦值,可以出現在 號的左邊 a是乙個 左值 而2就僅僅是乙個2,它是乙個值,我看看到它,就認為它...