這些年,這些挖掘機算法,這些反思

這些年,這些挖掘機算法,這些反思

寫這篇文章，緣自於前幾天部門內部成員們進行了一次部門內部現有涉及的一些算法的review以及整理。不過比較囧的就是，因爲boss不在，咱們討論討論着就成了吐槽大會，卻是有一半時間在吐槽產品以及業務部門了~~不過這也算是一件可喜可賀的事情了，這也能夠看作是咱們數據部門，已經由開輕型挖掘機向深挖階段邁步了。

所以，藉此機會，也對本身接觸過的，瞭解過的，或者作過的一些勉強稱得上算法的東西作一個梳理。其實，就我的來講，自己就不是作算法出身的，在大學時代，學習的反卻是網絡方面多一些，更不知數據挖掘算法爲什麼物。

其實，就所謂算法而言，我的認爲，我有個同事說的很對：所謂算法，並非說那些複雜的數學模型纔是算法，哪怕是你寫的一個簡單的計算公式，只要可以解決現有業務的痛點，有了本身的模型思路，它就是一個算法，只是它可能不夠通用，只能解決特定業務需求而已。

在大規模的數據前提下，其實不少複雜的算法過程，反而效果沒有這麼好，或者說，咱們會千方百計去簡化其過程。

舉個簡單栗子：假設有一批大規模數據集，就以近千萬篇博文爲例。若是提供一篇博文，讓你去查詢與其類似度最高的top N，那咱們的一般思路是什麼?一般的作法是計算這篇博文與其餘博文的類似度，至於類似度的計算方法就不少了，最簡單的就是計算其向量夾角，根據向量夾角斷定類似程度。OK，就算你用最簡單的計算過程，你試想一下，運算近千萬次須要多久?或許，有的人說，俺使用hadoop，利用分佈式的計算能力來完成這個任務，但若是實際操做起來，你就會發現這是一個多麼蛋疼的事情。

再舉一個簡單栗子(好吧，多吃點栗子)：好比SVM，這是一種難以收斂的算法，在大數據的前提下，有些人但願使用它，但又但願使用更多的數據來訓練模型，畢竟手裏數據量太大，不少人仍是但願使用盡可能多的數據訓練的，以達到模型更準確的目的。可是，隨着訓練數據量的增大，像SVM這種難以收斂的算法，其耗費的計算資源仍是很巨大的。

東拉西扯說了這麼多，自個的梳理工做尚未完成呢!

1、這些年，我開過的挖掘機

(1)最先接觸的應該是貝葉斯的分類了

貝葉斯算是分類算法中最簡單的算法了，初學挖掘機算法的人十有八九第一個愛上的絕對是它。其實，貝葉斯的原理真的很簡單，就是依據統計學的最大機率原理。這麼簡單，可是就是尼瑪這麼好用，多年依然屹立不倒。

訓練過程就缺少可陳了，基本上貝葉斯的都這樣，因爲是文本，因此一套流程下來，分詞，去停詞，做爲最基本的知識點向量，而後就計算模型機率了。不過比較有趣的是，分類過程是放在Storm裏頭作的，至關於這是一個實時的分類業務。

(2)說到了文本，天然少不了分詞算法了

其實說到分詞算法，反倒沒啥可說的。現在互聯網上各類開源的分詞工具，都已經作的很好了，效果也差不了多少，想進一步改進的話也夠嗆。至於說深刻到分詞算法的內部，涉及上下文法分析，隱含馬爾科夫模型等東西，若是是我的出於興趣去研究，那我沒話說;若是是小公司，花費人力物力去優化分詞效果，我只能說他們閒着蛋疼;若是是大公司，人家金多任性也是能夠理解的。

因此，至今來講，我的對於分詞方面的東西，也僅限於初步瞭解分詞算法的衍變，內部大概涉及的算法，以及幾種分詞工具的使用。

其實，在文本挖掘方面，僅僅針對於文本的分詞是不夠的，由於咱們使用分詞拆分出來的單詞，每每不少跟業務都是沒有關係的，一般作法是，創建對應業務字典，至於字典的創建，固然也是須要分詞的，再進行進一步的加工，甚至可能會加上一些人工的工做。

