當技術已經產品

當技術已經產品，我是程序員，儘管工做三年，可是在初級的路口徘徊。一直在考慮，如何去作好技術這件事情？如何去區分業務和技術，又如何去融合業務和技術，從而來提升咱們的工做效率？一直很困惑。

 

今天，我跟同窗去爬北高峯，忽然有所感悟。如何去融合業務和技術。前幾天，我偶爾在看看《Java特種兵》（謝宇），一本很nice的書（學java讀者能夠推薦去看）。其中，有一部份內容是程序員也應該懂點數據庫。其中一個觀點是能夠將數據庫看成一種產品。那麼，我將問題就概括爲：你如何去熟悉這款產品？如何才能說明你已經瞭解這款產品？同理，java也能夠看成一種產品，那麼，你又要如何去理解？如何表示你已經理解？同理，本身公司的一款產品，你應該如何去深刻理解，如何去優化你的產品？當時，我並非很理解。

 

最近買來了李林峯的《分佈式框架與實踐》（值得讀一本書，做爲對分佈式框架知識結構整理，很推薦）。翻了他的目錄結構。終於明白，原來分佈式框架基本上作了這些事情。不管使用的框架是dubbo，仍是其餘。他能夠將分佈式框架這一塊的產品，作一種抽象。你只要理解這些抽象，就能夠明白基本上全部分佈式框架所作的事情。這又讓我想到了mysql。咱們有如何去深刻理解它呢？對，就是明白關係數據庫的抽象。例如，事務，查詢計劃，數據存儲引擎。這三樣，其實不管在mysql，sqlserver，仍是oracle都是存在的。同時，又明白通用的一款產品，能夠作不一樣的設計，儘管流程上是同樣的，意圖上是有差別的。

 

最後一點，是對數據結構和算法的理解。其實，沒有數據結構這種東西。咱們生活中的需求，就只有排序和查找這兩件事情。排序，能夠根據某個特徵排序，爲了作好這件事情，咱們就要考慮各類事情，他們怎麼存的，這就有了數據結構。就出現了堆排序，快排，桶排序，歸併排序等等。查找，這個是更加須要考慮存儲結構的。存儲結構的好壞，致使不一樣查詢的效率。這就有出現數據結構。例如O（lgN）的bst，O（1）的hash等等。最後的抽象，也就排序和查找。他們的實現原理，就是他們的存儲結構和算法。worths大神總結：程序 ＝ 數據結構 ＋ 算法。之前，總覺得你寫了sql（至關於算法），就能夠不考慮性能。可是，你不明白存儲結構，你的性能就有點瞎。

 

沒有具體去解釋，如何去熟悉產品！可是，這裏已經足夠一部分。技術能夠看成產品，產品看成技術。抽象是個好方法。接下去，能夠會寫一些我對這個理解的實戰。若有更多的想法和意見，能夠在評論處交流。