DBMS大作業之一 – B+樹

 我這學期的主要精力幾乎都放在這上面了，終於把第一個作業做完了，小結一下

與大頭的Pair Programming非常愉快，真是一個好的Partner
又一次見證了自己C++、指標、寫代碼的膚淺之處，原本對編程的自信在這一過程中喪失得體無完膚
不過很幸運，又有新的進步，又有新的提高
不但加深了對資料庫理論的理解，提升了自己的編程能力，同時認識到了自己多方面的不足

我追求的目標只是
每天有新的進步，每天都在做有意義的事情
這就足夠了

另外，你應該時刻感到滿足，因為你擁有很多人不曾擁有的一切
然後，你應該努力向前，向新的目標奮鬥

10月25日：
Pair Programming確實是個好東西
1.有助於克服惰性。在你不想寫的時候，你會想到你不能讓另外一個人失望
2.有助於休息。在累了的時候，可以更換一個人敲代碼
3.有助于思考。當你不在編碼的時候，它會強迫你思考
4.有助於新想法的產生。討論不但可以避免一個人編程時容易犯的慣性錯誤，還可以碰撞出思想的火花，同時讓編程變得更有樂趣
5.有助於傳播知識和經驗。三人行，必有我師焉。可以互相吸收經驗，以共同進步。
6.有助於培養團隊意識。

好了，不多說了。好東西要適當宣傳，但不必過分宣傳。
想知道其好處麼，試試就知道了。

10月30日：
用STL改寫大部分實現
STL真是個好東西，易用且不用太擔心出錯
於是興奮不已，狂編不止

11月5日：
記憶體泄露嚴重。機器越跑越慢，一看工作管理員，記憶體只增不減。
我覺得人就是這樣，不給你苦頭吃吃，你絕不會反省的。
到這時候我才想起來，<Effective C++>的建議是多麼有效
或者說，你沒體會到其重要性，只不過因為你遠沒達到那個程度而已

至此痛下決心，能不用指標則不用指標。

11月6日：
由於程式運行緩慢，下定決心改善效率。
以前總以為機器的速度足夠快，其實，只是因為你以前寫的程式太簡單而已
當寫一些處理超大資料量的程式時，你就會深感演算法和程式效率的重要性了

這次的大作業給了我又一次的反省機會，我很感激
很多時候我們總一廂情願地認為自己是對的，其實不過是井底之蛙而已，因為你看不到更廣闊的天空，所有你的思想膚淺而且固執
所以，我們所要做的，就是嘗試跳出自己習慣的這一片天地

11月7日：
為徹底解決記憶體泄露問題，學習使用_CrtDumpMemoryLeak輸出記憶體泄露
將所有的new操作全部取消，終於解決問題

11月8日:
終於嘗到最佳化的甜頭，將尋找操作由線性尋找改為折半尋找，效率立刻提高了100%
深感以前的盲目
不懂最佳化的程式員不是個好程式員
學習最佳化可以讓你學會很多知識
1.演算法和資料結構。這是最好的最佳化
2.語言的特性。想使程式跑得快，不懂語言的特性是絕對不可能的
3.組合語言。很多最佳化都得在彙編層次上進行
4.作業系統、資料庫、I/O，電腦群組成，電腦系統結構。真正的高手對這些有著全域性的把握，因為，只有瞭解這些
底層的東西，你才能把事情做得更好
浮雲遮避了眼睛，你需要透過它來尋找光明
學習要注意的是，深入，深入，再深入，然後淺出，然後跳出，然後在多個層次上看問題。這是高手的境界。
軟體開發也需要如此眾多的基礎知識，所以，是時候溫習那些你以為沒用的知識了

11月9日：
嘗到苦頭後，決定開始標準化
做任何事情都不能容忍破窗戶的發生
很多時候，為了一時的懶惰，付出的是長久的代價。而這份代價你在很久後才會體驗得到，後悔或許來得及，但很昂貴
雖然我很確切地知道這一點，但同樣的錯誤仍然一再地發生，我在試圖糾正，並希望這是個迭代的過程
我發現想要做好一件事情並不難，一是興趣，二是認真，三，還是認真。

11月10日：
學會使用profile.exe衡配量序開銷
並成功發現我們在緩衝管理時有一塊很嚴重的效能問題，就是一個替換隊列在插入和刪除時佔據了程式大部分的已耗用時間
從而導致緩衝區開大程式運行速度反而降低的情況
經調整，將緩衝管理改為CLOCK演算法實現，成功解決該問題
工欲善其事，並先利其器
很多好的工具可以極大地提高我們的效率，可惜很多時候我們並不願去學習使用它們
下決心要好好學習下Emacs和Latex了

11月12日：
我是愛書之人，對於電腦類的書籍，更有自己的一份執著與熱情
每每到圖書館，新發現一本好書，總是心情愉悅然後深感自己的不足，然後定然要借來或買來一閱
項目驅動學習是個很好的方法，我想極限編程的概念或許也可以應用到極限學習方面吧
翻閱的與這次作業有關的書如下：
<C++大學教程>、<C++標準模板庫>、<C++編程規範>、<Effective C++>
<C專家編程>
<代碼最佳化-有效使用記憶體>、<代碼大全>
<演算法導論>、<演算法I-IV C++實現>
<資料庫系統實現>、<資料庫管理系統>

11月15日：
受大頭老闆的啟發，可以在工作管理員中啟用I/O寫入和I/O讀取以監測I/O的實際使用狀況
哈，有時真是可以一語道破天機啊
我一直在思考一個問題，究竟是書還是人可以給你一條更好的學習指導道路。答案可能是，BOTH。
可惜實踐驗證我們的問題主要是出在記憶體處理上。

11月23日:
受到<程式員修鍊之道的啟發>，決定測量一下程式實際的輸入和已耗用時間之比。我認為它不是線性，否則怎麼會運行得如此之慢呢
結果再次讓我一方面失望一方面欣喜，這個看起來慢得不行的程式，它的插入操作竟然是呈線性增長的