(3)下一個就是實時熱點分析了

我也不知道這算不算是算法，說到實時，天然跟Storm又有關係了(好吧，我認可我是搞這個以後開始接觸數據的)。說到實時熱點，可能大夥兒都摸不着頭腦，舉個簡單栗子就明瞭了。

玩hadoop的童鞋都知道WordCount這個經典栗子，MapReduce在Map到Reduce的過程當中，自動將相同的Key經過相似hash的方法聚合到一塊兒了，因此，統計單詞這個需求經過MR來作是辣麼的簡單。

那Storm的實時WordCount呢?好吧，這也是一個可以記錄到實時技術領域史書上的經典案例(好吧，其實它就是一個Storm的HelloWorld)。Storm雖然沒有相似MR那種自動Hash的功能，不過它也提供了一種數據分組流策略，也能達到相似的效果，而且它不像MR那樣是批量的，它是實時的、流式的，也就是說你能動態的獲取到當前變換的單詞詞頻。

實時熱點分析，若是咱們把熱點映射成單詞，那咱們是否是就能夠實時的獲取到當前Top N的熱點了。這個方向但是有很大的研究價值的，實時地掌握了用戶的熱點導向，咱們就能夠動態的調整業務策略，從而衍生更大的數據價值。

不過，整體來講，這個數據模型更多依靠的是Storm這個實時工具的自己功能，模型設計上的東西反卻是少了。至於說算不算是算法模型，就跟前面所說的那樣，看我的見解吧，你說是就是了~~

(4)國內很成熟的一種建模--推薦

就目前在國內作數據挖掘的來講，可能分類與推薦是作的最多的兩種方向。分類就很少說了，就好比剛纔所說的貝葉斯，簡直就是分類中的鼻祖算法了。

可能一說到推薦算法，有人腦海裏立馬就閃現出關聯規則、協同過濾、餘弦類似性等這些詞。這是沒錯的，但我要說的不是這個。其實我的想說的是推薦就兩個方向：基於用戶，基於內容。

咱們須要注意兩點，咱們推薦的對象是用戶，或者說是相似用戶這種有動做行爲的實體;而推薦的東西則就是內容，他沒有動做行爲，可是他有不一樣的屬性，或者用更磚業說法描述就是他必然有知識點。

基於用戶推薦，咱們看重的不是內容這個實體，而是用戶自己的行爲，咱們認爲用戶的行爲必然隱含着一些信息，好比，人的興趣導向，那麼既然你有了相關的行爲，那麼我按照你的行爲去給你推薦一些東西，這老是有必定道理的。

基於內容的推薦，咱們的側重點則是內容，這就跟用戶的歷史行爲無關了。咱們潛意識的認爲，既然你會看這個內容，那麼跟這個內容有關係的內容，你是否是也感興趣呢?或許這樣說有失偏頗，可是大致方向是對的。

至於以前說的那些關聯規則也好，協同過濾也好，餘弦類似性也好，其實就是研究知識點與知識點之間關係所創建的模型。

針對於基於內容推薦，其知識點就是內容之中的各類屬性，好比影片推薦，其知識點可能就是各類評論數據、點播數據、頂踩數據、影片類型、演員、導演以及其中的一些情感分析等等;又好比博文，其知識點可能就是一個個帶權的詞，至於這個詞就涉及到詞的抽取了，再說到詞的權重，可能就會涉及到TFIDF模型、LDA模型了。

而針對基於用戶，其知識點最直接的體現就是用戶的行爲了，就是用戶與內容之間的關係，不過深究下去，又會發現，其實跟內容的知識點也緊密聯繫，只不過這可能不止一個內容實體，而是多個內容實體的集合。

(5)文本單詞的加權模型

前面正好提到了TFIDF以及LDA模型，因此順帶也就講講文本單詞相關的加權模型吧。

說到文本挖掘，可能大部分人都熟悉TFIDF模型，既然涉及到了，那就簡單的說一說。咱們知道，文本的知識點就是一個個的單詞，雖然都是單詞，但也總有哪一個詞重要程度高一點，哪些詞重要程度會低一點吧。

