有哪些技術是脫離業務的？

今天在Q羣裏嘮一個新技術（關於phper如何學習swoole）的時候，忽然一羣友發一句「脫離業務的技術都是耍流氓」，頓時讓我等老鳥無言以對。而後，就是一堆的不明羣衆複製、刷屏。。。php

幸虧本人反應夠快，快速輸入下面這段話：html

分享一些工做的經驗：不存在脫離業務的技術。全部新技術都是爲了解決一些業務痛點，讓特定業務更爽。前端

當咱們掌握足夠多的技術，在遇到問題時就能夠選擇適合的技術進行解決。反之，若是沒有技術儲備，就會手足無措，又或者說選擇一些不太恰當的技術進行解決，最終都會走一些彎路、踩一些坑。走彎路、踩坑當然是全部項目都會遇到的一個問題，一我的走彎路、踩坑也許不是什麼大問題，但整個項目走彎路，這個最終苦的仍是咱們這些技術人員。java

技術儲備相當重要，不管是團隊仍是我的。有了足夠的技術儲備，才能夠遊刃有餘，作到成竹在胸，遇到問題能夠快速找到N種解決辦法，並評估各個方案的優缺點進行合理選擇。
總之一句話：根據業務場景選技術，但前提是對各類技術都有深刻的理解，能熟知其利弊。nginx

下面會圍繞這個觀點，作一些延伸思考：web

1：技術由何而來？

關於這個問題，個人同事 "江邊望海" 曾經提到一種關於"技術人員的成長之路"的思路能夠拿來借鑑：redis

第一個階段： 作技術人員的前3年，不斷的作業務，作各類各樣的業務。
第二個階段： 3-5年，解決一些異常問題，遇到足夠多的問題。總結其規律，找出業務痛點
第三個階段： 根據痛點、規律制定流程（開發規範、協做方式、設計模式），開發新的解決方案（新技術的誕生）算法

不謀而合，新技術的目標就是爲了解決一些痛點，優化工做效率。不管新技術是一種實際的技術，如redis、hadoop等解決現有存儲的問題。仍是如MVC、設計模式、OAuth通常只是提供一種思路，不一樣語言有不一樣的實現。新的技術（思想）只是針對特定痛點的一劑良藥，用的得當即可事半功倍，用的不得當便會事倍功半。apache

2：如何尋找業務的痛點

先說一段題外話：好久之前的一次聊天中，我給客服小妹講一黑科技：如今有一種技術，能夠模擬任何人的手機號給任何人打電話、發短信。編程

而後客服小妹就問，這技術有什麼用呀？
    能夠把本身假裝成任意一我的，而後給你打電話，你怕不怕。
而後呢？
    這麼說吧，假如給你家人發短信，上面顯示你的手機號，讓匯錢，怕不怕
我家人才沒這麼笨。。。
    那。。。

而後我就各類解釋，想讓她明白這技術多麼牛逼，多麼有用。
「好啦，我明白了，我逗你玩的，別太認真，哈哈哈哈」
而後就這樣了。。。

技術是很牛逼的技術，只是要想讓別人承認這項技術，尋找這項技術所解決的痛點尤其重要。幸虧只是跟同事瞎聊，若是就拿相似這樣的方案跟領導講技術解決方案，說不明白各模塊所存在的必要價值，估計就慘了。

好吧，說正事， 如何才能尋找開發中的痛點？

主要仍是多作業務，作足夠多的業務，作足夠多重複無味的工做。其它的崗位也是同樣，只有足夠多的使用本身的產品，纔會去反思如何提高效率。
一旦有了反思，有了提高的想法，便進入上面所提的第二個階段。
在這個階段，開發效率便會有所降低，由於想的更多，反思的更多。但這些想法每每不被認同，由於這些想法不符合常規的思路。因此你須要更加的努力，整日整夜的忙，產出卻跟其它人並沒有區別。須要補更多的課，好比他人認爲徹底用不到的TCP/IP、網絡編程、算法導論等基礎知識。思考的更多，總結更多的規律，就會發現越多不知道的東西。這個階段也許要2年，也許永遠走不出來，永遠對一些理論抱着仰望的態度，卻從未花時間去真正瞭解，指望着有大牛封裝這些功能。若是願意花一個週末全心的去了解，沒有哪項單一的技術是解決不了的。所謂聚沙成塔，多讀書，多看官網，此時能夠借鑑的資料已經不是特別多。但此時有一個好處，只要是能找到的資料都是很是有價值的，不會再有那些眼花繚亂的翻版與誤解。
選擇對業務有用的東西，深刻理解、總結其利弊、分析其應用場景，而後快速進入下一階段尤其重要。
在這一階段，就是要總結業務痛點，綜合所瞭解的知識，提出適當的解決方案。適當的時候須要開發本身的一套解決方案，如上所說，也許是一套理論，也許是一個實際的工具軟件。

