最近兩周的某一項工作就是把 線段樹 不斷地抽象，然後封裝起來，並且逐步引入新的模式來提高效率。
這裡稍作總結。
一開始的版本：
沒有泛型，不支援函式設定，只有區間求和查詢，還有單點值修改的操作。
稍微調整之後就有了第二個版本：
增加了泛型模板，並且提供了自定義函式，最重要的一點是：
嚴格地將資料結構剖析清楚：要求運算對型別構成么半群，
並且增加了一層抽象，這使得整個架構得以確立。
第三個版本就順理成章了：
將線段樹的結構從指標改為陣列，一點區別就在於：
指標實現的線段樹版本在整個樹結構中間可能會有空隙，於是陣列實現版本對此作了一些修改：將長度拓展為2的冪次，多餘的部分用么元來填充。
最後的部分建立在上述的工作之上，並做了大量效率的改進：
之前的版本都是不支援區間修改的，於是在此引入了lazy模式，將修改值放入對應區間中，並停止向下，直到必要時才執行pushdown（下推）操作向下更新。
這個思想被稱為 lazy evaluation ，在工程中被廣泛運用，比如cow（寫時複製）那樣的。
然而在這個版本的開發中遇到了一些問題，因為要支援
1. 基於值的修改
2. 基於增量的累積
魚唇的我在一開始沒有規劃好（後面會說到），於是在寫完的時候面臨乙個很詭異的bug：資料量很小時沒有問題，但是如果測試資料量很大時，會有2%左右的錯誤。於是只能硬著頭皮去debug。兩天之後，無果。
然後重新開始規劃，（這裡說的規劃指的是函式呼叫前後保持的某些狀態的約定或保證，有點類似很多演算法中的不變式。有了這種保證，在研究整個程式結構時會得到極大的便利）修改了一些函式的保證，以及對應的操作之後的狀態的保證。
這個工作比較麻煩（所以我一開始沒做），但是後期的便利程度和維護成本可以極大地提高和下降。
其實這裡面還有一點未完成的工作，就是我在考慮是否提供乙個介面，
使得使用者可以傳遞乙個修改函式。
但是面臨乙個問題：如果函式不是同態的，就幾乎只能去逐個修改。
如果是同態(homomorphism)，像這樣 f(
xoy)
=f(x
)of(
y)f (x
oy)=
f(x)
of(y
)，的確可以做一些優化，
如果有 cache 還好說，但如果有的只是 augment ，還是會面臨巨大的麻煩。
先寫這麼多，以後如果有機會還會寫
可持久化線段樹(persistent segmenttree)，不過那就是另一回事了。
最後，關於這方面的效率只能說差強人意吧，還有很多東西要搞：
rb_tree, buffer_pool, b+ / lsm，希望這些都可以盡快提上日程（
最近關於工作的幾點思考
吾日三省吾身，記錄一下近期關於工作的幾點思考。好記性不如爛筆頭，隨手記錄的習慣永不過時。舉幾個例子。以目標為導向，try any way。上栗子，在專案初期，定期的小組內部 dive deep 會議，及時交換想法，同步發現的問題並討論如何解決，不僅能規避重走彎路，也能提高生產效率，集思廣益，最大化團...
最近工作小結
1 由於上次加了報文上cpu的功能後，本以為該功能是能夠正常工作，報文上cpu是沒 問題的，但是經過測試發現，唉，怎麼什麼報文都能夠上cpu了。根據這個 現象，就想到了會不會是下發的acl有異常啊，然後去看sdk 然後一直以為這個cpu埠是已經從管理vlan中剔除的。最後也是在同事的建議下，去確認下...
最近的工作
從重慶來到杭州 由於對遊戲的熱情，來到杭州的第乙份工作是在網易的遊戲推廣部門，做遊戲推廣。當時負責了十五家網咖的推廣工作，遊戲是負責天下二了。做了半個月，發現自己還是對業務上的事和人都格格不入，放棄了，還是重回網路開發吧！接下來進到一家廣告公司，做 開發了，繼續我的.net生涯 先接下公司之前的活兒...