或許有人會說，出現多的詞就重要。沒錯，那就是詞頻，簡單的來想，這種思路並無錯，而且，早期的文本挖掘模型就是這麼作的。固然，效果確定是通常般的。由於那些常常出現的詞每每都是一些沒用的經常使用詞，對文章的做用並不大。

直到TFIDF模型的出現，才根本性地解決了文本挖掘知識點建模的問題。如何判斷一個詞的重要程度，或者專業點的說法就是判斷其對文章的貢獻度?TFIDF經過詞的詞頻來加大詞在文章中的權重，而後經過其在多個文章中的文檔頻率來下降其在文章中的權重。說白了就是下降了那些公共詞的權重，把真正貢獻度大的詞給暴露出來。這基本就是TFIDF的基本思路了，至於詞頻權重怎麼加大，文檔頻的權重怎麼下降，這就涉及到具體的模型公式了，根據不一樣的需求進行調整就OK了。

關於文章知識點主題建模的另一種很重要的模型，那就是LDA模型了。它是一種比較通用的文章主題模型，它經過幾率學原理，說白了就是貝葉斯，創建起知識點(也就是詞)，主題和文章的三層關係結構。詞到主題有一個機率矩陣，主題到文章也有一個機率矩陣的映射關係。

好吧，LDA不能再說下去了，再說下去就露餡了。由於，俺也不是很懂啊。對於LDA，雖然部門內部有在使用，可是我沒有作過具體的模型，只是和同事討論過它，或者更確切的說向同事請教過它的一些原理以及一些設計思路。

(6)類似度計算

類似度計算，好比文本的類似度計算。它是一個很基礎的建模，不少地方就用的到它，好比剛纔咱們說到的推薦，其內部關聯的時候，有時候就會涉及到計算實體間的類似度。

關於文本的類似度，其實方法有不少。一般會涉及到TFIDF模型，拿到文本的知識點，也就是帶權的詞，而後經過這些帶權的詞去作一些類似度的計算。

好比，餘弦類似模型，就是計算兩個文本的餘弦夾角，其向量天然就是那些帶權的詞了;又好比，各類算距離的方法，最著名的歐式距離，其向量也依然是這些詞。還有不少諸如最長公共子串、最長公共子序列之類的模型，我的就不是很清楚了。

總之，方法不少，也都不是很複雜，原理都很像。至於哪一個合適，就得看具體的業務場景了。

(7)文本主題程度--信息熵

曾經和同事嘗試對數百萬的博文進行領域劃分，把技術博文劃分紅不一樣的領域，好比大數據領域、移動互聯網領域、安全領域等等，其實說白了仍是分類。

一開始咱們使用貝葉斯進行分類，效果還行，不過最終仍是使用SVM去建模了。這都不是重點，重點是咱們想對劃分到某一領域下的技術博文進行領域程度判斷。

咱們想了不少辦法，嘗試創建了數據模型，但效果都不是很理想，最終迴歸到了一個最本質的方法，那就是使用文本的信息熵去嘗試描述程度，最終結果仍是不錯。這又讓我再一次想到同事說過的那句話：簡單的東西不必定很差用!

信息熵描述的是一個實體的信息量，通俗一點說就是它可以描述一個實體的信息混亂程度。在某一個領域內，知識點都是類似的，都是那些TFIDF權重的詞，所以，是否是能夠認爲，一個文本其信息熵越小，其主題越集中越明顯，信息的混亂度越低，反過來講，有些文本主題很雜亂，可能包含了多種領域的一些東西，其領域的程度就會下降。

最起碼錶面上，這種說法是行得通的，而且實際的效果還不錯。

(8)用戶畫像

用戶畫像這個方向多是近兩年比較火的方向了。近年來，各大互聯網公司，各大IT企業，都有意識的開始從傳統的推薦到個性化推薦的道路衍變，有些可能作的深一些，有些可能淺一些。