3：引入新技術存在的問題

引入新技術可能存在一些問題，這是你們的共識。具體問題包括但不限於如下幾點：

不可控因素，忽然not work怎麼辦。因此不多有人在覈心業務中引入一些不是常規的第三方解決方案。
學習成本。通常公司都有本身的技術儲備，一旦引入新技術，就須要本身的團隊去嘗試、培訓、上線測試、填坑。
部分員工的排斥心理。這個不解釋

曾經聽過滴滴架構師李令輝的一次分享《用靈活的架構去適應變化的業務》，明確指出了咱們不引入新的開源技術。這看似有些難以理解，但卻有其意義。引入新技術有其優點，也有其弊端。再引用李令輝的一句:

咱們還有野心從新梳理總體業務架構，中國架構師比較不自信，當設計一個新架構的時候，你的領導和同事就會問是否有大公司這麼作過，大公司包括了BAT3M。

技術方案當然重要，但有一點更爲重要，就是團隊的「內研」能力。團隊的內部研發能力若是較弱，就算拿最牛逼的技術依然會走彎路。別人的技術方案只是一種工具，內研能力纔是決定咱們是否能把這個工具用在正確地方的主要因素。

4：如何引入新技術

分階段而論，若是是創立階段，制定一些框架類的規定，其它的技術方案選型以快爲主，惟快不破嘛。能快速解決現有問題的方案就是好方案。
到達盈利模式後，解決掉技術債務（把欠的東西都還上），這樣才能一身輕鬆的快速前進。積累經驗，分析各技術方案在業務中的利弊，發揮其長處、避開其弊端，充分提高業務能力。制定開發規範、優化協做模式，新技術的引入、使用、深刻分析、適用場景分析。當作好這些準備後，我的認爲開發效率至少能提高5倍以上。

從新說明一下：新技術不僅是指實際的軟件，也能夠是一些思路、一些模式。

5：最後

最後仍是說一說開始的話題：phper有沒有必要學習swoole。原本就是想說這個話題的，結果被打斷了，好吧，我仍是很執着的。

swoole作爲一個新的技術（其實成熟版本已經存在3年以上），與php充分融合，借用php的語法，使用php的cli運行模式就能夠測試其所有功能。看似swoole是php的一個擴展方法，實則否則。swoole是一套網絡框架，看過其源碼就會明白，其中有大量的C代碼，實現了併發、網絡編程、共享內存操做方面的東西，最終只是以php的擴展方式作爲最終呈現。

那麼，還有必要學嗎？

固然有，php作爲一種腳本語言，常規的職責就是藏在nginx/apache的後面接收請求，處理請求並返回給nginx。存在的問題是每接到一個請求就須要初始化一些資源，返回結果後就把資源釋放掉。這就決定了php只能作web應用，作服務就略牽強。舉個例子來講，用php提供一個分詞服務，分詞的服務端須要先加載詞典，而後接收用戶傳入的文本，將其分詞並返回。整個過程最耗時的就是加載詞典，而php常規的php-fpm模式須要每次加載詞典，這無疑是個很大的問題。若是把php前端的nginx去掉，php直接對外提供服務，那麼就可讓php啓動一個進程並一直存在，詞典也只須要加載一次。
這看似簡單的調整，實則已經改變了php在整個架構中的職責。如swoole官網所寫：從新定義PHP。

要如何學？

官網的demo看起來很簡單，但剛纔已經說了，swoole再也不是單純的php，是從新定義PHP。常規phper所不瞭解的網絡編程、併發、進程間通訊在這裏已是常識問題，不會有單獨的文檔介紹這些內容，須要本身去補充。若是有java、C/C++的併發編程經驗，上手這個會更方便。若是單獨去了解一下相關的知識，再來看這個東西，會有一種遇到神器的感受：swoole簡化了網絡編程的許多方面，可讓phper以最快的方式實現一個網絡服務器。然而也有一步一個坑的走過來的phper，真是邊走邊在內心咒罵，怎麼這個坑在文檔中沒有說明，爲何這個變量不起做用。具體的坑在另外一篇文檔中有說明（入口），這裏就再也不調戲swoole了，哈哈。至於swoole能作什麼，有人問能作數據採集嗎，這裏也不作解釋，swoole提供了更多的可能。掌握此技能頗有必要（業餘時間），無論如今你是否有適用場景。

不是有個段子嗎：若是你有一把錘子，看哪都是釘子。但若是你有100種熟練使用的工具呢？

所擁有的見聞（技能），決定了所看到的世界。