<input id="0qass"><u id="0qass"></u></input>
  • <input id="0qass"><u id="0qass"></u></input>
  • <menu id="0qass"><u id="0qass"></u></menu>

    學習方法和自我管理雜記

    軟技能 專欄收錄該內容
    3 篇文章 0 訂閱

    1. 兩種學習方法

    昨天聽一個講座,挺有意思,怎么學習一個東西,有兩種辦法:一個是像學習母語一樣,天天刺激你一點點的學習具體內容;一個是像學習英語一樣,把知識梳理好歸納成語法規則和語言理論。明顯第一種最好,自己去慢慢發現規律、總結規律,從內到外融合貫通,但是過程漫長。第二種辦法高屋建瓴,快,但是不具體不牢固,你學了很久過去將來時態也搞不清楚一句具體的話怎么去說。

    2. 馬拉松式學習與技術人員的成長性

    你的朋友圈里總有一些人具有某種特殊的技能點。比如我的一位鐵哥們波仔,就是這樣的人。
    波仔,江湖人送外號波哥,是我認識的程序員里面最能跑的。國內的馬拉松賽事,他幾乎一次不落地參加。只要哪個城市舉辦馬拉松比賽,不管多遠,他都一路飛奔過去。這不,前兩天剛冒雨跑完了無錫的馬拉松。雖然淋得跟落湯雞似的,但感覺就一個字——爽!
    波仔年輕的時候曾是專業運動員,有著令無數少女尖叫的健康體魄。后來做了程序員,雖然跑步從此成了業余愛好,但仍然威風不減當年,很隨意地就跑能個半馬,緊接著再跑個全馬,都是小菜一碟。我們搞程序的,誰沒經歷過沒日沒夜加班的日子。常言道,身體是革命的本錢。這說起來,好的身體也是程序員的核心競爭力之一呢。
    意大利「文藝復興之父」彼特拉克曾經說過:「肉體和心智的能力必須大到足以滿足文學活動和妻子兩方面的需要?!谷绻麚Q做程序員的角度,這句話應該修正一下:肉體和心智的能力必須大到足以滿足熬夜寫代碼和女朋友兩方面的需要。當然啦,這個說法也還遠沒有表達出生活真實的復雜性和嚴峻性。
    所以,跑步是鍛煉身體很好的手段。但是馬拉松,除了鍛煉身體,同時也是對人性的考驗。一件接近身心極限的事情,你的身體能否承受,你的精神能否堅持下來。
    波仔多次邀請我一起去跑個馬拉松,都被我毫不猶豫地拒絕了。這身體條件,咱不能強求。沒有準備的極限運動還是比較危險的。但是,對于有能力跑下來的朋友,我在精神上表示羨慕和支持。
    有時候我會把學習比作跑步。對于類似程序員這樣的職業,新技術更新換代的速度確實比較快,這需要你總是保持在學習的狀態。
    應該說,在一般情況下,程序員們對新知識進行學習的能力都還是比較強的。工作中碰到以前沒做過的東西,只要能在網上找到對應的開發文檔,仔細讀一讀,再看幾個 Demo,就基本能解決問題了。這種規模的學習過程,一般幾天就搞定了,可以看做是一次「短跑」。
    當然,這種「短跑式」的學習過程,也只對于「一般性」的情況有效。而對于一些「專業性」的領域,我們就需要「馬拉松式」的學習姿態了,做好充分的準備,并且長時間投入,半年,一年,甚至更長。
    實際上,編程這門工作,門檻說低也不低,說高也不高。很多學歷不高或者非科班畢業的同學,也都能把這份工作從事得很出色。但是按技術領域來區分的話,編程還是可以分為「一般性」和「專業性」兩大類的。對于「一般性」的技術領域,你只要具備一點計算機基礎,懂得一門編程語言,能理解業務邏輯,就能勝任了。但是「專業性」的技術領域就不一樣了,除了計算機基礎知識之外,你更需要掌握一整套知識體系,可能對數學知識還有特殊的要求。這樣的領域有哪些呢?比如說,分布式系統,數據庫理論,音視頻處理,3D游戲引擎,操作系統和虛擬化技術,大數據處理,還有最近火爆的人工智能技術,等等。
    對于「專業性」的這些知識,如果你打算涉足其中,就得需要拿出跑馬拉松的精神了。據說馬拉松跑到一半,很多人就會產生強烈的「想放棄」的想法,后半段就靠毅力支撐了?!格R拉松式」的學習過程也是一樣??赡芤婚T「專業性」領域的知識,最開始吸引你的是興趣,它非常有意思,可能聽起來還很酷,但隨著研究的深入,你就不可避免地遭遇很多沮喪時刻。你會發現,你學得越多,未知就越多。這時候你肯定會產生放棄的想法,甚至對自己是否適合做技術產生一絲懷疑,但是沒有關系,每一個在某一領域走得足夠遠的人都會碰到這樣的情況。只要你咬牙堅持下去,隨后你得到的獎賞必然是恍然大悟或醍醐灌頂的感受。我相信 ,這與一場馬拉松終于跑到終點的勝利喜悅是一樣的。
    有長跑經驗的人都知道,真正能在馬拉松上取得好成績的人,基本上都是勻速跑者。開始跑得多快并不關鍵,關鍵在于「后勁」足不足。我們的職業生涯也是一樣,不管是程序員還是其他職業,這個道理都適用。
    我時常在想,不同技術人員之間的區別到底在哪。是在于工作經驗,還是在于他們的聰明程度,或者是在于他們是否有名校的教育背景?為什么本來基礎差不多的人,多年之后會產生巨大的差異?與此相關的一個很實際的問題是,我們在招聘新員工時,到底應該看重他們的哪些特點?我最后想到的答案是,決定不同技術人員之間的真正分野,在于「成長性」,也就是持續學習和提高自身的能力。換句話說,「后勁」足不足。一個人的成長過程,什么都可能隨時變化,但成長性本身不應該有絲毫減弱。
    設想一個稍微極端一點的情況,假設你要自己創業,現在要物色合伙人的角色。你會怎么選?你必須考慮他們的成長性。你放眼四周,也許你周圍的很多朋友都能幫你解決當前的問題。但你物色的人選,他們能否隨著公司一起成長?他們身上有沒有自我超越的基因?都說找合伙人比找對象還難,的確如此。跟不上公司發展節奏的合伙人,注定將是一場災難。
    而創業公司的 CEO,作為掌舵人,他自身的成長性其實要求更高,因為這決定了公司和團隊的未來,責任極其重大。Facebook 的 CEO 馬克·扎克伯格,每周都堅持讀一本新書,就是為了保持自己的成長性。有些自私的老板,他們忽略了這份責任,可能認為「我給你發工資你給我干活」是理所當然的事情。但是,確保團隊成長的責任,和公司發展的責任,同樣重要。
    實際上,凡是帶團隊的人,都有這份責任。如果你自己混日子,不能一步步成長,那你的團隊成員又怎能獲得突破自己的機會呢?職位越高,責任越大。當你的 leader 或某個機遇把你推到那個位置的時候,你為進一步的成長做好準備了嗎?估計很多人是想不到這一點的。還聽說有些極端的團隊 leader,甚至整日擔心下屬會超過自己,不但不給團隊成員創造成長的機會,還打壓下屬。真是不理解這些人是怎么想的。所以,跟對人很重要。
    投資人是否會投資一家公司,看重的是公司的成長性;我們買股票也是一樣,都會選擇成長性好的股票。甚至女孩子找老公,也希望找個「潛力股」。所有這些選擇,都是在追求「成長性」帶來的升值。
    只要想明白這一點,我們就不再會為一些不必要的擔憂而煩惱。比如,很多人擔心年齡大了就再也做不好技術,或者擔心年齡大了之后的職業發展問題。顯然,年齡并不是決定成長性的關鍵因素,這頂多是一個心理因素。成長性更應該是一個人的本質特征,是他所具備的基因。人與人的不同究竟在哪里?具體技能總是會變化的,但基因是不變的,也不應該隨著年齡的變化而變化。
    人的可貴之處就在于學習和塑造能力,這是造物主賦予我們的可貴品質。
    甚至現在的人工智能模型也要以學習的方式來訓練,才能產生它需要的職能。一個復雜的模型,需要大規模的訓練,喂給它很多數據和模式,才能讓它獲得新的知識,不斷提高「智能」。
    我們可以想象,人腦其實也是一個智能模型,只不過這個模型更龐大,參數更多,容量更大;訓練它需要的數據更多,時間也更長。如果你想成為某方面的專家,就需要花費很多年的精力來進行專業訓練。
    一個人,要想在某方面獲得睿智,唯一的辦法就是持續地學習、調整、提高、成長。這個過程需要耐力和堅持,而最終你會收獲成功和樂趣。
    一句話,保持學習,保持「后勁」,保持成長。

    3. 進階之路

    那么,為了達到真正的突破,有哪些因素是我們需要重視的呢?
    第一,根基。
    在接觸一門新技術或者一個新的技術領域時,良好的基礎有利于我們快速突破,抵達下一個階段。不同技術之間,基礎卻是相通的。比如,對于計算機軟件學科的基礎知識——數據結構和算法,處于熟手期的程序員可能多半會認為它們在工作中根本沒有用。這是因為這個階段的技術人員主要靠孤立的經驗解決問題,一些基礎的知識自然就用不上。但對于技術專家層次的人來說,數據結構和算法卻是在系統設計的很多方面潛移默化地發揮作用。對于其它計算機基礎學科,這個道理也同樣適用。
    再比如,現在人工智能和機器學習技術比較火,似乎全民都在學習。但要想學好這些技術,至少應該對于微積分、線性代數、概率論、統計學等數學知識有比較扎實的基礎,才能走得更遠。
    第二,外因,一個不疾不徐的環境。
    過于寬松的環境自然不利于人的進步,而盲目的緊張也不利于人的成長。
    突破的過程需要付出巨大的精力,所以需要投入足夠的時間去從容地完成。我們大概都經歷過這樣一種場景:新產品上線在即,但還有很多問題需要解決。如果距離預定上線時間還有數天,那么我們可以相對從容地用比較優雅的方式來解決這些問題,并做一些長遠的打算;但如果我們碰到的情況是,兩個小時以后就要上線了,那么我們多半會想一些歪點子來規避這些問題。
    產品開發和技術優化,有時相輔相成,有時又互相矛盾。如果你所處的工作崗位,只是要求你不停地修改業務流程,盲目地試錯,那么,可能公司根本沒有給你留出技術突破的空間。試想,一個主旨不清,功能點做了新的就扔了舊的,而沒有長遠的目標,也不去持續優化體驗,這樣的一個產品,又怎能有持續的生命力呢?
    第三,正確(正宗)的學習資料。
    新手剛開始工作的時候,通常只要看一些入門教程(Tutorial),跑幾個Demo,掃除了表面上的技術疑問點,再針對業務代碼向老員工請教一番,基本就能開始工作了。然后一邊編碼,一邊查閱所需要的API Reference,時間長了,經驗和技巧足夠多了,就自然變成熟手了。
    而從熟手向專家的突破,則需要系統地去補習知識架構。技巧應該建立在對于普遍規則的理解之上。這里不得不提及Spec,它是涉及某項技術的完備的、系統的描述,包含該項技術涉及到的方方面面(具體參見我的另一篇文章《技術的正宗與野路子》)。在奔向技術專家的路上,閱讀Spec,是不可逾越的一道功課?!渡涞瘛分泄傅奈涔ν黄?#xff0c;很大程度上就是因為他閱讀了《九陰真經》這份大大的Spec。當然,除此之外,你可能還需要通讀重要部分的API Reference以及Source Code。
    技術專家必然將原始文獻(官網Spec、論文等)作為知識的第一來源。相反,跟著某人的博客去系統地學習某方面的技術,是要冒有很大風險的,還需慎重選擇。
    最后,要想成為技術上的一代宗師,則需要更高的抽象,做出完全創造性的工作。這份工作不僅僅是閱讀Spec,解決具體的問題了,而是創作Spec,開創全新的天地。
    第四,獨立思考,不要自我設限。
    現在,很多人喜歡把技術好的人喊作“大神”。這自然是代表一種尊重,很多聽的人也很受用。
    但是,“神”的稱呼暗含了一層意思:神是無法超越的,是普通人學不來的。這是人們在潛意識里劃出的一道鴻溝。所以,我就不太喜歡類似這種稱呼。
    很多人碰到問題就喜歡找身邊“大神”去問,但殊不知問再多問題,你仍然無法真正地有所提高。普通人和“大神”之間真正的鴻溝在于,能否獨立思考和解決問題。

    在追求技術成長的路上,不可能總是一帆風順。我們不免有時沮喪,有時欣喜。
    人生苦短,有人窮其一生,就是想要達到理想中的那個狀態。但不管結果如何,當我們青春不再的時候,只求問心無愧。

    4. 從拖延到高效,我推薦這 7 本書

    最近幾個月一直在看一些非技術類書籍(大約50本左右),感覺收獲非常大,從中選擇出來比較經典的改變拖延、高效學習的書籍,希望給大家提供一些參考。
    《拖延癥心理學》
    網絡越來越成為了人們不愿意做事的罪魁禍首,這種趨勢正在不斷地蔓延。如今,信息已經鋪天蓋地、無所不在、太多的信息、太多的決定、太多的選擇,讓我們很多人陷入拖延的泥沼之中。
    這本書對拖延癥分析很到位,特別是前半部分在描寫拖延癥的時候,后半部分給出解決方案。
    這本書能讓你看清自己為什么會拖延,找到拖延的本質,給出解決方案讓拖延之手從你的生活中松開!
    《學習之道》
    我們不僅必須善于等待,還要享受等待。因為等待不僅僅是等待,它還是生活。我們中的很多人生活著,卻沒有全心投入。當我們真實的生活開始時,卻一味等待。
    美國公認的高效學習經典書。世界冠軍現身說法,揭秘從平凡到天才的成功之道。這是在任何領域都能成功的學習方法。這是任何人都適用的終身深入學習法。教你“以較小的努力贏得美好成就”。
    這本書講的學習方法,顛覆了大多數人對學習的認識。以及還講解了遇到困境該如何高效學習。
    《搞定Ⅰ:無壓工作的藝術》
    GTD是“Getting Things Done”的縮寫,翻譯過來就是“把任務完成”。是由作者戴維·艾倫開創的一套完整個人時間管理系統。
    了解過時間管理的同學,應該都知道GTD。
    GTD的五個核心原則是:收集、整理、組織、回顧、執行。
    《番茄工作法圖解》
    番茄工作法是簡單易行的時間管理方法,是由弗朗西斯科·西里洛于1992年創立的一種相對于GTD更微觀的時間管理方法。
    之前寫過關于番茄文章
    《時間管理之番茄工作法》和《番茄工作法的時間管理套路》
    這本書有圖片、步驟幫助你輕松學會番茄工作法精髓;至于堅持,用番茄工作法是會上癮的,你只需要擔心自己戒不掉。
    目前我就是GTD組合番茄工作法,十分的高效。
    《Google工作整理術》
    不要花太多時間給信息歸檔,用的時候學會去搜索;
    在數字信息文檔中加上關鍵詞,方便日后檢索;
    從前,知識就是力量,現在,共享知識才是力量;
    把工作和生活融為一體,而不是力圖在二者之間求平衡。
    這些實用Tips都揭示了:信息整理才是高效工作的關鍵,信息整理已是現代人的工作必備技能!
    這本書教你如何:過濾分類、各個擊破、有效組織。
    《凸法則》
    一個對其他人發自內心感興趣的人,在兩個月里創造的溝通,要比一個總是試圖讓別人對自己感興趣的人在兩年內創造的溝通還要多。
    高效表達自我的心理法則。
    這本書提供了一系列可以快速吸引他人注意力的心法和方法。
    《習慣的力量》
    我們的生活在某種程度上有其固定形態,是習慣的集合體–有現實生活的習慣、感情生活的習慣,還有思維的習慣。這些習慣系統化地構成了我們的喜怒哀樂,讓我們走向自己的命運。不管最終命運如何,我們都無法抗拒。
    這是最后一本推薦的書籍了,這本書籍至關重要,因為上面的書教會了我們解決拖延,溝通,學習,工作,但最重要的還是要把好的行為養成一種習慣。

    本書單適合從上往下一本一本看。
    通過《拖延癥心理學》和拖延癥說:“拜拜”。
    通過《學習之道》來提升自身學習能力。
    通過《搞定Ⅰ:無壓工作的藝術》來用GTD來規劃任務。
    通過《番茄工作法》來做細分任務用番茄鐘計時執行。
    通過《Google工作整理術》告別無序工作,學會利用數字工具為大腦減壓,從而提高自身工作效率。
    很多情況下效率不僅是我們本身的問題,還是協同的問題,通過《凸法則》提高我們的溝通能力,而從提高整體的團隊效率。
    通過《習慣的力量》把這些好的行為養成自己的習慣。
    希望能夠對大家有幫助。

    7. How to read source code

    http://blog.codinghorror.com/learn-to-read-the-source-luke/

    Most projects supply a documentation on the wiki/readme.
    In the meantime, there are a few strategies:
    Pick a feature you like, and try to find the source that implements it
    Find the beginning point in the source and step through it, try to understand how it sets itself up
    Start poking around aimlessly until you find something that makes you curious (i.e. that’s an interesting technique, why have they done that? etc)
    One thing that helps me is to put myself in the author’s shoes. Why did they do things this way? Was it good/bad? For me, reading source code is about learning new strategies for solving problems. I usually look at a project and think how I would have done it, then I see how they do it and compare.

    No matter what the documentation says, the source code is the ultimate truth, the best and most definitive and up-to-date documentation you’re likely to find.
    When people report a problem with their stack, the first question I ask them is: “Well, did you read the source code?”

    8. 技術的正宗與野路子

    黃衫女子的武功似乎與周芷若乃是一路,飄忽靈動,變幻無方,但舉手抬足之間卻是正而不邪,如說周芷若形似鬼魅,那黃衫女子便是態擬神仙。
    這段描寫出自《倚天屠龍記》第三十八回。
    “九陰神抓”本是《九陰真經》中的上乘武功,但當初梅超風夫婦由于拿到的《九陰真經》不完整,學不到里面的內功心法,硬是把這門上乘武功練到了邪路上,于是就成了“九陰白骨爪”。周芷若為求速成,也練就了這門邪功。
    但黃衫女子乃出身武林名門(相傳是楊過和小龍女的后人),自然修煉的是正宗的《九陰真經》。雖然武功路數與周芷若本同屬一脈,但更加“醇真深厚”,自然也更勝一籌。這是金庸武俠中“正宗”武功勝過“野路子”的一個典型案例。
    那么,這是否能夠說明,“正宗”一定強于“野路子”呢?
    且慢!
    喜歡金庸武俠的朋友,可還記得《越女劍》中的阿青?
    阿青本是一名牧羊女,卻在牧羊時巧遇一頭會使竹棒的白猿。在與白猿的玩耍嬉鬧中,她硬是悟得了高超的劍法,竟能以一人之力敵兩千越甲!
    就是這樣一個從野路子練出來的柔弱女子,即使按廣大金庸迷的保守估計,她也能在整個金庸武俠圖譜中至少排名前五!

    做技術,猶如修習一門武功。
    歷數我周圍的技術牛人(牛不到一定程度的先不算),他們中既有名牌大學計算機科班畢業的,也有半路出家轉行過來的。
    但他們都有一個共同特點:他們在遇到問題后,思考片刻,總是能一下子切中要害,在表達上也往往一語中的。這也包括那些平常不善言辭的程序員。反觀那些“更一般”的程序員(其中不乏科班畢業的),他們經常很難抓住問題的本質,表達起來也總是說不到點子上。
    可見,“正宗”還是“野路子”,并不在出身。
    寫到這里,我終于自己長出了一口氣。我出身一個極普通的農民家庭,既不是書香門第,也不是技匠世家。記得在大學一年級的上機編程課上,我才發現自己原來根本不會用鍵盤打字。相比那些初中高中就把計算機玩得很溜的同學,我算野路子嗎?
    好了,那“正宗”還是“野路子”,不在出身在什么呢?
    在于學習和思考的方法。
    據我觀察,技術牛人的學習方法和思考方式,大體類似。
    思考方式,是個很難說清的東西。所以,本文我們重點來討論討論學習的方法。

    面對一項新技術的時候,我們怎樣去學習才能循序漸進,最終理解得深刻?
    讓我們先把可供自學的資料列出來,分析一下:
    Tutorial(入門教程)。由該項技術的官網提供。通常是英文的。這份資料是給初次接觸該項技術的人看的,一般是一步一步地教你完成某些例子。當我們說某項技術對于新手不太友好的時候,一般也是因為這項技術的Tutorial部分做得不夠好。
    Specification,簡稱Spec。這是集中體現該項技術的設計思想的東西,是高度抽象的描述。這個一般也是一份完備的、系統的描述,包含該項技術涉及到的方方面面。這部分資料在不同的地方叫法不同,在相對簡單的技術項目中,也可能沒有;在另一些情況下,這部分資料混雜在其它文檔資料之中;它還可能以論文(paper)的形式出現。
    API Reference。大而全的API索引和文檔,針對不同的語言接口可能提供多份。當我們使用這項技術進行編程的時候,API Reference自然是個離不開的、總是要不停去查詢的一份資料。
    別人寫的技術博客。質量良莠不齊,到底有沒有價值,我們要學會去分辨。
    技術書籍。跟技術博客類似,質量有好有壞。稍后我們和技術博客放在一起來分析。
    Source Code。如果我們要學習的技術是開源的,那么很幸運,我們能得到源代碼。這是一份終極資料。
    為了讓這些概念表達無誤,我接下來多舉一些例子。
    Java語言
    從來沒有接觸過Java語言的人,要想開始自學Java,從哪里開始呢?可以從Oracle官方提供的Tutorial入手:
    http://docs.oracle.com/javase/tutorial/
    這份資料《The Java? Tutorials 》,集中體現了Tutorial類型的資料的特點。它從最開始的編譯和運行環境搭建說起,教你寫出第一個Hello World,再用介紹的方式將Java各種語言特性(變量、類、泛型、Lambda表達式、JavaBeans,等等)進行講解,同時還有對于JDK里常用API(集合類、多線程、IO等等)的介紹。
    對初學者而言,需要的就是這樣一份資料。即使你手頭沒有任何Java的入門書籍,讀完這樣的一份資料之后,一個新手基本就可以開始使用Java來編程了。
    再看Spec:
    http://docs.oracle.com/javase/specs/jls/se8/html/index.html
    這份文檔,叫做《The Java? Language Specification》。是一份很典型的Spec,完備而規范。
    任何講Java語法的資料,包括各種書籍和前面提到的Tutorial,都只能涉及部分。而這份Spec,如果你能讀通的話,那么與Java語言特性有關的所有一切,你就再也不用求人了。
    JDK 8的API Reference:
    http://docs.oracle.com/javase/8/docs/api/index.html
    用Java語言編程的時候,我們需要不斷查閱的就是這份API Reference。我們平常一般是通過IDE來快速查看某個接口的文檔說明。
    Android開發
    Android針對新手的Tutorial類型的資料,官網上稱為Training:
    https://developer.android.com/training/index.html

    這份資料是典型的Tutorial。它教你制作第一個Android App,并針對若干個主題進行一步一步的教學。
    下面這份資料在Android官網上被稱為:API Guides。
    https://developer.android.com/guide/index.html

    它實際上是一份介于Tutorial和Spec之間的文檔。它有很多Spec的特點,比如它介紹Android中的抽象的四大組件的概念,介紹資源尺寸的抽象(dp),介紹View層原理,等等。但是,跟前面看到的Java Spec相比,它沒有那么規范和正式,描述也更隨意一些,估計也算不上完備(但涉及到了Android技術的絕大部分)。
    當我們對Android中某項具體技術存疑,或是有爭論的時候,我們就需要來翻翻這份文檔。因此,它基本可以歸入Spec類型。
    然后是Android SDK的API Reference:
    https://developer.android.com/reference/packages.html
    這份API Reference的質量并不高,描述上過于簡略,甚至模糊不清,其可讀性跟前面提到的JDK 8的API Reference完全不在一個水平上。這也是一些開源項目的通病,不重視接口文檔。
    iOS開發
    蘋果在iOS開發方面給出的文檔是相當豐富的,這也是一個閉源系統做得好的地方。
    iOS開發的文檔,很難區分出Tutorial和Spec這兩個層面。它由很多文檔組成,每個文檔描述系統的某一方面。通常是在一個文檔中,既有教學的部分,又有完備描述的部分。
    針對完全的新手入門的話,下面這個文檔,算是真正的一個Tutorial:
    Start Developing iOS Apps (Swift)(https://developer.apple.com/library/ios/referencelibrary/GettingStarted/DevelopiOSAppsSwift/index.html)
    其它各個文檔也是介于Tutorial和Spec之間,更偏向Spec。比如:
    App Programming Guide for iOS(https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Introduction/Introduction.html)
    View Controller Programming Guide for iOS(https://developer.apple.com/library/ios/featuredarticles/ViewControllerPGforiPhoneOS/index.html)
    View Programming Guide for iOS(https://developer.apple.com/library/ios/documentation/WindowsViews/Conceptual/ViewPG_iPhoneOS/Introduction/Introduction.html)
    Core Animation Programming Guide(https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreAnimation_guide/Introduction/Introduction.html)
    Concurrency Programming Guide(https://developer.apple.com/library/ios/documentation/General/Conceptual/ConcurrencyProgrammingGuide/Introduction/Introduction.html)
    然后是iOS的API Reference:
    https://developer.apple.com/reference/
    如前所述,這份API Reference的可讀性非常高,比Android SDK的要強多了。很多前后相關的概念,在這份API Reference的描述中,都有體現。
    當然,除了developer.apple.com之外,iOS的文檔也都可以通過XCode取到。
    Redis
    Redis的Tutorial是我見過的最好的Tutorial,它對初學者非常友好,不僅能讀,還能執行。
    http://try.redis.io/

    Redis的Spec舉例:
    Redis Protocol specification (http://redis.io/topics/protocol)
    Redis Cluster Specification (http://redis.io/topics/cluster-spec)
    Redis RDB Dump File Format (https://github.com/sripathikrishnan/redis-rdb-tools/wiki/Redis-RDB-Dump-File-Format)
    Redis的Commands Reference:
    http://redis.io/commands
    TCP/HTTP
    網絡協議與前面的都不同,它不是一個實現,而是一種標準。
    網絡協議的Spec文檔很明顯,就是它們對應的RFC。如果你的工作經常涉及到使用某個網絡協議,恐怕就需要找來RFC通讀一遍了。

    再來說一下技術博客和技術書籍。
    現在網上的技術文章空前繁榮,想讀都讀不過來。胡峰同學在他的微信公眾號“瞬息之間”上,發過一篇文章《技術干貨的選擇性問題》,討論的就是技術人員在當前技術文章爆炸的情況下如何取舍的問題。
    在這里,我們從另一個角度來討論一下這個問題。如果一篇技術文章,僅僅是對于所涉及技術的官方文檔(Tutorial或Spec)的復述,甚至只是個翻譯,那么就價值不高。換句話說,如果我們能通過閱讀官方文檔學到同樣的知識,那為什么要看你寫的技術文章呢?官方文檔自然更權威,直接閱讀它能確保不會遺漏重要的東西。
    那什么樣的技術文章才有價值呢?大概可以說(未必那么準確),那些包涵了實踐經驗的,能將各個技術點綜合起來產生思考,從而給人以啟迪的。簡單來說,就是有深度的。
    當然,技術書籍也大體如此。

    我們回過頭來再看一下,各個學習資料之間的層次結構。

    每當我們接觸一項新的技術的時候,我們都要把手頭的資料按照類似的這樣一個金字塔結構進行分類。如果我們閱讀了一些技術博客和技術書籍,那么也要清楚地知道它們涉及到的是金字塔中的哪些部分。
    最開始,一般讀完Tutorial之后,就基本能上手做一些開發工作了。然后一邊開發,一邊查閱API Reference。注意,從這時候起,你的老板就開始向你付工資了,因為你的工作已經能夠產出成果了。
    但是,工作一段時間之后,我們發現,似乎身邊的技術牛人學東西都比較快,而且在很短的時間內就能對某項新技術達到很深的理解。這是為什么呢?
    這并不是因為技術牛人閱讀技術資料閱讀得快,而是他們知道閱讀正確的資料,從而很快能達到知識金字塔更高的一層。
    我見過的很多技術牛人,他們如果不是把一項技術至少理解到Spec那個層次,他們是不敢隨便寫代碼的。相反另一些人則從網上隨意拷貝代碼,并在自己不能完全理解的情況下用到項目中去。技術牛人們當然也參考網上的代碼,但他們通常會確保它的每一部分都能安放在知識金字塔的某一部分,他們不容許那種不屬于任何體系的知識孤島的出現。
    我們現在可以這樣總結,技術的“野路子”,其實是知識結構的不完整和不系統造成的一種狀態。只有當你沖破知識金字塔層層的障礙,邁向更高層次的時候,老板才開始向你付高價。

    我們的大腦好比內存。
    既然是內存,就裝不下所有的知識。但應該能裝下對于知識的索引,否則我們便沒法工作了。
    那么,這里就有一個選擇性的問題:我們選擇哪部分知識加載到“內存”里呢?
    顯然,應該優先選擇重要的,對我們最有用的信息。
    對于那些最核心的技術,我們應該做到:
    通讀Spec。讀完就不再困惑。
    重要部分的API Reference要通讀。里面包含了很多跟實現有關的信息。
    如果工作需要,還可能需要讀到Source Code。特別是對于平常一直在使用的SDK,不一定從頭到尾把源碼讀通,這樣工作量太大且效率不高,但一定要把你的開發環境設置成一點擊某個調用的方法就能跳轉進源碼實現。只有這樣,你才能把平常開發的時間利用起來,隨時隨刻都點過去看源碼。
    對于剩下的知識里80%的部分,應該至少理解到Spec層次。只有這樣,我們才能游刃有余地去使用它。
    通讀重要的Spec,在很多情況下,其實還是很有難度的。這需要毅力,和一點點英語基礎。
    按本文前面提到的例子,做Java的人有誰讀過Java Spec?做Android的人有誰把developer.android.com上的API Guides都能通讀下來?而做iOS的人,developer.apple.com上的各個Programming Guide又完整地讀過幾個?對于經常調用的SDK,你會有計劃地去通讀其中重要部分的API Reference嗎?
    能夠把這一套做下來的,有可能不成為技術牛人嗎?

    到了文章最后了,總感覺還有些意猶未盡,腦海中似乎有些東西還是沒有表達出來,也不確定本文描述的學習方式是不是適用于每位讀者。仔細想想也難怪,學習本來就是一個復雜的問題,每個人并不是完全一樣的套路。
    但是,不管本文介紹的方法是“正宗”的路子,還是屬于“野路子”,我在這里想要強調的一點是很明確的,那就是:要把知識梳理成系統的結構,要讓頭腦中的知識層次清楚,為此,我們需要閱讀恰當的東西,需要不斷地練習,需要克服種種困難。
    成長沒有捷徑可走。需要的是一個一個堅實的突破。

    9. 如何讓自己成為一個優秀的程序員

    這個人真的知道他們正在做什么:
    你的想法:編程能力和年齡是成正相關性的,希望編程到老,當然身體要好。
    溝通方式
    管理自己的方式
    精湛技術水平編程演講的方式

    他們做調查研究
    “三思而后行”,或者叫“谷歌一下”
    優秀的程序員在解決問題之前知道通過GitHub圖書館、網絡博客,或者通過與經驗豐富的程序員交流等形式來做調查研究。

    他們閱讀錯誤信息(并按照它們行事)
    這包括解析堆棧路徑信息。
    我知道的高效程序員是不會害怕深究問題的。
    優秀的程序員發現問題馬上就解決它。讀錯誤信息對他們來說僅僅是個開始,他們渴望深究問題并查出問題的根源。他們不喜歡推卸責任,而是愿意查找解決問題的方案,問題在他們這里止步。

    他們去看源代碼
    文檔、測試、團隊,這些都會說謊。盡管不是故意的,但是如果你想確切地知道事情是怎么回事,你必須自己親自看源代碼。

    They just do it
    優秀的程序員趨向于主動去做。他們的內心有著難以控制的沖動,當他們確定問題或者發現新的需求時他們立刻會實現解決方案,有時過早有時太過激進。但是他們對問題本能的反應是正面解決問題。

    他們避免危機

    他們善于溝通交流
    說到底,編程是一種形式的溝通交流。寫代碼和寫散文創作一樣,能夠簡潔地表達你的想法很重要。我發現那些可以寫簡潔郵件,優雅的狀態報告,或者甚至只是一個有效的備忘錄的程序員也將會是優秀的程序員。

    他們激情四射
    我認為這可能是優秀的程序員最重要的方面(也許這點也適用于除計算機科學領域的其它領域)
    如果你真的在乎你所做的事情,如果不把它當成工作,當作一個業余愛好、興趣或一件很有吸引力的事情,那么在該領域你比其他人更有優勢。優秀的程序員一直不斷編程。普通程序員一天工作八小時,并且沒有業余項目,也沒興趣回饋社區。他們不會不斷地嘗試新方法,而只是為了看看它們是如何運行而執著于編程語言。

    當我看見一個程序員利用周末的時間做自己喜歡的項目時,參與創作他們每天能用到的工具時,執著于新的有意義的事情時:那個時候我確信我眼前的是一個令人驚奇的人。最后,優秀的程序員視他們的職業不僅僅是賺錢的途徑,更是讓生活變得有些不同的方法。我認為那就是成就最優秀程序員的真正原因。對于他們來說,編寫代碼是改變世界的一種方法,也是我非常尊敬崇拜他們的原因。

    真正的錯誤是,當你知道應該如何去提高時仍然選擇做一名初學者。

    1.提交(簽入)代碼需要填寫備注說明
    2、每天匯報自己的工作情況
    3、對一些公共庫的修改一定要謹慎,并且測試再測試
    4、需求要確認,切勿盲目編碼
    5、經常主動地去和別人進行 Code Review
    6、要相信自己的工作在團隊中是舉足輕重的
    7、不要盲目拷貝代碼
    8、及時記錄工作日志

    我司很多剛來的大學生在半年內都能把一些中間件系統摸的很明白,并不是說有多難,只是接觸少,對未知的東西感到害怕疑惑而已。
    大型網站技術架構-核心原理與案例分析。 @李智慧大牛的書
    大型分布式網站架構-設計與實踐。作者:陳康賢
    大型網站系統與java中間件實踐。作者: 曾憲杰(原淘寶技術,現在蘑菇街)
    然后再推薦一個網站并發編程網 - ifeve.com。這個網站的知識絕對夠你面試一個阿里P7,京東T3-2,騰訊T3-1。

    其次掌握的技能樹主要有三個方面:
    第一個是基礎。比如對集合類,并發包,IO/NIO,JVM,內存模型,泛型,異常,反射,等有深入了解,最好是看過源碼了解底層的設計。比如一般面試都會問ConcurrentHashMap,CopyOnWrite,線程池,CAS,AQS,虛擬機優化等知識點,因為這些對互聯網的企業是絕對重要的。而且一般人這關都過不了,還發鬧騷說這些沒什么用,為什么要面試。舉一例子,在使用線程池時,因為使用了無界隊列,在遠程服務異常情況下導致內層飆升,怎么去解決?你要是連線程池都不清楚,你怎么去玩?再舉一例,由于對ThreadLocal理解出錯,使用它做線程安全的控制,導致沒能實現真的線程安全,你怪我哦?所以作為一個拿兩萬的JAVA程序員這點基礎是必須的。

    第二你需要有全面的互聯網技術相關知識。從底層說起,你起碼得深入了解mysql,redis,mongodb,nginx,tomcat,rpc,jms等方面的知識。你要問需要了解到什么程度,我可以給你說個大慨。首先對于MySQL,你要知道常見的參數設置,存儲引擎怎么去選擇,還需要了解常見的索引引擎,知道怎么去選擇。知道怎么去設計表,怎么優化sql,怎么根據執行計劃去調優。高級的你需要去做分庫分表的設計和優化,一般互聯網企業的數據庫都是讀寫分離,還會垂直與水平拆分,所以這個也有經驗的成分在里面。然后redis,mongodb都是需要了解原理,需要會調整參數的,而nginx和tomcat幾乎都是JAVA互聯網方面必配,其實很阿里的技術棧選擇有點關系。至于rpc相關的就多的去,必須各種網絡協議,序列化技術,SOA等等,你要有一個深入的理解?,F在應用比較廣的rpc框架,在國內就是dubbo了,可以自行搜索。至于jms相關的起碼得了解原理吧,一般情況下不是專門開發中間件系統和支撐系統的不需要了解太多細節,國內企業常用的主要是activeMQ和kafka。你能對我說的都研究的比較深入,阿里p6我覺得是沒問題的,當然這個還需要看你的架構能力方面的面試表現了。

    第三就是編程能力,編程思想,算法能力,架構能力的考量。首先2W程序員對算法的要求我覺得還是比較低,再高級也最多紅黑樹吧,但是排序和查詢的基本算法得會。編程思想是必須的,問你個AOP和IOC你起碼的清清楚楚,設計模式不說每種都用過,但是也能深入理解個十四五種。編程能力這個我覺得不好去評價,但是拿一個2000W用戶根據姓名年齡排序這種題目也能信手拈來。最后就是架構能力,這種不是說要你設計個多牛逼多高并發的系統,起碼讓你做一個秒殺系統,防重請求的設計能快速搞定而沒有坑吧。

    10. 從騰訊的職級系統 看清自己的職場宿命

    我2011年把公司全資賣給騰訊。2012年過完春節,編輯部的員工辭職一半。
      我就很想不通,現在變成了騰訊員工,運營騰訊旅游,聽上去很不錯,為什么要離開呢?
      于是和每個申請離職的小MM都交流了一下。
      之前我是創業,當然沒能力找很多熟手,基本上是大學應屆畢業生。到此時,大家畢業1年多。很此次提出離職,幾乎原因一致:“離開北京,回家鄉去?!?br />   小姑娘提的問題很現實:“我在這里,每個月租房子要1500,而且租在很遠的地方。每天眼睛一睜就去擠公交。晚上下班,再2個小時顛簸到住的地方,基本上一點力氣都沒有了。我的生活就是路上——上班——路上——睡覺。這樣幾年,我會成為一個什么樣的人?我能不能在北京呆下來?我會有什么樣的生活?”
      我一時啞然。
      然后問當時騰訊電商的HR老大劉琳。有沒有被問過類似的問題。
      劉琳吃驚地問:“啊?難道你第一次面對這個問題?我們可是10年累計花了1000多萬設計了一套系統,來解決這個問題啊?!?br />   這就是騰訊的職級系統??吹剿囊凰查g,我驚呆了。然后花了整整兩周的時間仔細學習,受益匪淺。

    騰訊的職級系統有26個職業通道,如果你是一個一張白紙只有素質沒有任何職業能力的畢業生,可以從這個26個通道,比如行政、財務、設計、運維、開發、運營、產品…….的任何一個1-1級開始,修煉,打怪升級,直到千萬年薪。如同一個完整的人生指引。
      橫軸是26個職業通道,專業技能各不相同,縱軸是4個大層級。
      以下是按照我的理解來寫了。(直接抄原文會被企鵝摔著打的)。
      我覺得騰訊的職業四大層級,幾乎就是人生發展的四大層級。
      第一層是動作執行層、第二層是任務執行層、第三層是戰略管理層、第四層是戰略決策層。
      先說動作執行層。一個企業最多的就是這個層面的員工?;蛘呙總€人初入職場,都是從練好一個動作開始。比如,畫原型,寫代碼,寫稿子……
      而騰訊對動作執行層的要求是:按照品質要求,完成動作、優化效率。注意,沒有品質要求的動作,毫無意義。用戶體驗的不是產品而是品質感。就像你去一個川餐館吃魚香肉絲,你感受到的是這家魚香肉絲的品質。大廚的工作不單是保證把菜炒出來,更是要保證菜品在一個什么樣的品質感里。所以麥當勞的桌子永遠擦的干凈,同樣的人在另外一個餐館未必達到這種清潔標準。因為麥當勞不是要求把桌子擦了,而是清晰地要求達到什么樣的清潔品質。
      達成品質要求之后,在談完成動作與優化效率。
      任務執行層。就是要把分配的任務及指標,拆解成動作。由不同人組合完成,或者一個團隊次序完成。需要在整個過程中,控制人心,安排動作序列,并配置風險,保證完成任務,達成指標。幾乎所有鐵血創業者都是從這個層級冒出來的。
      戰略管理層。就是大家永遠不理解的那批副總。帶兄弟痛快淋漓干活的都是總監。而副總,心累。他們需要根據戰略決策,確定任務優先級,配置資源,鼓舞士氣。保證戰略方向不偏差。
      而最高的戰略決策層,幾乎就是個CEO的活。他需要有前瞻,推動相關資源方做出戰略決策,并且獲取戰略資源。就像亮劍里的李云龍。在除了自己,什么都沒有的情況,他可以溝通,說服。一個隊伍打沒了,馬上再拉起一個隊伍。只要他還要打下去。
      四個層級的核心工作不同,對人的特性的核心需求也不同
      在動作執行層,才氣很重要。
      在任務執行層,責任心,執行力的價值,遠大于才氣。甚至需要放棄自己的才氣,把時間交給眾多的兄弟,才能實現任務的完成。
      而一個人能否達到戰略管理層,核心要考核的是:心力。心力是什么?就是無止無盡操心的能力。資源永遠有限,戰略常常在變,兄弟都是親的,永遠沒人滿意。所以,一堆人拉我去當副總,我都謝謝了。因為自己清楚,心力真心不足啊~
      戰略決策層。愿力。其實我在《決策》那篇文章中談過愿力的問題。沒有愿景支撐的決策都是機會主義。一個人如果心中沒有愿,那真是誰都幫不了他??瓷先ピ俅蠖际羌埨匣?。
      所以,人會在哪個層級呆著,度過一生,其實都是因為吃不了其他層級的苦。其實發展個人才氣,在動作層呆著,是人生最舒適的選擇。
      不過那些以才子自居的人,創業往往格外困難,因為在整個創業的戰略確定到達成的過程里,最不值錢的,也就是才氣。
      又:
      進入騰訊一年后,我和Free吳宵光吃飯,很認真地敬酒感謝他。這一年在騰訊學了很多東西。Free還反問我,是嘛,學到啥啦?我說我寫篇學習心得交給你吧。2年后,還是交作業了。當然學到很多不止這些。。
      騰訊還是一家非常強大的企業。動作人員動作到位,品質嚴格,沒有任何偷懶取巧。任務負責人有高度集體榮譽感,連年會表演個節目都全情投入。中高層干部心力充足,能每天從早6:00到晚1:00持續無至盡地操心。所以,那些要挑戰騰訊的企業,只要看一眼動作人員的動作到位度,和高管的心力,就可以自我掂量了。

    11. 中國式管理_最適合我們中國人自己的管理方式!

    ● 管理是修己安人的歷程
    ● 搞清楚推、拖、拉的真正用意,合理應用以求圓通
    ● 以化解代替解決,務求盡量減少后遺癥
    ● 寓人治于法治,更符合中國社會的實際情況
    ● 做人做事兼顧并重,透過好好做人來把事情做好
    ● 抱持既不贊成也不反對的心態來包容一切
    ● 發展事業本身并沒有什么目的,必須在經營事業的過程中,完成修、齊、治、平的人生使命,立業才有價值。
    ● 計劃的目的,在肯定今后幾年,如何安人?
    ● 組織的功能,在聚合安人的力量,協同一致。
    ● 領導的意義,在發揮安人的潛力。
    ●控制的用意,在保證今后幾年如何安人。
    ● 所有管理措施,無一不與安人密切相關。
    ● 只有組織成員各守其分,大家才能和合為一,產生強大組織力。
    ● 安人就是把部分和在一起,合成一個整體,并且促使整體大于部分,和透過已安和人安增進和諧的效果。
    ● 安人的歷程,是由開心而交心,藉交心而共同關心,然后產生同心的一連串心與心的變化。
    ● 中國人擅長把二看成三,以二合一來代替二選一。
    ● 以不變應萬變是管理的最高智慧,不要因誤解而放棄。
    ● 持經達變是最有效的管理方式,有原則,卻必須因人、因時、因事、因地而應變,以求制宜。
    ● 經是方的,規規矩矩,實實在在。權是變動的意思,要持經達權,合理應變,才能圓通而安人。
    ● 美國式管理的哲學基礎是個人主義,日本式管理的哲學基礎是集體主義,中國式管理則是我們常用的交互主義。
    ● 日本人拿中國的管理哲學,來運用西方的管理科學。
    ● 中國式管理具有三大主軸,那就是以人為主,因道結合,以及依理應變。
    ● 中國人相信事在人為,所有的事都是人做出來的,所以管理應該以人為主。
    ● 若非理念相同,很不容易做到以人為主而又能夠密切配合,把工作做好。中國式管理首重道不同,不相為謀,力求因道結合,彼此志同道合,理念相同,更中能夠同心協力。
    ● 志同道合的同仁,由于人心善變,不久之后,可能變成志不同,道不合。各種內外環境的變數,更是隨時出現。中國式管理主張依理應變,凡事依據原則,則因人、因事、因時、因地而應變,以求合理。
    ● 只要合理,怎樣變動都可以。
    ● 中國式管理,重視把人際或人群和倫理合在一起,建立一種差別性的關系,稱為人倫關系。
    ● 中國式管理的交互主義,秉持二合一的態度,將個人主義和集體主義這兩種極端的說法,合在一起,形成在集體中完成個人的合理主義。
    ● 人倫關系,便是以倫理的觀點來建立合理的人際關系。
    ● 對上要有禮貌,但是不能夠討好。以下不宜太嚴,也不能夠過份寬松。平行同事不必太拘束,也不應該過份熟不拘禮。
    ● 大同必須包容小異,世界大同并非世界一同。
    ● 凡事未定案之前,十分民主,一旦拍板定案,相當獨裁。這種把民主和獨裁合起來想,稱為專制。
    ● 法是過去的產物,情是未來的埋伏,只有理才是現在的指標,中國式管理主張依理應變,按照現在的情勢做出合理的調整。
    ● 中國式管理重視樹狀的組織精神,根部吸收水份,源源不斷供應樹干;樹干也毫不保留地讓枝葉予取予求。這種我支持你,你放手去做的精神,符合中國人你辦事,我放心的心理需求。
    ● 上侵下職,妨害員工的學習、成長,更破壞上司與部屬之間的合理關系。
    ● 決策者的大智,指具有相當的專業知識,大慧指有智慧也有德行,三者合一,才是大智大慧做決策。
    ● 決策以止定靜安慮得為過程。
    ● 至誠可以前知,預測未來才能做好計劃。
    ● 采取無為的執行過程,才能大有為。
    ● 全面無型的控制,把法律和良心合在一起。
    ● 考核的標準是錯不可以而對并沒有用。
    ● 抱持救人而非殺人的心態來考核。
    ● 溝通以不明言為基礎。
    ● 有效地會而不議,議而不決、決而不行。
    ● 領導比管理更重要。
    ● 老板做好人,干部做壞人,才是良好的配合
    ● 勸合不勸分,表示站在合理的立場來分。
    ● 用情理法來領導,最為合理。
    ● 有本事來拿,拿不到怪自己,是激勵的基本原則。
    ● 先求忠誠再求能力,更加安全。

    12. 學習top100站點

    名稱(站點名或人名) 國家 備注
    1 Adam Bien 德國 Java EE相關
    2 Antonio Goncalves 法國 Java EE相關(《Java EE 5》和《Java EE 7》的作者)
    3 Henrik Warne 瑞典 編程過程中的一些思考
    4 Billy Yarosh 美國 Java日常開發中的實用代碼示例
    5 Lars Vogel 德國 Java、Android 和Eclipse
    6 Peter Verhas 匈牙利 純粹的Java
    7 Martin Fowler 美國 面向對象設計專家和咨詢師
    8 Bozhidar Bozhanov 保加利亞 Java EE相關
    9 Richard Warburton 英國 Java 8 Lambdas
    10 Bear Giles 美國 Java EE相關
    11 Marginally Interesting 德國 機器學習
    12 Pascal Alma 美國 Java EE相關
    13 Dror Helper 美國 代碼測試和代碼質量
    14 Juri Strumpflohner 意大利 JavaScript
    15 Reza Rahman 美國 Java EE/Glassfish
    16 Phil Whelan 加拿大 Web技術
    17 Brett Porter 澳大利亞 Apache Maven 2的作者
    18 Ben McCann 美國 一些實用的操作指南(Connectifier的聯合創始人)
    19 Java Posse 美國 Java相關的一些有用的鏈接
    20 Mark Needham 英國 數據處理
    21 Iris Shoor 以色列 調試技術、性能等
    22 Yifan Peng 美國 Java開發、算法與數據結構等(一個本科畢業生的博客)
    23 Nikita Salnikov Tarnovski 愛沙尼亞 內存泄露
    24 Dustin Marx 美國 一些通用的開發技術以及Java、 JavaFX、Groovy等相關技術
    25 Bart Bakker 荷蘭 敏捷開發
    26 Gunnar Peipman 美國 非Java(C#、.Net相關)
    27 Dave Fecak 美國 程序員需要知道的工作技巧
    28 JOOQ 瑞士 SQL
    29 Petri Kainulainen 芬蘭 Web技術
    30 Informatech CR 哥斯達黎加 Java、Web、Mobile開發
    31 Arun Gupta 美國 Java EE
    32 Mechanical Sympathy 英國 性能(鎖、垃圾回收、編譯優化等)
    33 Extreme Enthusiasm 意大利 敏捷開發
    34 Steve Blank 美國 The Startup Owner’s Manual(創業者指南)的作者
    35 Oliver Gierke 德國 SpringSource(現為VMware旗下部門,提供Java企業應用開發平臺)
    36 Nicolas Fr?nkel 瑞士 Java EE
    37 Blaise Doughan 美國 XML和JSON相關
    38 Vlad Mihalcea 羅馬尼亞 軟件集成
    39 Kevin Lee 澳大利亞 Web技術
    40 Mikhail Vorontsov 澳大利亞 性能(語言本身的性能研究)
    41 Jakob Jenkov 丹麥 Java基礎
    42 Program Creek 美國 深入理解Java

    • 1
      點贊
    • 2
      評論
    • 4
      收藏
    • 一鍵三連
      一鍵三連
    • 掃一掃,分享海報

    ??2020 CSDN 皮膚主題: 大白 設計師:CSDN官方博客 返回首頁
    實付
    使用余額支付
    點擊重新獲取
    掃碼支付
    錢包余額 0

    抵扣說明:

    1.余額是錢包充值的虛擬貨幣,按照1:1的比例進行支付金額的抵扣。
    2.余額無法直接購買下載,可以購買VIP、C幣套餐、付費專欄及課程。

    余額充值
    多乐彩