商業價值的核心是用戶，這天然不用多說。那麼如何結合用戶進行推薦呢，那就是用戶的屬性，那關鍵是用戶的屬性也不是一開始就有的，咱們全部的只是少許用戶的固有屬性以及用戶的各類行爲記錄。咱們連用戶是啥子裏狀況都不清楚，推個毛啊!

因此，咱們須要瞭解用戶，因而對用戶進行用戶畫像分析就頗有必要了，其實就是把用戶標籤化，把用戶標記成一個個屬性標籤，這樣，咱們就知道每個用戶大概是什麼狀況了。一些商業行爲，也就有了目的性。

至於說如何對用戶的每個畫像屬性進行填充，這就看具體的狀況了。簡單的，用幾個簡單模型抽取到一些信息填充進去;複雜的，使用複雜的算法，經過一些複雜的轉換，給用戶打上標籤。

(9)文章熱度計算

給你一大坨文章，你如何判斷哪篇文章比較熱，哪篇文章比較矬，換個說法就是，我進入一個文章列表頁，你能給我提供一個熱文章的排序列表嗎?

可能大部分的思路都很直接，拿到文章可以體現熱度的屬性，好比點擊率、評論情感分析、文章的頂踩狀況，弄個簡單加權計算模型，咔咔就出來了。

本質上這沒錯，簡單的模型在實際的狀況中不必定很差使，部分屬性也的確可以體現出一篇文章的熱度，經過加權計算的方式也是對的，具體的權重就須要看具體狀況了。

但若是這麼作的話，實際上會出現什麼狀況?今天我來了，看見了這個熱度推薦列表，明天我來了，仍是看到這個列表，後天我來了，依然是這個列表。

尼瑪，這是啥狀況，咋每天都是這個破列表，你要我看幾遍?!不錯，這就是現實狀況，形成的結果就是，越熱的文章愈來愈熱，越冷的文章越冷，永遠的沉底了，而熱的文章永遠在前頭。

如何解決這個問題?咱們把時間也加入參考，咱們要把老文章經過降權的方式，把他人爲的沉下去，讓新文章有出頭的機會。這就是說，須要咱們把建立時間也加入權重中，而且隨着時間推移，衰減其熱度權重，這樣，就不會出現熱的一直熱，冷的一直冷了。至於衰減的曲線，就須要看具體業務了。

這樣就能解決根本問題了嗎?若是文章自己信息量就不夠呢，好比，自己大部分就是新文章，沒有頂踩，沒有評論，甚至連點擊曝光都不多，那用以前的模型就行不通了。

那是否是就無解了呢?方法仍是有的，好比，咱們尋找到一個類似的站點，他也提供了相似最熱文章推薦的功能，而且效果還很不錯。那麼，咱們是否是就能夠藉助它的熱度呢?咱們經過計算文章類似度的方法，復刻出一個最熱列表出來，若是站點性質類似，用戶性質類似，文章質量不錯，類似度計算夠準確，相信這個熱度列表的效果也是會不錯滴(這方法太猥瑣了~~)。

(10)Google的PageRank

首先，別誤會，我真心沒有寫過這個模型，我也沒有條件去寫這個模型。

認識它瞭解它，緣自於跟幾個老同窗合夥搞網站。既然搞網站吧，做爲IT人猿，一些基本的SEO的技術仍是須要了解的。因而，我瞭解到：想要增大網站的權重，外鏈是不可缺乏的。

我跟我幾個老同窗說，大家去作外鏈吧，就是逮住網站就放咱網站的連接。他們問到：一個網站放的連接越多越好嗎?放的網站越多越好嗎?啥網站放比較好?這都不是重點，關鍵是他們問：爲毛啊?

把我問的那個是啞口無言啊，因而我一怒之下就去研究PageRank了。PageRank具體的推演過程我就不說了(何況憑藉我這半吊子的水平也不必定能說清楚)，其核心思想有幾個：當一個網頁被引用的次數越多時，其權重越大;當一個網頁的權重越大時，其引用的網頁權重也隨之增大;當一個網頁引用的次數越多時，它引用的網頁給它帶來的權重越低。

