[size=medium]
[b]專家與雜家[/b]
專家與雜家之爭由來已久。
挺專家者說：只有專一，才能學透學精；那些泛泛之輩，只能學到些皮毛，終究不能有所成就。
挺雜家者說：只有廣泛，才能目光開闊；某些人天天鑽牛角尖，最後學成榆木疙瘩。
招聘的時候也是。
有人號稱精通七八種語言，參與過76個專案（在乙個真實簡歷中看到的，不過不是來我們這應聘的；按當時的速度估計，他現在應該寫參與150～200多個專案左右了），相信大家一定看了直搖頭。
但如果又有人十年如一日，只是在乙個文件轉換器上鑽研，恐怕也夠嗆能有什麼成就（這是當年叫做「在微軟工作十年的笨蛋」的故事，說有乙個人在ms工作了10年，除了office所有文件之間的型別轉換之外，什麼也不會，現在居然搜都搜不到了）。
那麼，到底哪個好呢？其實哪個都不好，或者說很多人把雜與專當作互斥的知識體系了。
[b]如何成為乙個好程式設計師[/b]
在10年多以前，我的師傅，乙個非常厲害的程式設計師，有一天和我們討論問題的時候（可能是在討論最近的一些招聘心得）突然說：「我發現，[b]厲害的程式設計師都喜歡說話[/b]。」
我腦海中迅速過了一下部門的20個程式設計師，果然不差。但是，背後的原理是什麼呢？
溝通，學習。
如果乙個程式設計師要經常和新手溝通，他就得嘗試把**寫得很乾淨明了，新手能看懂。
如果乙個程式設計師要經常和高手溝通，他又要把**寫得很精妙，不能一看就拖沓冗長。
最開始只是技術溝通，但最終會出現業務上的溝通，進而是知識上的溝通，所知道的範圍就越來越廣，逐漸變成雜家。
「變成雜家會不會水平下降？」
分析的結果，往往不是乙個蘿蔔乙個坑，而是某人或某兩三個人壟斷了所有最佳選擇。也就是，總有那麼幾個人，幹什麼都最拿手；還總有幾個人，幹什麼都不太行（而不是只能幹一件事情！）
這時候，這些高手們就變成了「既是雜家，又是專家」，怪哉。
原因就是程式設計師總會用自己學到的最高水平，解決所有事情；而見到的事情越多，可以學到，乃至只是偶然獲得更佳靈感的機會也越多。
所以，程式設計師不能偏安一隅，要多去從事不同的事情，理解不同環境中處理事情的方法；並把它們中的精華，互相借鑑。
典型的必須跨越的鴻溝，包括這樣幾個：
[b]1. 前端與後端[/b]
很多人居然只從事其中乙個，而對另外乙個置之不理。
由於這兩個內容互動非常多，只有了解對方的工作方式，才能做好自己的工作。
本人在這一點上感受頗深，在火星人的開發過程中，我其實自己乙個人前後都跑，從設計css風格到資料庫的應用快取，有什麼幹什麼。
這些內容常常相互依存，功能並不會很乾淨地 在前後臺拆開，經常其中乙個做好了，另外乙個就省事多了（尤其是我們採用了mvc的框架的情況下）。
[b]2. 開發與測試[/b]
乙個人很難直接從事這兩個職業，但是可以做這樣幾個事情：多關注出現的缺陷，目的是在開發過程就提前避免；多為測試人員編寫自動測試**，目的是學習產品的整體功能；多看測試人員的測試用例，目的是學習使用者的業務邏輯……
[b]如何防止失去專業性[/b]
人很容易失去專業性。
英國有一位物理學家，曾經在25個諾貝爾獎項上做過研究，但每個都淺嚐則止，被當作反面典型。
那麼，程式設計過程，怎麼防止這種現象呢？跟牛頓學習就知道了。
牛頓發明/發現過很多東西，物理三定律（總結前人），光譜，反射望遠鏡，微積分，萬有引力……他怎麼沒沒落成雜家呢？
[b]因為他所研究的東西，都是互相支撐的。[/b]
光譜發現後，牛頓預言折射望遠鏡一定有色差（不同光線的焦點距離不同），所以他研究發明了反射望遠鏡；由於他喜愛天文，所以開始關注都卜勒三定律，並從中推出了類似天體這樣的兩個質點，之間引力是2gmm/r^2這樣的關係（這個不是他第乙個推出來的），還首次給出了反向公式的證明；不過這還不能算是「萬有」，因為蘋果距離地面太近，地球不是乙個質點，至少不應該這樣計算蘋果受到的引力；這個問題直到20年後他發明微積分，才得以解決：按照球體的積分公式，整個地球吸引力等同於地心的質點……
總之，牛頓不是乙個「興趣廣泛」的人，而是乙個「刨根問底」的人，不會在乙個事情沒完的時候，就轉向到另外一件事情。而相反地，他之所以轉向另外一件事情，是因為當前這件事情遇到了瓶頸，需要其他知識的補充。
[b]結果就是他同時在諸多相關領域工作，成果互相支撐，最後終於達到了一定的高度。[/b]
[b]it人員如何防止失去專業性[/b]
對it人員尤其是程式設計師而言，如何決策呢？跟著需求走，不要跟著興趣走。
很多人學習乙個新語言，「想借鑑一下」，不是因為業務的需求，而是因為聽說這個語言不錯，這是比較危險的。
[b]人在沒有實際動機的情況下去學習乙個語言，想達跨過學習曲線而有所收穫，是非常困難的[/b]（想想自己在大學度過的「學習」時光，就知道了）。
[b]與其去「了解」遠在天邊的一種新語言，不如在自己正在開發的專案中，擴充套件自己的知識面[/b]，比如：
1. 嘗試跨越前端/後端/開發/測試的壁壘。
2. 嘗試使用某些新技術解決以往困擾已久的問題。
3. 在任何重構的機會，嘗試新技術（用老舊技術進行重構，是一種原地踏步的行為）。
[b]技術，管理，業務？[/b]
這在中等it人員面前，算是最後乙個問題了。很多人都問：「我是應該發展技術，還是學習管理，或者業務呢？很猶豫」
正確的答案是：全面，隨緣。
[b]什麼是全面？[/b]
仔細想想自己身邊那些只懂討好客戶不懂技術的銷售，再看看空話連篇的領導（多數諮詢師更甚！呵呵），又看看埋頭程式設計最後不符合使用者需求的程式設計師們……顯然我們明天不能做乙個讓今天的自己鬱悶的人，那麼唯有這些方面都做到一定程度，才是乙個全面人才。
[b]什麼是隨緣？[/b]
假設「全面發展」已經有一段日子了，領導突然過來說：「小張，我們最近想招募一些內部的產品經理，你既懂業務又懂開發還挺喜歡管理，想不想試試？」
這時候腦海中千萬不要想：「哎呀，天天外面跑，業務是熟悉了，技術和管理咋辦？」這個緣分，可能就錯過了。
產品經理有不同的做法。
不要獨斷專行，而是拉著銷售、研發一起參與進來，分析市場、使用者群、使用者體驗這些內容，這就是管理。
不要說完需求就撒手不管，而是陪同開發人員做出一些業務架構設計（一千零一問系列中曾提到：技術架構設計依託於業務架構設計），這樣做出來的東西不走樣，還有前瞻性，又能換來開發人員積極參與需求描述作為回報，這就是技術。
所以，就算成了「全職」產品經理，仍然可以業務/管理/技術三不誤。
[b]隨緣，不是隨波逐流無所作為，而是要與外界環境共振，積攢力量把握機會，而不是總幹些「逆天」的事情。[/b]
[b]金字塔形知識體系[/b]
[color=blue][b]專家與雜家的結合點，是金字塔形知識體系。[/b][/color]
金字塔之所以歷經五千年屹立不倒，歸功於其特殊的外形。
其他的世界奇蹟，多半都是「很細」的，所以很容易倒。而選擇「很細」是希望能節省材料，就像很多程式設計師埋頭乙個小模組一樣，省材料自然才能有積累嘛。
其實不然，狹隘的目光，很難支撐乙個足夠的積累。尤其是it業，不等積累到什麼高度，可能這個技術本身都過時了。
選擇上下一般粗好不好？也不好。如果要把金字塔弄成乙個巨大的立方體cube，估計也倒了。因為沒有人能在那樣的高度上堆砌這麼多的「頂級知識」，這個時候，就要回到乙個或幾個小的「頂尖」的狀態了。
後來施密特、卡塞格林、馬克蘇托夫他們發展了新的反射望遠鏡，而萊布尼茲也有額外的微積分發明，萬有引力也被愛因斯坦證明是物質存在所產生的一種場……所以即使是牛頓，也沒有把世界上所有事情都壟斷了，而只能「站在巨人的肩膀上」（堅實的底座），且「偶然撿到乙個美麗的貝殼」（個別塔尖）而已。
附：最後引號裡邊的兩句話，都是牛頓的原話。
第一句原文是：如果說我比別人看的遠些 那是因為我站在巨人的肩膀上
第二句原文是：我不知道在別人看來，我是什麼樣的人；但在我自己看來，我不過就象是乙個在海濱玩耍的小孩，為不時發現比尋常更為光滑的一塊卵石或比尋常更為美麗的一片貝殼而沾沾自喜，而對於展現在我面前的浩瀚的真理的海洋，卻全然沒有發現。
[/size]
ref：
canvas知識體系
把canvas想象成乙個畫板 乙個繪製狀態，可模擬畫圖工具中的工具欄 繪圖元素，包括簡單的圖形，線條，複雜的組合，和 繪製模式，比如畫板中的圖形存在繪製的先後順序，而存在重疊部分，該如何顯示存在重疊的圖形，這是繪製模式要解決的問題 裁切路徑，只讓畫板的部分可見 畫素操作，操作imagedata的畫素...
android 知識體系
1.雙鎖單例，為什麼要加 volatile？volatile就牽扯到指令重排序的問題了。要理解為什麼要加volatile，首先要理解new singleton 做了什麼。new乙個物件有幾個步驟。1.看class物件是否載入，如果沒有就先載入class物件，2.分配記憶體空間，初始化例項，3.呼叫建...
Vue 知識體系
由vue官網可知，vue大致分為如下目錄 基礎在基礎中，簡單的介紹了vue在本地記事本方式開發的整個過程，學過該內容，可以通過記事本簡單的進行開發，但是僅限於單個頁面之間，且均為簡單的使用。過渡 動畫 在該單元中，詳細的講述了vue元件的動畫內容，當乙個 所有功能全部搞定之後，就該使用到該單元內容，...