1. 數據結構初體驗
在大學期間學習數據結構時覺得很優美，因爲選擇一個好的數據結構可以讓代碼更加簡短、容易閱讀。並且很快也有了一個實踐機會，就是自己決定做一個LISP 解釋器。這個軟件的代碼總共花了3周寫完，但是設計時間很長。實際上，其中的LISP的語法非常簡單，而實現的時候主要涉及到數據結構中廣義表，概念很多，但是在數據結構的書中介紹不多，只有自己逐步去理解，可以說，LISP解釋器程序的編寫中，自己的思考佔了大部分。完成後的結論是，只要充分理解廣義表，並且把這個理解結合到LISP解釋器程序中，要花費幾個月，但是很值得，因爲整個程序的實現代碼就變得很簡潔、容易擴展，看這樣的代碼讓人感到很享受。
2. 不甚樂觀的現實
我在負責公司技術人員招聘的時候，其中有不少人是剛剛畢業的學生，他們沒有工作經驗，因此，數據結構是主要考查的內容，可是我發現這樣的基礎課程有很多人並不瞭解。一次“成都軟件技術沙龍”交流，一個朋友提出的真實的招聘也印證了這一點。
這個朋友給我講了一次典型的招聘後，他認識到數據結構課程中非常基礎實用的內容對很多學生來說也並不瞭解。當時招聘來了約100個學生，他提了一個問題，就是誰會寫冒泡排序算法，讓知道的人舉手，大約有10個人舉手，然後請他們來做，發現只有兩三個人做對。其實，數據結構中最基礎的就是排序和查找，而冒泡排序是基礎中的基礎，只要10行左右的代碼，逐個比較，兩層循環，大的向上浮動，所以叫做冒泡排序。爲什麼做不對呢？這不是簡單的智力問題，而是不知輕重和權衡。
有些人認爲只要會IDE和語言就行，基礎知識不重要了，我不以爲然。這些年來，看慣了很多程序中大量嵌套的if else，大量的嵌套，混淆的語義，也看多了大量的重複代碼。因此，更加覺得有抽象思維能力、基礎紮實的可貴。
3. 可以有更多應用的狀況
控件代碼常常需要用到數據結構。有機會看了國內一個人寫的一個report控件，該控件基於GPL協議發佈，其中的代碼完全是他自己寫的，包括一個個的線、一個inplace的小edit、鼠標移動cell線等。原始的ereport共5000行，其中的註釋也比較有意思，比如
“今天早晨有一個大豔陽天，我的打印...”,
“又是一個不眠夜”，
記載了這個人開發過程的酸甜苦辣。
ereport內給人印象最深的是，當用戶的數據以dataset方式進來後，所有的排序、分組的累計都是通過for循環來做的。爲什麼不使用現成的呢？可能是因爲Delphi過於龐大，沒有提供這樣的一套算法。decal是Delphi的一套Third Party 算法庫，但是並不是所有的人都知道。隨後的分組也由自己來寫。這樣，ereport內就有大量的排序算法、分組算法，以及和它們伴生的數據結構。
稍微複雜的算法也需要數據結構。我們接到了一個產品，叫做報表精靈，其實就是一個類似desisioncube的數據分析控件，其中涉及對數據鑽取、切片、分組和排序等操作，可是現成的控件都不能滿足我們的要求，要自己做，再一次涉及基本的數據結構。
要寫出漂亮的代碼，不能不瞭解數據結構。代碼總是有控制結構和數據結構構成的，這就是Niklus Wirth所說的“程序=數據結構+算法”的含義。可是很多人只知道大量善用控制結構如if ，while等，卻不知道善用數據結構，比如Array，List ,Collection，HashTable 。控制結構可以表達分支、循環的流程，數據結構因爲它本身的設計可以隱含分支、循環，因此同樣可以表達這樣的流程。不同的是，用精巧的數據結構來表達分支、循環的意圖，常常會比用控制結構來表達更加容易閱讀和理解。一般程序員認爲產品開發的技術要求不高，只要搞清楚業務就可以，就是就有大量的簡單堆積、大量嵌套的代碼佈局——這就是爲什麼很多人認爲數據結構不重要，總覺得沒有用武之地的原因吧。
4. 現實的MIS編程
我們常說，IT工程師的技術常常很久不更新，原因是現在IT業對他們的要求都不高。簡單地說，對做軟件系統的人來說，只要要能夠使用SQL，能夠連接上數據庫，然後繪製界面，把數據改一改，掛接到界面上，這個基本功就夠了。因爲這樣的低要求，也因爲缺乏代碼評審，重複的代碼、大量的嵌套就會出現。
IT新人在頭一年做項目時，要做的就是反覆操練這樣的技術，在不同的場景下用少量的變通，然後學習如何偵查到錯誤並且修正它。如果確實有自己技術上搞不定的問題，知道如何得到解答，然後反覆練習，直到熟練。這一段時間是最難熬的日子。
簡單的使用TStringList.sort，複雜的使用SQL數據庫，排序、分組都可以的。數據庫SQL更加無所不能，一個子句就可以完成一個排序，一個子句就可以完成一次分組。讓程序員不再重視數據結構，進而不重視抽象思維，這裏說的是一般編程。說到優化，難免要閱讀他人代碼、分析結構；說到設計，也是如此，程序員的抽象能力是跨越臺階的必要條件。