當咱們反覆迭代路上過程時，咱們會發現某個網頁的的排名基本就固定了，這就是PageRank的基本思路。固然也有個問題須要解決，好比，初始網頁如何給定其初始權重，高計算迭代過程如何簡化其計算過程等等。這些問題，在Google的實際操做中，都作了比較好的優化。

(11)從互聯網上定向抓取數據

其實我估摸着這跟算法沒很大關係了，不過既然有數據的獲取設計流程，也勉強算是吧。

之因此有這個需求，是那段時間搞網站搞嗨了，給本身整了個工做室網站，想給別人尤爲是一些小企業搭建包括輕度定製企業網站(是否是挺瞎折騰的-_-)，也確實是作了幾個案例。

因而乎，俺就想啊，如何給本身找客戶?工做室的客戶應該是那些小企業的老闆，而且還必須是目前沒有企業門戶的。做爲一個搞數據的程序猿，而且仍是開挖掘機的，雖然是半路出身非藍翔畢業且無證上崗，但好歹是挖過幾座山頭的呀。

現在是互聯網橫行的時代，他們總會在互聯網上留下一些蛛絲馬跡，我要把它給逮出來!個人目標很明確，我要拿到那些無企業網站的企業郵箱，而後作本身EDM營銷(電子郵件營銷)。

1)我先從智聯檢索頁面，抓取了企業規模小於40人的企業名稱，事實證實智聯招聘的頁面仍是很好解析的，都是靜態的，而且格式很規整，因此很容易就分析出一批小企業的企業名來了;

2)拿到了企業名，我如何判斷這個企業已經有了獨立的企業官網?經過分析，我發現經過搜索引擎檢索這個企業名的時候，若是有企業官網的話，必定是在首頁。而且其頁面地址也是有必定規律的，那就是：獨立官網的開頭一般是www開頭的，長度通常不會太長，收尾一般是index.html、index.php以及index.asp等等。

經過這些規則，我就能夠將那些有企業官網的企業名給pass掉了。其中遇到了兩個難點，一個就是搜索引擎的不少頁面源碼都是動態加載的，因而我模擬了瀏覽器訪問的過程，把頁面源碼給抓取下來了，這也是爬蟲的通用作法;第二個就是，一開始我嘗試的是經過百度去獲取，結果百度貌似是有放結果抓取的一些措施，致使結果不如人意，因而我換了目的，使用的是360的檢索，問題就解決了(事實證實百度在搜索引擎方面比360仍是強了很多的)，而且效果也差很少。

3)解決了排除的問題，那根本的問題就來了，我如何拿到企業的企業郵箱?經過分析搜索引擎的返回結果，我發現不少小企業喜歡用第三方網站提供的一些公司黃頁，裏頭包含了企業聯繫郵箱;還有部分公司發佈的招聘信息上會帶有企業郵箱。

經過數據解析，終於拿到了這部分數據，最後還作了一些相似郵箱是否有效的基本解析等等。最終拿到了大概3000多個企業郵箱，有效率達到了80%以上。

問題是解決了，但仍是有些地方須要優化的：首先就是效率問題，我整整跑了近12個小時，才把這3000多個郵箱給跑出來，太多須要解析的地方，而且模擬的瀏覽器在效率上不高;其次就是對郵箱的有效不是很好判斷，有些郵箱根本就是人爲瞎寫的;還有就是部分網站對郵箱進行了圖片化混雜處理，即作成了相似的驗證碼的東西，防抓取，我沒有對圖片類的郵箱數據進行解析，其實這個問題也是有解決辦法的，咱們拿到一些樣本圖片，進行圖片字母識別的訓練，這樣就能解析出其中的郵箱了。

整體來講，此次體驗仍是挺有成就感的，畢竟在業餘的時間解決了本身實際中的一些痛點，熟練了一些所學到的東西，或者說實施的過程當中學到了不少東西。

ps：github上檢索webmite就是這個項目了，我把代碼託管到了github上，或者從個人博客上進入。

2、對本身作一個總結吧

其實我的的缺點很明顯，首先就是沒有通過系統的數據挖掘學習(沒去過藍翔，挖掘機自學的)，也就是野路子出身。所以對不少算法的原理不夠清楚，這樣的話，對於有些業務場景，可能就提不出有建設性的意見了。而且，對於不少算法庫的使用，仍是不夠了解的。

