最近搞了乙個演算法，尋找k個有序陣列中，順序為n的那一頁資料。最開始的時候，我用假資料填充法處理了一種特殊情況。實現完上線以後，才發現資料填充存在問題。於是趕緊修改。修改完以後，寫了case去驗證。竟然發現修改前後的版本都能完全通過這些case。我大惑不解，拼命想構造出一組讓舊版本fail，而讓新版本成功的case，結果只是發現，雖然假資料填充是不對的，但是結論卻是對的。
雖然白白花了兩天時間，但是這次經歷還是值得銘記的。它讓我永遠記住，bug是需要驗證的，先找出讓bug出現的case，再尋找解決bug的方法。而不是按照自己的想象去解決bug，乙個根本不存在的bug。
我的演算法的輸入輸出可以用如下的例子來說明：
舉例來說：
11,2,3,4,5,6,7,8 …
22,4,6,8,10,12 …
33,6,9,12,…
那麼n=8，page=10，應該輸出
11,2,3,4,5,6,7,8，9,10,11，12
22,4,6,8,10,12
33,6,9
注意到被刪除的元素剛好是8個，剩下的元素剛好是10個。
我所採取的演算法是取每個佇列的 n/3 ，再找出其中的最小值，刪除對應的子串行。比如以表一為例，n/3分別是。其中3對應佇列1，是最小的，因此刪除佇列1的1和2。我稱這個過程為尋找guard的過程。找到的guard進行比較，guard最小的佇列刪除guard之前的元素。看起來沒有問題。可是，如果佇列的資料不夠，n/3對應的位置空缺，guard找不到怎麼辦。
我之前的假設是每個佇列的後面都有無數個「無窮大」。當guard的位置超過佇列的長度，guard都是無窮大，因此怎麼都不會是最小。然後無窮大在輸出的時候都是最後輸出的，不會干擾正常資料的輸入。
但是有個問題容易造成困擾，就是guard小的佇列被刪除。有可能那個超出範圍的佇列比「guard敗者」的佇列更小，刪除它，有沒有可能刪除掉本該出現在結果集的元素呢？不會。因為假設a佇列元素個數為x，x 背景描述 近期要去講一次重構，想收集乙個案例，恰好從網上看到了乙個朋友寫的乙個計算算術表示式的 c 程式，原程式是計算含括號的正整數表示式的四則運算值。讀後，發現問題比較多，而且邏輯有錯誤，因此對其進行了重構。為簡化起間，將程式的功能進行了簡化 1 計算的算術表示式只含有 運算 2 不含有括號 3 ... 背景描述 近期要去講一次重構，想收集乙個案例，恰好從網上看到了乙個朋友寫的乙個計算算術表示式的 c 程式，原程式是計算含括號的正整數表示式的四則運算值。讀後，發現問題比較多，而且邏輯有錯誤，因此對其進行了重構。為簡化起間，將程式的功能進行了簡化 1 計算的算術表示式只含有 運算 2 不含有括號 3 ... 十一長假，無處可去，也哪兒也不想去。正家中閒坐，同學邀請明日去森林公園一遊，欣然點頭。轉過身來，妻子轉告 朋友們明天森林公園聚會。女怕撞衫，男怕撞席。不自覺中，我變成了鏈結兩個party的關鍵人物。10點，三個it家庭會面。開始吃吃喝喝，順便談談子女教育。11點，兩個媽媽帶著孩子過來，話題開始散亂。...一次典型的重構
一次典型的重構
一次失敗的聚會