不經意看到了程序員的一期算法專題，細細研讀多位高手（包括李開復）的文字之后，對算法的重要性重新進行了反思。我研究生畢業
2
年，一直從事
J2EE
開發，由于項目的原因，很少需要自己去設計算法，甚至
stack
，
tree
這些數據結構都很少使用。還好自己也不甘于平淡，如
Effective Java
，
Practical Java
，
Refactory
，
Design Pattern
等等這些流行書還是抽空學習，這些書的確很是經典，對我的編碼風格，模式的理解，設計能力都起到了很好的促進。也快速的由一個程序員成長為架構師（只是公司的，離真正的架構師還差得遠）。
因為項目需要，去年下半年開始全面接觸開源軟件，使用了
spring
，
maven
，
hibernate
，
ibatis
等眾多開源軟件，也對開源軟件產生了濃厚的興趣，于是拿這些開源軟件做了
openfans
，一方面是推進開源軟件在中國的使用的交流，一方面也為自己在實踐中更多使用這些軟件（因為沒有項目和利益因素，可以做想做的事，用想用的軟件）。使用這些開源軟件倒很是順利，很多軟件拿來就能用，都有
sample
，簡單使用還是不難的。
但一些關鍵的問題一直懸而未決！比如
tag
的設計：我現在簡單的使用平鋪的模型，
tag
沒有層次之分，
tag
間產生雙向關聯。但這樣是最符合
tag
特性的模型嗎？如何對這些
tag
進行分類，如何定義
tag
的多級關聯（如
spring
和
hibernate
有關聯，
hibernate
又與持久層關聯，
spring
是否與持久層有間接關聯，依次類推）。。。。。。而做出一個好的
tag
模型，可能就需要圖論方面的知識。再比如用戶相似度設計（號稱是豆瓣的核心，難以復制）：每個用戶擁有了一些
tag
，如何根據這些
tag
定義用戶的相似度，一個用戶有
spring
，
hibernate
這
2
個
tag
，一個用戶有
spring
，
ibatis
這
2
個
tag
，他們相似度為多少，如果每個人
tag
都很多，再加上權重的概念，問題又復雜的多。簡單的做法就是每個用戶
tag
一個個匹配，匹配的越多相似度越大，但這樣設計一是不準確，二是時間復雜度很大，最壞情況為
n*n*m*m
，
n
為用戶數，
m
為每個用戶的
tag
數。
這些都需要扎實的算法基礎。而我的基礎就很薄弱：本科學的比文科還文科的專業，研究生又學的比較上層的東西（
UML
，
RUP
，
PM
等，也都一知半解），選修了一門算法導論，又被
1000
多頁的經典英文教材嚇趴下了，上了幾次課就直接放棄，沒敢參加最后考試?，F在想臨時抱佛腳，談何容易。
所以算法也并非沒有用處，關鍵要看你在做什么，想做什么。想去
google
、百度不用會
spring
，算法基礎扎實，只會
c
語言都行；一些行業如電信、金融也很是需要算法高手。而國內更多的企業做企業應用，一般是連連數據庫，寫寫頁面，最多引入些開源框架和軟件，如
spring
，
hibernate
，
struts
等。這方面的需求較大，會了
spring
，省了公司的培訓成本，自然還是給找工作加了一些砝碼。
所以有時聽到某些人對某項技術不以為然，說“這些東西有什么是我在幾個星期學不會的”的時候，一方面是對其狂妄進行些鄙視，一方面也真要問問自己，我的核心價值到底在哪。這個問題很重要，涉及面很廣，選擇也很多，而我也只是有些模糊的答案，等以后再仔細寫寫。
不管如何，我是要開始研究算法了，得解決問題阿！先在
openfans
開個算法的
tag
，一邊學一邊積累，對算法有興趣的同學也可以跟我一塊進步。
PS
：做個廣告，
blogjava
很多好的
bloger
，能否到
www.openfans.net
導入下
blog
，跟大家分享下你的感悟，謝謝！