其次就是在數學功底上有所欠缺。咱們知道，一些複雜的算法，是須要有強大的數學基礎的。算法模型，其本質就是數學模型。所以，這方面也是個人短板吧。

因爲我的是由作大數據偏向挖掘的，基於大數據模式下的數據挖掘過程，可能跟傳統的數據過程有很大的不同。好比，數據的預處理過程，大數據挖掘的預處理不少依賴的是目前比較流行的分佈式的一些開源系統，好比實時處理系統Storm、消息隊列Kafka、分佈式數據收集系統Flume、數據離線批處理Hadoop等等，在數據分析存儲上可能依賴的Hive以及一些Nosql會多一些。反倒對於傳統的一些挖掘工具，好比SAS、SPSS、Excel等工具，我的仍是比較陌生的。不過這也說不上是缺點吧，側重點不同。整體而言，大規模數據的挖掘將會是趨勢。

3、給小夥伴們的一些建議

說了這麼多，前面的那些東西可能對大夥兒的用處並非很大，固然對於開挖掘機的朋友仍是有必定幫助的。如今我想表達的東西可能跟挖掘就沒有直接的關係了，更多的給動物園動物(程序猿，攻城獅)的學習以及自我進化的建議。

(1)爲了學到東西，臉皮是毛玩意兒?

對於這點，我的但是深有體會。想當年(好吧，這個詞仍是很蛋疼的)，大學那會兒專業是信息安全，偏向於網絡多一點，所以在語言方面更多的是c和c++，對於java但是連課都沒有開的，說白了就是用java寫個HelloWorld都不會。

剛畢業那會兒，興沖沖地跑去公司寫c，結果不到一個月，新項目來了，需求變了(尼瑪，開發最怕的就是這句話)，變了就變了吧，尼瑪要研究大數據，用c能幹毛啊!一些個開源系統工具，十個卻是有九個是java寫的。當時我就哭了!

因而就糾纏着一個同組的夥伴，逮住時間就問他問題，有些問題在熟悉java的人看來，絕對是白癡又白癡的。可是對於初學者來講，絕對是金玉良言，人家一句話的事，若是本身去查找，多是幾個小時都搞不定。一個月以後，總算入門了，後面就輕鬆多了。

日後的一些日子裏，遇到了一些問題，老是會厚着臉皮纏着交流羣中的一些大拿們死問，慢慢地就進步了。近段時間，開始學習scala，幸虧旁邊有個scala小高手，哈哈，可苦了他了~~

因此，遇到本身不懂的東西，不要怕本身的問題簡單很差意思問，必定要臉皮厚!你連這麼簡單的問題都不懂，你還有資格擔憂本身的臉皮?!

(2)交流與分享

對於交流與分享這點感想，緣自於2012年底研究Storm的那段時間。Storm在2012年那會兒，並不像今天這樣火，研究的人也很少，無處交流，可用的資料就更少了，因此解決起問題來很費事。

固然其中有幾個博客給個人幫助仍是很大的，包括了「大園那些事兒」、「莊周夢蝶」等幾個博客，都是早期研究Storm而且分享經驗技術的博客。當時我就萌生了寫博客的想法。

在日後的時間裏，我花費了很大一部分精力，將我學到的Storm相關的東西整理了出來，而且因爲當時感嘆沒有一個很好的交流平臺，建立了「Storm-分佈式-IT」技術羣(羣號191321336，主要搞Storm以及大數據方面的，有興趣的能夠進來)，並把整理的資料、代碼、經驗分享到了平臺以及博客中。

因爲我一直主張「進步始於交流，收穫源於分享」這個理念，不斷有搞技術的朋友加入到這個你們庭中，而且不斷的把一些經驗技術反饋到羣貢獻中，達到了一個良性的循環。 短短不到兩年的時間，羣已經發展到了千人，而且不管是技術氛圍仍是羣員素質，在IT技術羣中絕對能夠算的上名列前茅的。

