距離上一次主動找工作，快到5年了，到現在的東家，是差不多3年前獵頭挖過來的，而當時東家剛剛被歐洲一家有百年曆史的跨國企業集團收購，所以我也就有幸成了一名“外企員工”，但是集團保留原東家人馬，一切制度照舊，因此我只能算一個“偽外企”員工了。
不過，很快就到了“雞飛狗跳”之年，公司挖來了一個世界500強公司的Java背景的高管，一切唯KPI馬首是瞻，只看結果不看過程，難怪總部的各個級別的員工都稱呼自己的直屬領導“老闆”，以前就常聽在外企的朋友說自己的領導是老闆，現在終於明白了這種稱呼的含義了。
習慣了以前還比較人性化的工作模式，一下子覺得“鴨梨山大”，難以適應，於是打算看看有沒有合適的地方，在年後加入了求職大軍，本以為憑藉10年架構經驗找個工作不是難事，沒想到慘遭滑鐵盧--大限到了！
瀏覽各大招聘網站，比如前程無憂，智聯招聘，獵聘網，普通開發工程師偶爾有寫年齡30以下，而高級開發工程師、開發經理/技術經理，有相當部分寫明35歲以下了，架構師，技術總監，也有不少寫明35歲以下，最高的就是40歲。
其它未明確註明年齡限制的，可能不是不註明，而是HR手工篩選簡歷的時候設置了，而那些註明了年齡限制的，人才網站後臺自動就給篩選了，根本進入不了HR視野。所以，各位程序猿看官，看清楚木有，看清楚木有，看清楚木有.....重要的話說三遍，程序猿的大限，就是年齡在40歲！！！
所以，這可能是我的簡歷在沒有購買人才網的簡歷置頂服務的情況下，1個月時間在3大人才網站被查看次數很低的原因，到底有多低，本猿不好意思說，因為大家可能會覺得我簡歷很渣，我也覺得我的確只是一個普通的猿，不是明星猿，不是網紅猿，只是一名在軟件行業摸爬滾打了10多年的老猿...
週末跟一個某技術群的朋友聊起這個40歲大限的話題，朋友諫言：儘早籌備自己的產品，不要到大限之日才奮發圖強。掌握其他業務知識，走專業領域路線。
這位朋友說的很對，並且也不止一位朋友對我說過要有自己的產品了，並且不少朋友真折騰出了一些自己的產品，比如啥OA，CMS等，然後用這些產品接個外包，也能賺些錢，所以才有人說，“人無外財不富，馬無夜草不肥。”
但是不是每個人都有這種機會，我深入瞭解後發現，這些有自己產品的程序猿，大都是利用工作積累出來的，最主要的，跟原來公司的客戶保持著聯繫，自己鼓搗出的產品容易有銷路。所以，與其說積累產品，不如說在積累人脈，積累資源。相信這類程序猿朋友，有人已經做了老闆，或者在未來做老闆的路上。
顯然，這條路不是每個猿猿都有，我也沒有。
作為70後老猿，我感覺吃“軟飯”，比別人要更艱辛。
求學之路
我出生在素有天府之國稱呼的的南方的一個小山村，家裡面只有一畝二分地，也許我出生的時候趕上了好時代，改革開放來了，沒有哥哥姐姐他們那麼苦，印象中打小每天吃飽了就和大院子裡面的一大群小夥伴山前山後到處玩，捉蟲打鳥，戲水抓魚，騎牛吹牛，很幸福的童年。
小時候媽媽問我長大了理想是什麼，那時候正好看到哥哥的課本上有建設四個現代，計算機是很厲害的東西，於是我就說我長大了要當“計算機科學家”！我爸爸就說這孩子將來有出息，不讓他幹農活，好好讀書吧！
那個時候，作為人口第一大省，“讀書”是一件很不容易的事情，而且那個時候正是計劃生育的前幾年，趕上人口出生的最高峰，一到了大清早，公路上上學的孩子絕對比大人多得多，但是沒有足夠的學校容納，所以有不少同學4年級就輟學了，等到了6年級，從各個村小學到了鎮的中心完小，發現一共有8個畢業班，但據說只招收2個初中班，所以那個時候考上初中，都要在村子裡面貼紅榜，就像現在考上大學一樣。
幸運的是，雖然我沒有認真複習，考試前一天都在玩，居然順利的考到了前面幾十名；而不幸的是，跟我一起玩到大最要好的幾個小夥伴，他們都沒有考上，其中有一個走關係復讀了一年還是沒有考上，所以自初中開始，我與院子裡面的其他小朋友就走向不同的命運了，現在想起來真是殘酷！
後來，我順利的考上了市裡面不錯的中學，到了這個時候，我發現家裡面為了供我讀書，加上哥哥姐姐到了成家的年紀，經濟上非常拮据，所以我只好要最少的生活費，但每次老爸都問夠不夠，我說夠了。
然而這個時候，正好趕上了“教育市場化”改革，高校“並軌”，很多大學的學費比起之前漲了不少，對於我們家的情況來說去上大學實在是很奢侈的事情。看到跟我一起長大的院子裡面的小夥伴，在東南沿海城市打工風光的樣子，我心裡面想的，只是早點畢業去打工，為家裡面減輕一點經濟負擔，但老爸堅決要求我要去上大學，說讀書才能改變命運。
由於心裡面的抗拒加上高中階段巨大的學業壓力，雖然在理科重點班讀書但成績並不那麼好，而那個時候不像現在這樣是先考試後填報志願，有2類大學學費比較低，一個是師範類院校，一個是農業類院校，當時我想如果填了這類學校就沒有理由不去上大學了，於是隨便寫了一個後來被人們認為“
很不科學”的專業的學校。考完試公佈了成績和錄取情況，班主任找到我說你怎麼寫了這樣的一個學校的專業啊？你回來跟其它沒有考上重點大學的同學一起再復讀一年，我保證你們明年都考上重點，我說不用了。
後來還是執拗不過父親，堅決讓我去上學，說沒有錢但保證能夠從親戚朋友那裡借到。為此父親拉著我去省會城市走訪一個平常都不怎麼來往的親戚，父親老早就抱怨這親戚看不起“泥腿子”，所以印象中除了很小的時候去過這個親戚家後來再沒有去過。父親怎麼跟親戚談的有沒有向親戚借到錢沒有跟我說我也不敢問，來這一趟我想父親都是拉不住臉皮的。
不過，答應父親來上學我後來還是後悔了，因為不久就聽到同學們都在談論現在並軌後也不包分配了，並且這個“很不科學”的專業出去基本上找不到工作，唯一的路徑就是繼續讀研再讀博，而這對於我來說顯然不現實。
於是來學校第二年我就開始自學計算機相關的專業，還參加了全國計算機等級考試，甚至買了本清華的人工智能教材自學，為兒時的那一點快要破碎的夢想補上一點點火光，預備將來有機會去搞計算機，雖然不能當科學家了但畢竟還是自己最感興趣的事情。
（PS：現在回想起來那麼早就瞭解人工智能AI方面的東西了，解到人工智能包括專家系統，機器學習，模式識別等，為此還學習了幾天Lisp,Prolog這種教材欽定的AI語言，並且認定將來一定是AI的時代，可惜沒有堅持下來深入研究學習，後悔啊！）
初試鋒芒:VB6
現實比較無情，不包分配了，畢業即失業，找不到工作，就在家裡面幹農活，5月的麥田，烈日、麥芒與汗水，真切的體會到了農民的艱辛(PS:現在國家成立了農業農村部，希望這是一個好的開始)，之前覺得讀書很苦，現在比起來都不算什麼了，為何父親不讓我早點體會下呢....
在家幹活雖然不完全算是“啃老”，但鄉親們議論紛紛老父親臉上也掛不住啊，無論如何得找份工作。還好這個時候已經是90年代末，小縣城也有了電腦城，於是去找了一個裝機的活，跟著師兄學了兩天，也能鼓搗著獨立裝機了。
以前學的都是軟件設計編程方面，現在能夠真切的跟計算機的實際硬件接觸，也加深了我對計算機的理解，不過我更感興趣的，還是寫程序，現在終於有機會在閒暇的時候，利用老闆的電腦，裝個VB6，寫點小程序了，比如寫個小小的電腦配件管理程序，記錄下每種配件的價格和性能參數，那是還不會用SQL數據庫，外面流行的是Foxbase這種，於是直接用隨機文件來當“數據庫”使用，也算方便。
一個偶然的機會，老闆發現了我的編程能力。小縣城有幾所中專技校，到了期末常常有人來問能不能幫忙寫個畢業設計小程序。我說可以，鼓搗個一天就寫好了，老闆很欣喜，說這不要本錢就能賺錢啊，路子不錯啊！
於是乎，後來老闆利用關係去接了另外一個小縣城工商局的系統，要求不僅僅要進行常規的信息管理，還得有電子地圖，在地圖上進行相關的信息管理。老闆屁巔屁顛的就接了，但跟我說只有3萬塊，我說這個活比較複雜，靠我一個人是不可能完成的，於是老闆讓我去找外面的人外包出去看看，結果外面開價低於30萬沒人幹。
老闆這下著急了，工商局得罪不得啊。既然整體外包公司做不行，那就找私人做吧。最後多方聯繫，從省城來了幾個朋友表示願意試試，他們說他們公司總部在北京，是專業做地圖數據的，並且還說他們4個人有2個都是研究生，技術絕對沒有問題。
老闆一看這個陣容不錯，就跟他們私下去談了，具體多少錢我不知道，但最後他們只願意做管理系統，不願意做電子地圖這部分。我自告奮勇的說，老闆，這塊功能我來做吧。老闆說，好，最近你就不用來這裡裝機了，給你一臺電腦回去加班做。就這樣，拉起一支三五個人的隊伍開幹了。
對於電子地圖，我想的比較簡單，就是加載一個地圖照片，以它為背景，在上面畫一些區域來表示每個鎮的管轄範圍，然後再標記上每個鎮的工商所和企業位置，用一個個圖片按鈕來做。這裡面最困難的是每個鎮的顏色標記填充，由於都是不規則的圖形，如何填充顏色廢了很大腦筋，最後終於鼓搗出來了。為了能夠動態的修改地圖上的信息，又搞了一個地圖編輯器。
後來，客戶要求在IE瀏覽器上也要能夠查看，於是利用VB的ActiveX控件，開發了一個電子地圖瀏覽器。除了我自己負責的電子地圖部分，我還需要經常跟遠在省城的夥伴聯繫項目工作事宜，瞭解到他們的管理系統使用的技術是ASP+SqlServer。
就這樣過了3個月，項目的雛形終於有了，客戶初步看了下，對電子地圖沒有提意見，但對於管理系統不滿意，說不好看，於是把省城的夥伴叫過來，老闆請吃了一頓飯，其中一個朋友說小夥不錯，居然把地圖搞出來了啊！
最終經過幾次改版，項目終於交付了，但老闆不高興，他說虧錢了，不僅沒有給我一分錢獎金，還埋怨我為何當初說可以接這個單（￥%#，我只是說技術上可行，項目到底多少錢我怎麼知道）。後來客戶的負責人又過來說準備做2期，但不了了之，可能老闆上次真虧錢虧大了。又過了幾年，我才知道，原來我做的這個電子地圖，跟“地理信息系統”（GIS）很相似啊！
項目做完了，也算第一次瞭解到了有ASP這種動態網頁的網站，以前自己都只會做個靜態頁面啥的，於是對ASP有了點興趣，不過我很快了解到ASP代碼是解釋性的性能沒有VB這樣編譯型的程序執行快，所以對VB6的Web工程項目很感興趣，甚至對VB6的DHTML項目也感興趣，開發客戶端動態效果的網頁很強大，代碼是編譯的，比直接寫JS即安全又高效。
可惜我當時並不熟悉Web開發的知識，甚至對於HTML都不太瞭解，而對VB又情有獨鍾，沒有深入學習ASP或者其它Web開發語言，比如Java,PHP.我當時對桌面開發更感興趣。
後來證明，我專注VB的桌面開發這個方向錯了，Web開發越來越流行，到處都在聽說建一個企業網站多少多少錢，一個域名多少錢，託管一個服務器多少錢，Web開發技術人員如何搶手。
於是被電腦城的一個老闆忽悠去幫他開公司做企業建站的生意，風風光光的大量招聘人去拉單子，結果卻很糟糕，沒有拉到像樣的單子，在我們這個小縣城大部分人對互聯網根本沒有概念，只有我們IT圈子的這很小一部分人在談論這個貌似很火的東西。
不到半年，老闆的一個親戚說現在互聯網泡沫都破裂了，你們還搞什麼，於是老闆把公司關閉了，我再次失業了。後來我才知道，這次互聯網泡沫破裂影響很大，只不過我們這裡IT比較落後，沒起什麼波瀾而已。
嶄露頭角：ASP
幸運的是，通過之前建站搞網站的過程，我知道了人才網這種網站，於是抱著試一試的想法去人才網投了一份簡歷，沒想到很快就接到了一個在線旅遊網站的電話，問1500元願意來負責網站程序維護和開發不。接到這個電話高興壞了，第二天就去省城這家公司報道。
當時這家網站公司很小，跟另外一家公司合租的辦公室，加上老闆一共才5個人，所以我是唯一的程序員，和一個Web前端同事一起工作，另外一個前臺和一個商務推廣。當時幾乎身無分文，來到公司第一次吃上免費的工作餐，老闆還安排了住宿，感覺真是運氣太好了遇到了一個好老闆，一定要努力工作。
來公司第一天的任務就是解決“共享上網”的問題，當時上網費很貴，就用163撥號上網，然後用Sygate這個軟件共享上網。由於只有這樣一個破解版的共享上網軟件，而且還是英文的，並且頭一次使用，可能是破解的原因吧，按照教程一步步配置下來就是不穩定，一會兒又斷了，又必須重新進行一次繁瑣的配置。
終於搞到凌晨2點，辦公室的幾臺電腦都能上網了。按照老闆的囑咐，這臺共享上網的電腦不能關機，一關機又得進行好多次繁瑣的配置才能上網。對於一個在線旅遊網站來說，上網是多麼重要的事情，第一次發現，網絡問題並不比寫程序簡單。
在公司第一次“出色”的完成了任務，我就有了一個監職角色：網管，以至於老闆家裡面幾臺電腦共享上網，每次出現問題都要找我去幫忙解決。不過，在老闆家我知道了老闆和老闆娘都在玩“聯眾遊戲” 這種東西。
後來公司搬遷到了一個比較大的辦公地點，從電腦採購，到網絡佈線，到弱電設計，服務器託管，十足一個網管的工作。說到遊戲，一年後大家都去玩QQ遊戲了，包括公司前臺沒事都在玩，老闆也在玩，但我對遊戲並不感興趣，只想著把工作做好。後來網絡遊戲大紅大紫，成為互聯網公司最賺錢的業務，再次錯失行業熱點！
來到省城安頓好後，我跟之前一起在老家縣城做項目的朋友打了一個電話，朋友問好啊，你也來這裡了，還是這裡空間大啊，你現在用什麼語言做Web開發呢？我說ASP。朋友說，我們都用Java了。
這不算是第一次聽說Java這種東西，之前在電腦城，就常聽一個老客戶說他家親戚在深圳用Java做很大的項目，但是，我對此並沒有概念，不曉得從這個時候，一種叫Java的語言跟大項目總是有某種聯繫，並且用的人會越來越多，而我仍然認為，ASP這麼好用，做Web開發多方便啊。
這期間，我也瞭解到了還有PHP這種開發Web網站的語言，初步瞭解後認為，這跟ASP沒有本質區別吧，只不過它常常在Linux系統上使用而已。這樣，我又錯過了使用PHP這種“最好的（Web開發）語言”。
於是，在工作閒暇之餘，經常去動網論壇逛，通過學習動網論壇的源碼，使得自己對ASP開發高性能網站有了更加深入的瞭解，跟Web前端同事配合，能夠很輕鬆的開發出網站各種功能，有了更多的時間去了解旅遊相關的業務知識，和老闆一起討論設計網站的功能。
慢慢的，網站功能越來越多，用戶量也越來越大了，網站一直平穩運行，對ASP這種Web開發技術感覺還是不錯的，比如開發效率方面，老闆讓我抄襲一個人才網出來，我差不多1個月時間從功能設計到程序開發就做完了，上線後很快就吸引了近一萬用戶。
後來，老闆找到科大的2個研究生，讓他們給重新設計下，他們對我說準備用Java來做，但是最後不知道什麼原因不了了之，可能老闆的主要注意力放到能夠快速賺大錢的“3721網絡實名”上去了。
很快2年過去了，網站壓力變得大起來，從一臺服務器增加到了2臺服務器，於是老闆請來了一個顧問幫忙看看有沒有問題，顧問說說他都在研究 .NET了。這是我第一次聽說.NET，初步瞭解了下，說.NET是微軟為未來10年的世界準備的平臺。也許，與.NET的緣分，就是從這裡開始的。
新時代的大門：.NET 1.x
不久，一個朋友說他們北京的公司要招人，並且說北京是全國IT最好的地方。以前在老家電腦城裝機的時候，就常常談論北京的中關村，現在有機會了，自然想去看看，於是就被朋友忽悠到了北京。
到了才知道，公司要做一個互聯網信息監控產品，簡單說就是做一個爬蟲去互聯網搜索包含指定關鍵詞的網頁然後提純入庫，聚類分析，用來走輿情監控，商業競爭情報分析等。這中間比較關鍵的技術是URL和內容排重，中文分詞和聚類分析。我對這個項目很感興趣，可是負責項目的老大不久就離職了，介紹我來的那個朋友也離職了，所以產品要怎麼做沒人知道，老闆也不怎麼過問，只有我來接這個坑了，所以中文分詞和聚類分析沒法真正去做。
開發一共就2個人，還有一個監職的測試，另外一個開發其實是沒有太多經驗的妹子，只會寫點ASP，所以主要的工作都是我在做，那麼在技術選擇上，決定嘗試一下.NET開發，那個時候還是 .NET 1.1剛出來，用的VS2003，不過比起我之前用的VS6.0已經好了很多；開發語言上我選擇了VB.NET，不用說VB是我的看家本領，並且寫了幾年ASP，對VBScript也相當熟悉，自然選它了，所以產品的最終架構是B/S端使用ASP,C/S端使用VB.NET。
大概過了3個月，產品雛形就出來了，老總看了比較滿意，然後慢慢優化改進，半年後老總帶著我去看了客戶負責人，某市公安局負責網絡信息監察的主任，聽到對方談論最多的是如何監控QQ視頻聊天和其它視頻聊天裡面的不法行為。當時候視頻應用還是相當少見，這些視頻聊天軟件我從來都沒有用過，我們的互聯網信息監控完全就不對路子，現在想起來在10多年前就有網警了，而且還是超前的視頻監控，對我們警察蜀黍的業務能力還是相當敬佩的。
回到項目的話題上來，自然是後來合同一直沒有簽下來，然後工資開始發不出來了，我看情況不對趕緊辭職找新工作，在我辭職半年後，這家公司果然倒閉了。當然這個項目我最大的收穫就是通過VB.NET進入了.NET的世界，與後來的C#比起來，VB公整的語法和規範的格式，智能的編輯器，至今都是我業餘寫程序的首選。
辭職後到了一家互聯網社交網站，算是山寨的美國臉書網站吧，創始人就是從美國硅谷回來的，我用ASP做些模塊。按道理來說開發ASP這是輕車熟路了，但是每天早九點晚九點，甚至10點，每週6天的工作模式讓人高度緊張，效率不升反降，多年後大家都在談論互聯網公司的996工作制，才知道當年我在這裡也是這種模式。
我喜歡寬鬆一些的工作環境，所以還沒有過試用期，跳槽到了一家做GIS應用的公司。不知道這樣辭職離開互聯網，離開後來大紅大紫的互聯網社交應用圈子值不值，但那種工作節奏，實在是受不了。
企業應用開發：Web Forms
到了這家做GIS應用的公司，是我在北京印象比較深刻的公司，不僅工作時間比較長，最重要的是跟同事們相處的關係算是有史以來最好的，可能因為這是一家純技術公司吧，同事之間沒有什麼利益爭鬥，跟我在後面那些呆過的公司完全不同。
面試的時候，老總說喜歡我的拼搏精神，能夠從小縣城一路來到北京，老總河南人，性格比較耿直，也許他說這句話是真的。公司老闆是南方某註明大學GIS專業出身，卻是公司主要的業務員，GIS技術上是北京某大學的一個博導負責，他給公司拉了不少政府項目，當然，也經常會拉幾個他的學生--博士研究生來公司工作，而我們就跟這幾個博士一起做項目和產品，有時候博導也來指導我們的技術。
在公司3年，沒有覺得博士跟我們有不同的地方，他們都很謙虛，還常常向我們請教一些程序開發方面的問題；但是他們研究的東西，我一點也不懂，不過我也知道他們使用的GIS技術，比我幾年前搞得那個電子地圖，是一個在天上一個在地上。公司產品主要的業務在房產，公路和礦山方面，當時用的是ArcGis和AutoCAD等。
博士們用C++做這些產品的應用開發，而我們用.NET做這些客戶的外圍管理系統開發，C#語言，ASP.NET WebForms，我第一次正式項目使用C#語言，也是第一次正式使用ASP.NET,感覺WebForms除了它的那些服務器控件的使用和自定義服務器控件的設計開發之外，開發模式跟WinForms特別相似，所以沒有遇到特別大的障礙。
後來給東北一個客戶做房產產權產籍管理系統，來了一個老大，在這個項目上我學到了很多東西，包括服務器控件的使用，自定義服務器控件開發，ORM，SQL配置文件，IOC，工作流，報表中間件等。老大經常說做完這個項目就要去美國斯坦福大學讀書，但項目還沒有做完他就辭職了，所以這許多東西，都只有我自己來研究。
項目中的ORM並沒有使用知名的ORM組件，也不知道是誰寫的，那個時候知名的ORM組件還沒有大量面世，所以也比較原始粗糙，依賴於反射來處理實體類生成查詢的，並且每次只能查詢出實體類的全部屬性，不能指定查詢某些屬性字段，這對於有很多字段的大表查詢效率不高，所以大部分時候，還是以寫SQL查詢到DataSet中使用為主。
這裡就遇到一個亮點，它的SQL並不是寫在程序中，而是寫到一個XML配置文件中，以一定的規則解析使用。不過，這些XML格式的SQL配置文件寫起來還是很費事，好處就是SQL都在一個地方集中編寫使用，維護比較方便。後來才知道，iBatis框架（MyBatis的前身）使用的就是這種思想。
後來，這種ORM和SQL配置文件的開發方式，又在其它幾個項目中使用，ORM查詢的不靈活，效率不夠高，和SQL配置文件的繁瑣，成為我一直思考的問題，將我的一些思考和設計在CSDN上與同行進行交流，逐步有了成熟的方案，比如ORM部分設計了ORM查詢語言--OQL，能夠指定查詢的字段和更新的字段，SQL配置文件部分改進了解析功能，並且設計了一個代碼生成器自動根據SQL的XML配置文件生產DAL層代碼，這就是PDF.NET開發框架的誕生背景。
2006年10月發佈了1.0版本，並且之後將公司項目裡面使用的智能數據控件也包括了進去，可以實現數據收集，呈現，驗證的功能，大大簡化頁面CRUD的開發過程。
然而，我總結的這個框架還沒有來得及在公司推廣使用，2007年上半年微軟就放出來了Linq2SQL這種技術，我們有同事就嚐鮮在項目裡面開始試用了，到了2007年年底C# 3.0正式發佈，.NET 3.0框架正式支持Linq技術，Linq2SQL獲得社區廣泛支持。
Linq以其強大的表達能力和廣受歡迎的程度讓我覺得我的PDF.NET框架的OQL技術實在是不值得一提，一個是大學級別的東西，一個是小學級別的東西，一度想放棄PDF.NET框架的繼續開發。
當時在公司，我們主要的客戶使用的數據庫是Oracle，Linq2SQL不能支持，所以這個項目引入了iBatis.Net。因為那個時候並沒有找到iBatis的C#代碼生成器，SQL語句和配置文件全部要手寫，然後再手工寫相關代碼去訪問SQL配置文件，由於項目比較著急，查詢量比較大，寫這種配置文件和相關代碼簡直累的吐血，發誓以後再也不用這種東西。
當然，做這個項目也有收穫，就是我基本上閱讀了當時iBatis.Net的全部源碼，發現這貨底層使用了Hibernate的一些東西，所以將iBatis和Hibernate 的一些優點和設計思想借鑑到了PDF.NET框架，逐漸PDF.NET的SQL-MAP功能和ORM功能自己覺得用的比較順手了，正準備在公司推廣使用的時候，微軟又放出了 Entity Framework，官方說明它正式支持Oracle數據庫了，我們同事決定在下一個項目中使用它，時間正好在2008年奧運會前後
Web 2.0時代的開啟：Ajax
我在這家公司這個時候已經滿3年了，除了上面數據框架的故事，還得說說我與JavaScript的一些小插曲。公司裡面有很多項目的JS代碼都是我在寫，當時沒有很成熟的前端JS框架，jQuery也沒有大量流行，好多功能都是自己手寫的，當然現在看來這些功能都不值得一提，比如一個可以在頁面新增行刪除行修改數據的表格控件啥的，當時我有一次請年假了，回來後聽同事悄悄對我說，老總前幾天發火了，說這些JS功能除了XX（“我”）就沒有人會了嗎？
當時流行的是ASP.NET WebForms，大部分同事都是用服務器控件的，JS寫的好的同事的確不多。但是到了2008年，社區開始流行ASP.NET MVC框架了，它跟WebService和如日中天的Ajax技術結合的更好，大量的社區文章都在討論Ajax，一些互聯網社區網站開始火起來，Ajax的局部更新技術使得網頁呈現動態功能更加容易，所以當時主流技術媒體大肆宣揚Web2.0時代來了。
假如我這個時候迴歸互聯網，也許能夠趕上這班車。當時公司老總找了幾個國外的ASP.NET WebForm與Ajax相結合的一些資料讓我研究，然而我認為未來是MVC的時代，而且Ajax技術我在來北京第一個公司就曾經山寨了一版了，沒什麼新意，所以對老總的安排不是很重視，我說我更喜歡後端開發，這在老總看來頗為不解，但他不知道我糾結的是PDF.NET框架如何發展的問題。
說到這裡，我不得不跟這家GIS技術公司道別了，原因有2個，一方面是當時很要好的同事要麼跳槽了，要麼轉行了，比如一個很牛的同事轉去做售前了；另一方面在公司三年薪資上沒有明顯提升，公司比較小不怎麼賺錢，不太可能花更多薪水挽留我，並且這個時候我已經結婚老婆剛生了小孩，以後家庭需要更多的資金支出，不得不考慮去薪水更高的地方。
離職後的幾年，我們原來公司的這幫同事還聚會了幾次，大家都說像我們這麼好的同事關係在別的公司不多見的。也許是公司氛圍真的很好吧，一個公司的氛圍可能取決於老闆的風格，有幾個公司的老技術人員在公司工作了很長時間，其中有一個因為家庭原因回東北後還一直兼職做公司的技術顧問。
不知道是不是技術出身的老闆的固有問題，這家公司直到現在仍然是一家小公司，還在原來的地方辦公，祝願它能夠繼續發展下去。
.NET 3.x時代：WPF，WCF，Linq
08年奧運會後，我來到一家做銀行業務的公司，其實這家公司是2008年金融危機後差點倒下的一個股票證券類諮詢公司，現在被它的東家，一家在中國香港上市的專門做銀行系統的公司接管了，所以我也就這樣第一次進入了一家“上市公司”。
集團公司旗下的我們這家公司主要做銀行核心交易系統，用C++和Java做大型機的軟件，而我們是整個集團唯一用.NET的開發部門，自然只能做銀行邊緣的增值業務系統。
公司雖然名頭大，但對我們，仍然像是一個小作坊，期間正好有一本書《走出軟件作坊》，來描述我們當時的情況很像--大公司小作坊，軟件研發一點不正規，而公司也派出了專業的項目管理團隊來管理我們的軟件研發項目，整了一個很高大上的名詞：PMO。
所以，我跟他們學到了一些項目管理方面的東西，終於有機會擔任一個產品的項目經理。這個項目很特別，部門經理是項目裡面的開發人員，老總新招聘了一個架構師，所以團隊成員有4個是部門經理的老人，另外是隨著架構師一起招聘的4個新人。
產品是一個C/S軟件，在客戶端使用SQLite這種嵌入式數據庫，架構師費盡口舌在項目裡面推廣WPF和Entity Framework，說這兩個東西是微軟平臺的未來， 部門經理拉著一幫老人抵制架構師的方案，要用WinForm和手寫SQL，吵架吵到老總那裡，老總說你們分成2個組，做同樣的功能來比比開發效率和程序運行速度。
在2010年之前那個時候很多客戶端裝的還是XP系統，機器配置低，加上架構師一派都是新人，這幾個新人水平比較差，這樣的比賽結果自然是架構師完敗。但架構師是老總招聘的架構師的意見還是有分量的，所以最後項目的技術方案就是一個混合妥協的方案：在產品啟動頁和首頁，因為要用比較絢麗效果，用WPF開發，其它地方用WinForm開發；在產品需要大量查詢可能有性能問題的地方，使用手寫SQL查詢，其它地方使用Entity Framework。
這個項目產品前期需求分析討論和產品設計大概花了6個月時間，但是給的開發時間只有3個月，從組建開發團隊到部門經理與架構師的技術框架之爭，又花費了1個月，另外計劃的是這3個月還包括1個月的測試時間，所以真正留給開發的時間差不多隻有1個月。
熬過這1個月緊張的開發，時間本來不夠外加團隊裡面兩個技術派的懟怒，磨合不好，進度嚴重滯後，外加上層領導的催促，重壓之下我只好辭去了這個項目的項目經理，我說現在開發人員嚴重緊缺，我最合適的崗位還是去做開發比較合適。
於是，公司從總部派了一個專職做項目管理的高級項目經理來接替我之前項目方面的工作。新項目經理來了後，做的第一件事情就是強令大家週末加班，並停止每天早上的“敏捷站立會”，嚴格按照項目開發計劃趕進度。
每做完一個功能，就讓測試人員開始測試，讓測試人員催著開發人員走進度。在項目重壓之下，有兩個新同事辭職了，在上線日期之前，還有好幾個不怎麼重要的模塊都還沒有開發。
但是，到了項目上線日，公司相關的大小領導都來了，項目經理在會上宣佈產品圓滿開發完成，各個領導也點頭同意。這讓我非常震驚，一個在我看來根本沒有做完的項目居然被領導驗收通過完成了，我不得不佩服這個項目經理的公關能力！
項目做完了，產品買的不怎麼理想，當然反饋回來都是技術的問題，比如性能慢之類，無法安裝.NET框架之類。這個時候部門經理說，大家看看我們用WinForm和手寫SQL開發的模塊，性能是不是要快些？如果產品不用WPF，不用Entity Framework，就不會有性能慢的問題，並且也不用安裝.NET Framework 3.5 框架，而 .NET Framework 2.0是很容易安裝的。
部門經理說的情況是對的，的確他們小組開發的模塊性能明顯比架構師小組開發的模塊要高。架構師選擇WPF和Entity Framework 作為我們公司第一個吃螃蟹的人，遭遇失敗，黯然辭職，令人噓唏不已。
此後，部門經理說話在老總那裡有了相當分量，於至於在後來的項目裡面，部門經理做項目經理的時候，強令開發人員不允許使用ORM，說ORM效率低。我與部門經理之前的關係還算可以，在部門經理與架構師的技術派系鬥爭中，我表現的比較曖昧，沒有明顯的表示支持哪一方。
這個項目做完後，公司派我去某知名培訓機構去學習架構，價值8000塊的培訓費在那個時候還是很奢侈的，當然也簽訂了協議培訓後必須在公司工作滿至少3年。經過一個月的培訓後，我就名正言順的當期了公司的.NET架構師。既然是架構師了，自然得在公司裡面搞點什麼架構才行。
於是在後來某個項目裡面，我決定推廣我的PDF.NET框架，但是，這卻引發了我跟部門經理的矛盾，部門經理說他嚴禁項目使用ORM，我說之前使用Entity Framework這種ORM是因為這個框架出來不久，它在性能方面的確有問題，但是我的ORM比較輕量級，不會有性能問題。
我拿出了測試數據給他看，但還是不行，於是爭執到了老總那裡。老總說，我看了你的測試數據，但我不懂技術，這樣吧我打個電話問問項目組裡面的同事怎麼看，ORM是不是會影響性能。電話通了，電話另一邊的同事說的確會影響性能。我說這一點點性能損失怎麼叫做影響性能呢？
老總說，公司實行項目經理負責制，他是項目經理他負責，你作為架構師，一定要明確自己的參謀角色。就這樣，這個項目沒能使用ORM，不過作為妥協，使用了PDF.NET框架的SQL-MAP技術，將SQL語句都寫在配置文件裡面，然後利用代碼工具自動生成DAL代碼。
項目裡面負責數據庫開發的同事，算是兼職的DBA，他對這個功能很喜歡，所以他寫了很多複雜的SQL語句和存儲過程，而其他開發人員寫的業務層幾乎沒有業務代碼了。項目交付後，性能不錯，部門經理和監職DBA同事都得到了公司的獎勵。
後來另一個客戶需要這個項目的產品，但數據庫不是SqlServer，而是PostgreSQL，由於上個項目採用了PDF.NET的SQL-MAP技術，所以基本上這個DBA同事一個人就把SQL Server的存儲過程移植到了PostgreSQL的用戶函數中，修改了SQL-MAP配置文件，基本上沒有修改代碼。
這個客戶的項目做好後，領導對這位同事大家讚揚，並且這年他被評為公司優秀員工。但是，如果之前的那個項目使用的是ORM技術開發，避免寫存儲過程，那麼後來這個客戶的項目，根本不需要進行這個移植過程，直接就可以使用。
不過，這個項目的移植讓我有機會學習瞭解PostgreSQL這種免費開源數據庫，還是很不錯的，順便的PDF.NET的數據庫支持清單上，除了SqlServer,Access,Oracle,有了PostgreSQL的PDF.NET驅動程序。
面向開源：PDF.NET
後來終於有機會獨自負責項目，那種只有2-3個人的小項目，我在項目中使用了SOD框架的ORM部分，同事們使用後都說，原來ORM這麼好用啊，的確比寫SQL方便多了。我說ORM也要有適應場景的，太複雜的查詢很難用ORM解決，如果非要解決，那就是另一種複雜的SQL寫法。
所以我對PDF.NET的ORM的看法是它只解決80%的查詢工作量，剩下的20%的複雜查詢，要麼交給SQL語句直接執行，要麼修改設計方案將複雜問題簡化為一個個簡單的問題，複雜的問題難以直接解決我們就繞開它。
在這個想法下，接觸到了領取驅動設計--DDD這種技術，曾經一度認為只有它才是解決複雜問題的應對之道，也曾經在公司宣傳了一下，給同事們講解建模過程，潛在的來講DDD的好處。當然，對於當時公司的同事來說，剛用上ORM就算鳥槍換大炮了，DDD這麼高深的東西是接受不了的。
看到PDF.NET框架已經在公司成功推廣應用，我產生了將它正式開源的想法，之前都是僅限於會員用戶才能獲得源碼。在2011年9月，寫了一篇博客，《節前送禮：PDF.NET（PWMIS數據開發框架）V3.0版開源》，正式推廣使用，後來陸續收到會員用戶朋友的捐助，其中實名統計的前後共有108位朋友，CSDN，Codeplex上各個版本各種驅動下載的總人數超過了1萬人次。
2015年初完全開源，寫了一篇博客：《一年之計在於春，2015開篇：PDF.NET SOD Ver 5.1完全開源》。開源之後，得到很多朋友的使用反饋，修正了不少Bug，框架不斷完善發展起來，框架也被我之前的同事帶到了其它公司推廣使用，有了一丁點知名度。不過，作為框架的作者，我在之後的推廣使用中，並不是那麼順利。
預見未來：P2P
我在這家公司除了最後成功推廣了PDF.NET框架，還有2件事情值得提下，一件事是把之前做的項目中利用郵件系統完成銀行內外網通信的方案發表到了集團公司的科技內刊上，得到公司CTO的表揚；另外一件事情就令人深感遺憾了。2011年初，我們分部的業務發展遇到了瓶頸，整個公司的業務發展也出現了飽和，公司的大型主機維護業務和核心銀行系統業務增長乏力，急需尋找新的業務突破口。
老總拉著大家一起頭腦風暴搞了一個晚上，各種總結思考，要求大家在一個月內拿出自己的建設性方案出來。我的課題就是依託公司所在的金融行業，提出了三個方案，一個是發展村鎮銀行系統，在傳統銀行業務線上提供小微銀行模式；一個是發展小額貸款業務，就是後來大火的P2P模式；一個是民間徵信業務，這個是前兩個方案要做好的一個配套方案。
老總看到我厚厚的幾十頁方案，問我怎麼了解這麼多啊，我說這是我花了很長時間思考和收集公開的資料，分析政策和經濟走勢，綜合分析得出的結果。老總說，希望你的方案能夠在公司得個大獎。
可惜，老總在年後升職成了公司副總裁，原來的副總當了老總，這件事情不了了之。等我這年底辭職離開公司後，集團的兄弟公司開始做小貸業務（P2P），結合它們之前正在做的銀行理財業務，這樣左手理財收錢，右手P2P放錢，這家公司一下子趕上了後來互聯網金融的快車，業務飛速發展起來，到現在已經成為一家互聯網金融集團公司。
據說徵信業務，也被它們集團內的一個公司拿去做了。後來每每說起這件事情，我都在想這家公司有沒有看過我的方案呢？如果我當初不離開原來的公司，轉了Java去了這家公司，我是不是能夠發達呢？實在令人懊惱不已。（PS：當時之所以要辭職，就是因為看到公司讓我們轉Java，我覺得.NET已經被邊緣化在這裡沒有前途。）
踏足電商：一波三折
下面說的這家公司是一個創業公司，但實力比較強，老闆從原來公司帶過來一班人馬，做電商拍賣業務。HR招聘的時候說他們招一個架構開發工程師，我以為就是架構師吧，結果發現就是做開發的，想想看一直都在做開發也沒什麼。
來公司後就開始做一個拍賣客戶端，我擔任項目經理和架構師，團隊都是新人，3個同事用WinForm做UI，我和一個同事做後端服務，客戶端使用SQLite緩存數據，後端沒有直接使用數據庫，通過接口調用別的系統，所以這個產品本質上就是一個消息推送客戶端，將拍品信息實時推送到客戶端，客戶端可以進行簡單的信息查看然後選擇拍品出價。
老闆對客戶端UI比較重視，所以產品經理對客戶端UI有近乎變態的渴求，界面要求跟美工設計完全一致，精確了一個像素。按理說這樣高的UI要求用WPF比較合適，但考慮到客戶的電腦普遍比較陳舊，擔心在上家公司做的那個項目那樣的性能問題，所以最終選擇了WinForm開發。
消息推送方面，我選擇了使用WCF的雙工長連接，封裝了一個消息推送框架，當然不是從頭開始搞的，使用了一點上家公司做郵件通信系統的時候有關WCF的部分功能，否則在短短1個月時間不可能做出一個原型出來。這個消息推送框架便是後來的消息服務框架。
大概又進行了3個月的功能開發，客戶端的後端服務可以支持集群服務，經過了大併發測試，這個拍賣客戶端終於面向客戶正式發佈了。由於這個時候在BS端的拍賣成交率嚴重下滑，所以拍賣客戶端被老闆給予了厚望，希望能夠大量推廣安裝，增長成交率。
可是令人擔心的問題還是出現了，好多客戶機都是深度克隆版的XP系統，死活安裝不上.NET 3.0框架，就沒法安裝我們的客戶端，唯一的解決辦法就是給客戶機重裝系統。
這個問題比較明顯的影響了產品的推廣力度，老闆就不再把它作為重點產品支持了。就這樣差不多過了半年，老闆將方向轉移到了移動端，開發APP產品，一年後，我們這個拍賣客戶端下線了，而消息服務框架也沒有了用武之地。
客戶端產品做完後，公司準備重新設計電商網站，總監進行技術選型，徵求我的意見。我說目前我們使用的是NetTiers 代碼模板生成的數據訪問層，它有一個最大的問題就是每個CRUD方法都生成了一個帶事務對象參數的重載，用於有事務的查詢，如果A，B方法都對同一個表查詢的時候，A方法使用了事務重載，B方法沒有，那麼有很大概率會出現死鎖，所以團隊開發的時候必須很小心，避免別人調用錯誤，而忙中出錯又是難免的，另外一個問題就是大家查詢的時候都用模板自動生成的查詢方法，這些方法默認都是查詢出表的全部字段數據的，當遇到大表的時候有性能浪費。
總監同意我的看法，說現在Entity Framework比較流行，用它怎麼樣？我說用它的確在比較簡單的查詢的時候很方便，但是複雜的查詢不好控制，生成的SQL不好優化和調試，另外就是效率不太高（基於當時EF4.X以前的版本而言，EF有比較大的性能我呢提）。
於是我拿出了PDF.NET框架跟Entity Framework的對比測試程序，前者在速度，內存方面都有明顯優勢，總監說行就用你的方案吧。於是我開始在公司推廣培訓PDF.NET框架，有一個小項目，同事先拿去試用了。正當我準備在新項目中使用PDF.NET框架的時候，原總監辭職了，來了一個新總監，某著名外包公司出身，2年.NET開發，3年Java開發，N年管理經驗，來的第一件事情就是否定拍賣客戶端的消息推送機制，並試圖從理論上證明這種設計就是錯誤的。
我覺得他的這些理論批判是沒有根據的，就據理力爭。當然結果就是我不再參與新電商網站這個重點項目的研發，打發去維護那個已經沒什麼人用的拍賣客戶端。
新網站項目規格很高，各方面都很重視，招聘了一個新架構師來搭架構，但是能夠使用技術是新總監已經欽定的一份“研發技術使用清單”，ASP.NET MVC+Castle IOC+MyBatis.Net。
由於舊網站使用的是ASP.NE WebForms，這個組合對於開發團隊來說都是新技術，總監分配團隊裡面不同的人分別去研究這幾個技術，然後給大家培訓，這個時間大概花了1個月。
MyBatis.Net 就是之前的iBatis的.Net版本，開發團第被谷歌收購後改了名字。總監推薦了一個代碼生成器來生成MyBatis的使用代碼，不用說，效率槓槓的，但實際上，這種自動生成的代碼都是針對全表CRUD的，程序運行效率跟之前那些古老的ORM沒有什麼區別；另外一個問題就是條件查詢，MyBatis可以動態拼接條件，大家為了方便都是程序裡面直接拼好一個Where條件字符串拿去替換，很少有人真按照MyBatis的規範去使用。
Castle的IOC框架在當時還是很有名的，它有對象生命週期管理，用過IOC的人可能知道生命週期管理不好會有坑，出現大對象內存洩漏的問題，這個問題對於團隊成員技術水平比較一般的情況來說就比較麻煩了。
項目開發過程中的其它問題比如加班加到失控，比如管理啥的不做評論，最後結果就是項目上線失敗了，服務器一直宕機，產品經理在上線前一週離職，新總監在上線前一天離職，測試經理一個月後被勸退，甚至新總監的直接上司，研發中心老總也被調離崗位。
老闆開了一個項目上線事故調查會，追查還有誰應該對此負責，架構師很委屈的說：我只是一個上線（操作）的。後來查明服務器宕機的原因是在高併發的時候，網站程序出現內存洩漏，而洩漏的原因就是IOC的對象生命週期管理失控，但是要修改已經來不及了，IOC的使用在程序各個地方都是，要改等於是很大一部分代碼都要重構。最後的結果就是，放棄花了一年時間研發的這個新網站，恢復原來的舊網站運行，將新網站的一些新功能加到舊網站上去。
（ PS：新網站上線失敗的事情還沒有完，這件事情對於公司業務打擊很大，.NET研發團隊在老闆那裡已經失去信任，而我也被無辜殃及。老闆從國內三大門戶網站挖來一個PHP研發總監，組建了一個PHP研發團隊，他們在平常工作之餘加班秘密複製了一個電商網站，但是直到我從這裡離職，這個複製的網站都沒有上線，可能老闆對於網站的複雜性，重要性深有顧慮，不敢輕易替換的原因吧。因此這裡就出現了一個很有意思的情景：.NET團隊失去了信任，但它的重要性又不敢輕易否定。所以，一切看當時負責研發新網站的.NET團隊成員的表現了，而他們也是拼了命的去加班補償，最後終於贏得了老闆的信任，這都是我離職後的後話了。）
網站上線失敗，PHP團隊接管了除網站之外的其它BS項目。後來，一個產品經理提出重做公司後臺ERP的方案，PHP團隊認為全部使用BS開發即可，產品經理過來找到我，對我說你要多多支持我的方案，.NET做客戶端是其它語言難以替代的，你們現在.NET不受公司重視了，這是你們的一個機會啊！
這話說的不錯，但似乎有醉翁之意不在酒的味道。就這樣，這個新的ERP系統BS端採用PHP開發，CS端採用WinForm開發，兩端因為如何通信問題嘗試了好久，PHP因為無法很方便的支持WebService 而採用了JSON序列化的方式發送和處理請求結果，那個時候還沒有流行Restfull API這個概念，我們就這樣先試行了。
就這樣，兩個團隊專注做自己的東西，我負責的WinForms端開發，採用了PDF.NET的智能數據控件技術，實現了界面數據的收集，綁定，好多界面所需要的代碼都沒有幾行，僅僅需要設置控件的數據屬性綁定而已，從而提高了開發效率。
參考後來總結的這篇文章：《不使用反射，“一行代碼”實現Web、WinForm窗體表單數據的填充、收集、清除，和到數據庫的CRUD》。產品做好後，我們的業務人員反映很好用，再也沒有之前BS版本那種速度慢，頁面卡頓的問題了，並且窗體方式的數據展示效果，內容輸入的便捷程度，都比BS方式的頁面要好得多，大大提高了現場業務人員的工作效率。為此老闆也很滿意，獎勵我們這個產品的全體研發團隊（產品，技術，測試）去國外4日遊，而且之後不久，負責這個產品的產品經理晉升為產品總監。
後來，公司改變了拍賣模式，由之前的“秒殺”式拍賣改變成實際現場拍賣會那種分不同拍賣場次的順序拍賣方式。這種業務模式的改變，極大的降低了網站的併發壓力，網站開發團隊由於之前嘗試新技術的失敗，技術趨於保守，仍然用之前的NetTiers 代碼生成的模式，只需要最快的速度開發新功能即可。
而在其它項目上，都是PHP團隊的事情，他們掌握了公司後臺的關鍵業務。但是對我而言，沒有進一步發展客戶端軟件的機會，也沒有大型互聯網那種大併發，大數據的挑戰了，架構的重要性已經不再，到了我跟這家公司說再見的時候。不過，在這家公司，我也有一個意外的收穫，公司業務飛速發展，我從業務部門也學到了一些有關業務分析的方法，進行系統總結後，寫了一些博客文章，並且參加朋友組織的線下技術思想分享。
從上家電商公司辭職後，我到了另一家做電商的公司，老闆試圖打造一個B2B2C的全平臺，利用自己集團主營業務是傳統支付業務的基礎，試圖進入電商支付領域，並且打通線上與線下的交易渠道。
老闆從某東挖來一個人做電商事業部的副總，基本上電商平臺不論從產品還是技術架構都是這個副總定的，而我協助副總實現他的想法，主要是負責Entity Framework在項目中的落地應用，另外負責電商支付模塊的設計實現，與集團的支付系統打通，所以我認為我們這個產品更大的意義在於公司從線下支付轉向電商支付的一次實驗性項目。
雖然我早在2008年就接觸到了Entity Framework，並且在2009年的那個項目對它嚐鮮式應用過了，期間也一直保持關注和研究，7年後這才算第二次正式使用Entity Framework。
副總的意思是所有查詢都要使用Entity Framework，但是架構設計之處就分庫了，所以需要使用Entity Framework做分庫查詢，並且Entity Framework對MySQL當時的支持並不太完美，有時會有些小Bug，比如某個字段跟數據庫的結果不一致，但是其它字段又是對的，經查明是字段類型問題。
另外項目開發的比較緊急，開發團隊成員大部分都是外包的，之前都沒有人用過Entity Framework，他們對SVN源碼管理也經常不按規則使用，再加上Entity Framework的數據庫升級，問題很多，預計半年的開發時間，差不多有3個月都在折騰Entity Framework的問題，半年時間到了果然沒有預期完成開發，而這個時候由於加班多開發壓力大，連項目的開發經理都辭職了。
這樣工期不得不又延續了3個月，所以前後差不多花了10個月才開發完成。項目上線之後就是跟支付那邊不斷的聯調測試，以及接入一些小商家來入駐試用，這塊商務方面進展的不是很順利，所以結果就是前面拼了老命開發，後面又比較清閒沒有方向，這樣下去不是我廢了就是部門要黃，我不得不思考新的出路，恰巧碰到一個獵頭把我挖到了現在的公司，而之前公司的那個部門，半年後因為別的公司意圖收購他們，部門裁撤了。
這裡需要說下離職期間的一些小插曲。老闆聽說我要離職，派了他的親信，公司的老員工來做了我三次工作，說如果留下來，承諾未來3年我的總收入不低於120W，平均每年40W，但是第一年只給30W。
我聽了很詫異，在我離職之前不久公司才給我加薪了，加了多少呢？500塊。既然認為我是人才為何才加這麼點呢？我將這個情況也給獵頭說了下，獵頭說你老闆這樣是沒有誠意的，獵頭的花言巧語讓我相信了他們的看法，留在這裡的發展前途沒有他們介紹的新地方大。
可能最後老闆知道了用錢也留不住我，就派了另外一個部門經理來找我，對我說，原來你就是PDF.NET框架的作者啊，我們都看過，很不錯的（#$#$一堆讚美的話就不多說了），你來我們部門吧。我苦笑了下，說感謝支持，但我去意已決：-《 。
後來到了新東家，才發現遠遠不是獵頭描述的那番美好景象，心想這些獵頭真是以賣人為第一原則別的什麼都不管的。到現在，居然有很多獵頭連Java與.NET都搞不清楚就到處挖人的。
結尾：.NET青春不再，尚能飯否
故事說到這裡，終於可以收尾了，文章的開頭我已經簡單說了下現東家的情況，出於隱私考慮，我現在不方便說太多現在公司的事情，雖然也有很多故事，有很多問題，有不少坑，其實套路都差不多，暫且不表。
就簡單說說我在公司的工作吧：推動變革，當然我作為系統架構師這個頭銜，說“推動變革”沒人信，一個公司的變革一定是由很多人一起推動的，起重要作用的可能是公司領導層的領導，也可能是普通員工的一些工作建議。
來公司近3年，公司慢慢的由一個傳統軟件公司向互聯網軟件公司逐步轉型，公司賣了10年的單機版軟件，正在重新研發設計為一個具有云-端計算的，複雜的成套解決方案，整個軟件不管從開發語言，系統架構，軟件功能還是銷售模式，都有了巨大改變，用老闆的話說，這是我們立足於未來10年的軟件。下面大概說說這個軟件的情況。
最後想學習編程又沒有學習資料的話，可以關注我的頭條號並在後臺私信我:前端，即可免費獲取。
閱讀更多 web小學員 的文章