就我的從中的收穫來看，這種交流是可以學到不少的東西的，你要相信三人行必有我師，這句話是有道理的。而分享則是促進交流的基石，只有讓你們意識到本身所收穫的東西是源自於別人的分享，這樣才能讓更多的人蔘與進來。

兩年多來，我也一直堅持本身寫博客，分享一些本身的經驗技術，或者沒有這麼高大上，哪怕是對本身涉及到的一些技術作一個備份也好啊。個人我的博客站博客蟲現在也有很多文章了，其餘人能用到就最好，用不到，權當本身作的一個技術文檔的備份。

其實說了這麼多，想表達的意思就兩點：多多與他人交流，聽取他人的意見;至於分享本身的所得，這就是屬於良心發現了。

(3)多看書，隨時給本身大腦補充養分

其實這點也不止是給大夥兒的建議，也算是給本身的一個告誡吧。

我的在這方面作的也不是很好，好久以前給本身定了一個目標：一個月看完一本書。結果工做的問題，其餘雜七雜八的事情不少，這個一直沒有落實下來，至今買來的《個人互聯網方法論》纔看了前幾章。最好的案例算是上上一個月，我花費了近一個月上下班等地鐵、倒地鐵的零碎時間，終於把《構建之法：現代軟件工程》給看完了。

書中有沒有顏如玉我不知道，但書中確定有黃金屋。平時多看一些書，多學一些，跳槽時跟面試官老是能多嘮一些的，哈哈，提薪酬的時候是否是底氣就足了些?!

關於說看書的內容，工做中涉及的一些必須瞭解，必須看的我就很少說了。若是業餘時間比較多，仍是推薦多涉獵一些其餘相關領域，畢竟，人不可能一生就只窩在本身那一畝三分地上的;就算你一直堅持某個技術方向，隨着時間的推移，技術的昇華也必然會涉及到其餘不少的相關知識。

因此，多看書，多充實一下本身，這必定是對的!

(4)常常梳理一下本身，整理一下本身

常常給本身作一下梳理工做：本身目前掌握了哪些東西，目前本身缺少什麼東西，掌握的東西夠不夠，缺少的東西如何去彌補。這些都是須要咱們常常去反思的，只有整理清楚了本身，才知道本身要幹什麼，纔有目標。

固然梳理完了，你還須要去實際操做，否則的話，你會發現，每一次梳理，結果都是同樣的。咱們須要在每一次梳理事後，進行對比，瞭解本身進步了多少。固然每一次梳理，都是爲了給本身作一個計劃，計劃本身大概須要在哪些方向進行增強。

其實不少人一到了跳槽季就猶猶豫豫，其實他們對目前的工做已是有所不滿的了，可是總感受本身能力不夠，可能辭了也難找工做。這是由於他們對本身認識的不夠，連他本身都不明白本身到底有多少料，那麼，請問面試官會知道嗎?

若是，你對本身掌握了多少東西都一清二楚，核心領域已經熟悉了，相關領域也有所涉獵，那麼你還在擔憂什麼呢?若是真有面試官對你說no，你能夠說：hi，恰好我也沒什麼時間，我還回去挑選offer呢!

(5)善於在實際生活中尋找學習的動力

人是懶惰的，不少時候，有些事情可作可不作的，每每人都是不去作的，也不肯意去深根究底。

這個我很想學，那個我也很想了解，關鍵是一到大週末，我更想躺被窩!說到底，就是沒有學習的動力!

也就是說，咱們要善於在實際的生活中，尋找到推進咱們取學習的理由。

舉幾個簡單的栗子：

1)以前也說過，有段時間在研究網站。爲了讓網站推廣出去，各類去研究SEO，如今來看，本身雖然遠遠達不到一個SEO專業人員的標準，但最起碼是知道了爲毛經過搜索引擎檢索，有些網頁就排在前面有些就排在後面(PageRank算法);也知道了怎麼去編譯一篇文章，更好的方便搜索引擎收錄(等俺失業了，不搞挨踢了，去作網編估計也是行的，又多了一條活路，哈哈)等等。

2)爲了給EDM尋找目標，我本身使用業餘的時間去分析互聯網上的數據，而後寫代碼，跑數據，測試數據等。其實，在那以前，我對爬蟲的瞭解是很少的，對於網頁數據的解析也不在行，這徹底都是經過「從互聯網抓取有用數據」的我的需求上去驅動的。還不止如此，拿到郵箱以後，爲了讓EDM郵件看起來更「磚業」一點，我開始自學如何使用html來製做好看的電子營銷郵件頁面。

3)曾經有一段時間，工做非常悠閒，突發奇想的把大學時想寫小說的夢給圓了。因而就開始在縱橫小說網上寫小說。不過，這都不是重點，重點是縱橫要求每個做者給本身的小說配小說封面。我去問了一下，尼瑪一張破封面須要20多大洋。心想，一張破封面就要20大洋，本身都是搞IT的人，乾脆不本身P一個呢。因而，我開始撿起了大學時期放棄的PS學習計劃，只用了兩個星期，PS基本功能就熟練了。後來的話，本身的封面固然是搞定了，而且還服務了至少數十位做者朋友們。固然，這都是題外話了。至於小說，哈哈，不但簽約了，稿費仍是掙了上千大洋，關鍵是過了一把寫小說的癮。在PS技術方面，雖然跟專業的前端人員比不得，可是改改圖、修修照片仍是木有問題滴。

4)遠的太遠，說一個近一點的事吧。前一段時間開始學習scala，其實就我的需求來講，寫那個項目用java來寫也徹底可以搞定，但關鍵是我對我本身說，錯過了此次機會，下次說不定啥時候纔有決心去學習這個頗有前途的語言了。因而，狠下心使用這個全新的語言去開發，過程雖然磕磕絆絆，畢竟立刻使用一種陌生的語言去敲代碼是很蛋疼的事，但一個星期來，結果仍是不錯的，最起碼一些基本的用法是會了。完事開頭難，熟悉了一些基本的東西，剩下的就是累積的過程了。

其實這些歸結起來就一個觀點：咱們要適時的給本身找一些理由，逼着咱們本身去學習，去獲取新的東西，去提高本身。或許有人會說，哥我每天加班，還有毛線時間去問問題、去交流、去看書，大週末的好不容易有假期了，吃飽了我不去睡覺去給本身找動力幹不給錢的活，我腦抽啊?!好吧，若是你是這麼想的，抱歉耽誤了你這麼多睡覺的時間。

其實上面說了這麼多零碎的栗子，關鍵仍是在於態度!你有沒有想學習的慾望，有沒有提高本身、昇華本身的想法，有沒有升職、加薪、當上UFO、迎娶白富美的念頭。是的，這些東西都是本身去作的，沒人逼你。若是你有這些想法的話，那麼這些東西多多少少仍是有一些幫助的。

除了對待事情的態度，咱們的心態也很重要，看待事情要樂觀一點。前幾天，羣裏有個搞互聯網招聘的朋友問我：你是搞技術的吧?我說是。他說我認識不少搞技術的都很悶，不像你這麼開朗。我說我不想哪天死在了馬桶上~~

搞IT的給大部分人的映象確實是悶騷、不善言談、不善交際。其實也是，天天大量的工做，領導又開會訓人了、產品這邊需求又改了，確實讓人瘋狂。工做壓力大是IT人的標準屬性了。

咱們須要調整好本身的心態，就像以前所說的，學習一個東西，雖然可能會佔用原本就很少的業餘時間，可是咱們應該不是那種單純爲了解決問題而去學習，去獲取，當成一種提高本身、昇華本身的途徑，而不是逼不得已的無奈之舉。若是一份工做，你確認本身不喜歡，那就別猶豫，果斷跳吧!腦中有貨還怕找不到買家!

時刻警醒本身對待任何事情要有一個好的態度，認清本身，抓住一切機會提高本身、昇華自我，保持一個良好的心態，這就是我想說的東西。

吭吭唧唧說了一大坨，其實我也知道不少是廢話，可是我依然但願，個人這些廢話可以幫助到你，作爲同一個動物園裏的人，一塊兒努力吧!http://www.cda.cn/view/17721.html