在我的職業生涯過程中，發現很多人會跑來問我這樣的問題，前端能做什麼？這條路怎麼走。然後他們會分開來問一些子問題，例如說到底我進入了前端我應該做產品呢？我應該做基礎架構呢？還是應該做產品基礎架構呢？可能有些公司不存在產品基礎架構這樣的概念，通常來說的定義就是在於產品和基礎架構之間。有點像是做一些框架、AB測試平臺，測試工具等等的方案。其實一個更好的問題應該是問到底我想服務於什麼樣的客戶？因為想要服務於什麼樣的客戶才是真正決定了你要做什麼？
【產品】
如果你選擇做產品，服務於外部的一些使用者。
首先，你需要找到一個讓你覺得非常非常想要解決的使用者問題，因為這才是你核心驅動力的出發點，你要先解決一個使用者的問題。
例如：
我作為使用者，每天用到這個東西不爽，我就是不爽，我決定用我的程式設計能力去解決這個問題，然後你才會有足夠的動力把這個事情做得非常非常的完美。如果這是老闆讓你做的這個東西，老闆叫你做這個功能，那可能你覺得我也是對這個功能存在的意義是一知半解的，那你就沒有實足的動力去把它做好。
那這個對你長遠的職業生涯有什麼影響呢？你去解決使用者問題的話，那麼你的機會是存在於大大小小不同規模公司裡面，因為有不同規模的公司都在嘗試解決使用者問題，所以你將來的就業機會就會相當的廣闊。
【基礎架構】
如果你選擇去做基礎架構，你服務的人群就是其他的工程師，那麼這往往意味著你希望解決一個其他工程師的問題，或者說是一個工程性的問題，而且是希望解決的手段是提供一個可擴充套件的服務，你的客戶往往就是公司內的其他工程師。
那這樣帶來的好處：
第一點是 ：你可能會對他們有更好的同理心，你能知道我在這家公司內，我以前是做產品的，我就覺得這個儲存服務很糟糕，一點都不好用，API設計完全不合理。我就知道這個CDN一點都不好用，我要去做個CDN我就不這樣做。然後你就衝上去他把解決了。而且你能夠很好的知道你自己想要什麼，因為你原本就是自己的客戶；
第二點是: 一個更方便能夠跟自己客戶溝通的渠道，因為你的客戶就是可能坐在你幾張桌椅外、或者幾棟樓以外的一個別的工程師，所以你想知道說這個東西好用嗎？你不需要做使用者調研，你不需要上線做AB測試，你直接跑過去問就可以了。比如說這是一個demo，你跑過去問一下，喜歡嗎？這個API你會用嗎？一看就明白嗎？不明白是吧？那顯然是我的鍋，那我回去在改，對吧？
然而問題來了：
如果你是做基礎架構，那顯然不是任何大公司，小公司都能夠支付得起做基礎架構的成本，所以你的就業範圍往往就被受限在一些某個規模以上的公司裡面.
因為只有這些大規模的公司他才想到說，我需要做自己的基礎架構，然後來服務於我自己的內部的其他的產品，但也有少數公司是自己做雲平臺的，那他可以說我做這個東西服務於我的內部的工程師還服務於我的其他商業客戶。但小規模一點的公司，非常罕見。也不是絕對沒有，有些創業公司是做雲平臺服務的，但比大公司要罕見得多。也比解決使用者問題的產品公司要罕見得多。
如果你是做產品基礎架構的話，你就站在兩者之間了，往往也是說有一個工程性的問題你想解決，但解決的手段不是你提供一個可擴充套件的服務、可伸縮的服務，而是一個可複用的框架，例如React和React Native這樣的例子，那麼你的核心客戶是誰？其實本質上還是你公司內部的其他工程師。
【開源】
如果你做開源的話，可能會有外部的其他的客戶，然而這是有一個巨大的條件作為前提。
第一，你開源的東西能夠影響公司在整個行業裡的影響力和名聲，讓公司的名聲變得更好；
第二，可能它能幫助到公司吸引人才，讓其他應聘者說：“我喜歡這家公司，我之所以申請來面試，是因為你們開源了這個，是一個非常偉大的事情，我對你們公司非常向往”。
沒有這兩點的話，其實你想在一家公司做開源，是不太可能的。你要想想，還是回到那個問題，你的客戶是誰？如果你的客戶只是說是外部的工程師，開源社群的受益者，那誰來為你的工作買單。顯然不是你的經理，顯然不是你的Team Lead，顯然也不是你的公司，因為他們得不到直接好處的話，是不會為這樣的事情買單的。
一家公司如果允許你一直做開源，這開源都對公司內部其他團隊一點貢獻都沒有，那結果就是要麼公司解散這個團隊，要麼公司自己解散掉，因為你在做一些不符合經濟規律的事情。
那跟做基礎架構一樣，你所能選擇的就業範圍是會受到一定的限制，因為只有在有一定規模以上的公司才會願意支付代價來做這種專案。當然你也可以說：“我選擇離開，我做一個純粹的開源開發者，我做自由職業，我上Pinterest上面去賺錢”。這也是另外一條路。但是你選擇在一家大公司裡面就業，那可能更多的就是一家有一定規模的公司，而不是一家小公司。
當然，所有的這些選項都沒有一個很清晰的界限。界限是模糊的，所以也沒有任何選擇是絕對的。
總結一下
你想要解決的是什麼人的問題？你覺得是終端使用者的問題？這很簡單，去做產品。因為那才是讓你興奮，讓你每天白天想要做，晚上想要解決問題，不停想著，洗澡的時候也要想著這樣的問題，但是如果你說，我想要解決的是一個工程性的問題，或者其他工程師也在感受的問題，哪你要想想，你的解決方案到底是一個可伸縮的服務呢？還是一個可複用的框架？這決定了，你到底是去做一些基礎架構的事情，還是去做一些產品基礎架構。
還有一個常見的問題：應該做前端呢？後端呢？還是全棧？
你應該問一下，到底哪一樣能夠讓你更加努力工作，就是做什麼事情能夠讓你更興奮，不管怎麼樣，我也要做，就算老闆不發工資給你做，你也要做，為什麼這樣說？
因為這個選擇只對你的職業生涯的前若干年產生有意義的影響，到了你的職業生涯的後期，所有東西都會收斂到一起，也就是說你不可能你只懂前端，也不可能只懂後端。
當你成為一個技術大牛，或者技術總監，VP這樣的角色的時候，你必須對下面子問題都有所瞭解，你知道問題怎麼樣分解，你知道這個問題分解下去之後需要有多大的成本解決、風險有多大、有多少的可能最終這個問題是解決不出來的，或者解決得不完美的。
到了那個時候，其實你選擇前端，後端，還是全棧這已經不是一個關鍵點了，你都需要要懂。所以唯一的問題就是說，什麼東西能夠讓你的職業生涯的前幾年儘可能的加速，要加速，其實事情還是在於你人本身，什麼事情，什麼樣的問題能夠讓你這個人真的非常非常感興趣，願意加班加點也要去做，老闆不發錢也要去做，所以我的唯一的建議，就是選擇對你頭幾年發力最有幫助的一個興趣點出發，然後把事情做好。然後之後就不在是一個問題。
程式設計師職業生涯的劃分方式
假如你的程式設計能力被轉換成為你開車駕駛經驗，來進行劃分：
【六個階段】
第1個階段
一個學生這樣的階段，那麼很多時候第一關鍵點並不是程式設計或者開車，第一個關鍵是明確你自己喜不喜歡駕駛的體驗，你不喜歡，你幹嘛去考個牌呢？你叫車就好啦。世界上不是說你必須要去考個牌的。
那麼如果你發現你喜歡駕駛體驗，而並不是為了家裡要抽個籤買輛車這樣的原因，那我享受這個體驗，就算我只是去學車，練習我也享受這中間的過程，當然作為學生，也有一些不哪麼好的地方，你開車不是安全的，所以只能在一個可控的範圍內開，不能把你放在馬路上開，把你放在馬路上開，你會危急其他人。
第2個階段
通過所有的考試，領到牌照之後，那證明你可以自己開了。所以，你可以說，我很享受我自己開車的大部分的時間，我在路上開，我都是心情愉悅的。然後呢，有時候你還是會犯一些很傻的的錯誤，例如說，不該轉的時候轉啦，左轉的時候轉到錯誤的隔離帶哪一側之類的，在所難免總是會發生。然後有時候，會有一些更有經驗的老司機給你一些技巧，告訴你怎麼樣開車更好、怎樣保養你的車更好。
第3個階段
變成老司機了，那麼你就可能會有一個安全駕駛的歷史記錄，你看，我多少年沒有出過事故，3年，5年，然後給我一個GPS，我能跟著走，去哪裡，一天之內的，GPS說得出來，我一定能去到。中間去加個油，去個洗手間什麼的不在話下，不需要人告訴我，我是一個成年人，我該去哪兒，我自然能去到。然後呢，當然老司機也有一個小問題，很容易被路上其他新手冒犯到。覺得這個人怎麼這樣開車，這樣的車技也能上來呀？這牌照到底是買來的？還是垃圾筒撿來的？就會有這樣的疑問。
第4階段
成為一個好像計程車司機或是快遞員這樣的，到了這個階段，基本上我列出來的點不在討論你的駕駛技術了，因為這個階段來說，你要非常準點和可靠的A點開到B點，這對於計程車司機來說是一樣的，對於快遞員來說也是一樣的。就是你有一個從A點到B點的需求，駕駛技術不在是你的目的，他只是你的手段，你的目的是A點到B點。駕駛只是手段之一，然後B點有可能是一天能到的，但是也可能你要跑個長途，拉個貨，那麼可能是幾天之外的距離，你怎麼走？行程怎麼規劃？每天晚上睡哪裡？這是你自己想明白的事情。然後有時候，你在路上開著開著，發現出事情了。
舉個例子
有人決定，我們要來廣州參加這個會議，北京過來，不搭飛機，我決定開三天的車過來，開著開著，開到杭州，遇到颱風，開不過來了，怎麼辦？這時候你自己要想辦法找路走，繞開臺風，還是如時到達，到不了，你就錯過了這個會議了，哪這個你不能怪別人，只能怪自己，你去怪颱風沒有意義的，因為你不能說，因為颱風出現了，所以我來不了了，所以你要賠償我，颱風不會賠償你，你需要做的就是非常準時可靠的從A點去到B點。
第5階段
你會成一個安排更多司機一起協同去某個地方的的角色，例如說，我們組個青藏自駕遊，哪現在誰有興趣一起去？有可能沒有人願意一起去，覺得這個太無聊了，有什麼好去的? 又有人覺得這個太危險了，不去。那你要一個一個的說服別人，你看我們認識，其實這個目的地很好玩的，去到有很多很新奇的事情，我們可以看到的，在這個大城市看不到的，哪你要讓大覺得非常Exciting，這個目的地我想去。然後你在去組織說，你要去這個目的地需要什麼資源呢？是找個贊助商呢，來贊助你這次的行程，然後你幫他打打廣告，還是自己掏錢去呢？這些都是你要能解決的問題。解決完之後，才決定大家怎麼從A點到B點。這時候，從A點到B點的過程就越來越自由了，有可能有些人說我們開過去，有些人說我們要去目的地提前準備，你們過來就是紮營的，人家就提前飛過去了，這都不重要。重要的是，你的整個行程要安排好。要從A點到一個很遙遠的B點。
第6個階段
就是一個探險隊，這就不能用現場的這種自駕的方式來比喻了，要回去想想，好像說，回到哥倫布發現新大陸的年代，哥倫布憑什麼說服皇室說，來贊助一下我，出點錢，好讓我有船，有人去找新大陸，這個事情是要想辦法的，不是別人無端端會給你的。然後去哪裡招來的船員，哪裡招來的水手，哪裡弄來的船，所有這些東西你都要規劃好，然後你才有一支探險隊，然後這支團隊才會在你的領導下出發去尋找你想要尋找的東西。
用程式設計師的話說，你會發現很簡單，很多東西都是一一對應的。
第1階段，你作為一個剛剛學習程式設計的人，最重要的是，搞清楚你想不想程式設計呀，享受程式設計的話，那你自然會覺得寫程式碼很有樂趣，但是我們也知道，你的程式碼會有很多的bug，你需要有很很多的除錯，就跟一個新司機在路上，不是那麼安全一樣，如果你的code如果能夠進生產環境，生產環境有相當的概率會倒掉。
第2個階段，你成為新司機之後，你會說OK，我是享受程式設計的，我有一定的程式設計理念和方法了，我能自己做，但是偶爾還會犯一些小錯誤，那麼你要想辦法自己去學習和修復，然後就開始從老司機那裡學習經驗，人家說這個IDE這樣配置比較好，可以讓你的生產效率會更高，你就學著做，這樣子寫程式碼，能夠更好的避免常見的錯誤，避免以後程式碼修改的時候引入不必要的影響，降低你犯錯誤的風險，可能你就照著做了。
第3個階段，你進入老司機的階段，你可能同樣有很好的歷史經驗，你看我成功的釋出了這麼多新產品的特性，他們都能夠得到很好的結果，這些特性發布的時候沒有產生bug。然後寫的程式碼，都是很容易閱讀和很容易維護的，然後可以跟隨著一個有效的專案安排，來完成一些專案。就是說，這個功能現在要做，2個月，1個月，你去做吧。可能不需要太多的幫助。PM說這個東西2個月做完，那我就有計劃的按步就般的就把這個東西1-2個月做完就可以了。2個月就說，QA過了，所有都過了，簽字吧，上線，不需要額外的幫助。當然，類似的我們可能會覺得來了一個新手，這個人寫程式碼，怎麼這麼爛呢？然後Code Review實施都不過，每次都Reject，你這樣寫程式碼不行，你哪樣寫不行，回去重寫。 這時候通常有經驗的程式設計師，可以嘗試慢慢的改變一下自己的態度，去更好的花時間去培養新人，去讓他們瞭解怎麼樣能夠增強他們的編碼能力，他們避免犯錯的能力，然後其實這對於自己也是一個提升。
第4個階段，你作為一個計程車司機了，程式設計技術由目的變成了手段，你的目的是什麼？你的目的是商業結果，你需要對商業結果負責任，商業需要從A點去到B點，可能是說月活要漲個5%，可能會說客戶端應用崩潰率要減半，這些都是商業目的的結果，那你存在的意義就是對商業目的結果負責任。同時說是說，商業結果可能不僅僅是1-2個月之外啦，是3-6月之外啦，可以說月活在半年之後要增加20%，留存率不變，這就是我們需要的商業結果。
至於怎麼樣做得到這個月活如此增長呢？這6個月你自己想辦法想明白。沒有人需要很明確的告訴你，做什麼產品，幫什麼新特效能夠提高月活，但是你需要去自己想辦法分析使用者資料，找出來一個門道，然後把月活搞上去。這個時候你需要想辦法，把這個工作切分下來，確認你每個月每天做什麼，有時候就如同我剛剛舉的例子，你從北京開車來廣州，開著開著去到杭州了，發現颱風你過不來，哪你需要有你的B計劃，就好像你做月活，我們假設做這個優化，自然月活就上去，做著做著發現，這個東西做不下去了，我們市場可能變了，政府監管可能變了，競爭對手可能有新的產品釋出了，導致這方面的改良計劃不在有效了。你就要去想辦法應對，提出新的辦法來繞過去，然後同時還是達到你原來的月活既定目標。
第5階段，然後這時候就不是你一個人對一個商業的目標負責任了，而是你希望來帶領一個團隊，來完全一個更大的商業結果。哪麼這時候你需要聚集一群人，說我們一起從這個地方到哪個地方去，目的地還是一個商業結果，哪麼你需要讓所有人都感覺到OK，我確實是想要去哪個地方。就能夠協同一起努力來達到你想去到的商業目的。
這個商業目標有可能是一年以後，也有可能也是含糊不清的，含糊不清的意思是可能說我要達到商業目標是使用者更加享受我們的應用工具，如何定義使用者更加享受使用我們的工具，這是一個很含糊的目標，你首先要提出來用何種方法來測量，然後測量得到結果，你要如何提升，提升到什麼程度，你才能說你達到到你的目標，你的客戶更享受你的工具，這一切都是你要解決的，這跟你帶領一個自駕遊的車隊一樣，你先要說清楚，你要去哪裡。然後讓大家都覺得哪是一個可達的目的地，都願意付出自己的努力，去到哪個目的地，然後你才能啟程。
第6階段，來到一個探險隊的模式，那就會更加難了，就是可能存在一個非常非常振奮的結果，就好像你說：我現在要開創一家公司，這家公司要解決一個現在沒有任何一個大公司小公司解決的這個新問題，這個問題就我看到了，其他人都沒有看到，你會說，這個商業目標能隱藏在一個難以觸及的商業領域，因為往往只有這麼巨大的商業目標隱藏在某個領域裡面，才會存在這樣的商業機會。你要做的事情，其實說起來很簡單，但是需要的技能很複雜。說起來簡單，你就是需要聚集一群人，讓他們都能夠跟你一起找這個東西，但這時候跟上一階段不一樣的是，你甚至你不能很好的說清楚B點在哪裡，B點就好像說隱藏在一個山中的寶藏，隱藏在無人區的寶藏，你不知道這個寶藏在哪裡，你只能去，然後你要想出一個系統的方法，去把它找出來，哪這麼大一塊地，寶藏到底埋藏在哪裡呢？你是用什麼方法來去掃描寶藏，如何系統性的劃分這個寶藏埋藏的區域，使得你有儘可能的高的概率能夠找到寶藏呢？哪這是你需要解決的問題，哪同樣，你說，我現在要做一個新產品，你怎麼知道你現在開一家新公司做一個新產品你這個產品的市場在哪裡，沒有人知道，這就跟尋找一個埋藏在某處的寶藏一樣，你需要很多嘗試的過程，你才能找到。我現在解決一個新的使用者的問題，解決到這個階段，我覺得我是足夠了解我的使用者，我知道我的使用者在哪裡，我的使用者也知道我的存在，哪我可以慢慢慢慢的做使用者的增長，讓更多的使用者來用。因為我找到了使用者存在的Pattern。
接下來我們講講，既然我們如此劃分了，在這些階段裡面我們需要學習什麼樣的技能？進入這個環節之中呢，就我可以說一下，很多時候大家之所以要討論技能，我也發現很多喜歡問這樣的問題，第一就是我是應該更加多的關注技術，還是業務？然後也有人會提問說，我在學習的過程中，如何在技術和軟技能之間做出平衡？
要看你現在處於哪個階段？要看你要看你對什麼事情更感興趣？而且還要看，你實際上要達成的目的是什麼？
對於第一個階段來說，首先我要看的是你要達成的目的是什麼？
你開始學寫程式碼，你有點印象，有點感覺，說我寫程式碼是一個愉悅的事情，哪這時候你的目的很明確，你要寫很多很多的程式碼，作為一個練習的過程，然後同時就是說想要有一個很低成本的配置環境，來減少寫程式碼之外的開銷，不要說我不會使用Linux，所以我要硬著要用Linux，所以怎麼樣，怎麼樣。我學習這個命令列花了半年的時間，這半年終於把我的Vim設定好了，或者我的Emacs設定好了，這才開始寫程式碼，這浪費時間。基於這樣的目的，你要學習什麼樣的技能。
第一就是說，你要在一門語言內要非常非常的affection，能夠把哪門語言用好，然後對於前端工程師來說，哪意味著，學一些非常基本的HTML、CSS、JavaScript，不需要很精通，至少要到一定的程度。然而你學這門語言不一定是前端的語言，這門語言只是你迅速起步的手腳架而以，熟悉了任何一門語言，對你之後的發展學習其他語言都有幫助，然後最後就是說熟悉一門開發環境的配置，比如說迅速能上手的IDE, 一些很基本的Linux的命令，然後可能一些git的命令使得你要去下載一些網路上的repo，你可以下載呀。
經歷了這個階段之後，你就進入了第一個階段，就好像一個新手一樣，這時候呢？你的目標是什麼？你的目標是你可以寫程式碼，你可以寫很多程式碼，但下一步的目標是你要寫高質量的程式碼，同時你希望從其他人身上學習，不要忘了，這個過程是一個老司機指點你的最佳的過程，哪麼，要達成這樣的目的，第一，你需要開始採用一些流程和工具來讓你的程式碼質量越來越好，然後可能說你引入一些coding style，我的程式碼風格是這樣的，可以讓我的程式碼更容易閱讀，更容易維護，我引入測試，包括單元測試，整合測試等等，來使我寫出的程式碼是健壯的，我將來自己維護也好，有人幫我維護也好，都是很容易維護的。
另外一方面是非技術性的，要學會提問題，這是非常非常重要的。對於這個階段來說，第一，是非常基本的，讓自己能夠感覺到舒服的向別人提問題，這很奇怪，為什麼要列在前面？其實觀察這個階段的很多程式設計師，大家會害羞，覺得我問這個問題是不是太蠢了，或者我問這個問題，會不會讓大牛覺得我非常的膚淺，這麼簡單的東西都不明白，他就不想理我了，你需要跨越這樣的心理障礙階段，能夠很舒服的提出問題。
第二點是說，在什麼都問，什麼都伸手黨 和 什麼都自己都研究不敢提問之間做一個很好的權衡，一方面你既不能伸身黨，什麼都想都不想，自己沒有做過任何研究就去問，但另外一個方面，你也不能說這個東西我研究了一個星期，還是一點動靜都沒有我才去問吧，相當於浪費了一個星期的時間，所以你要找到一個平衡點，比如這個東西搞了1-2小時，毫無進展，哪速度為0對任意多的時間的積分產生的距離還是0？所以沒有意義的，如果你發現你的速度為0,接近為0，搞了一段時間之後，你是時候去問人了。別人幫助你，使你速度從0變成一個有意義的小數了，你可以慢慢的越走越快，越走越快，但速度是0，是一個最艱辛的階段。你需要獲得幫助。
然後，最後就是如何提好的問題，不要直接提你眼見到的一個很精準的很小的問題，或者很技術性的問題。要提供更多的上下文，我為什麼要解決這個問題，是因為我要解決一個更大的問題，為什麼我要解決一個更大的問題呢？是因為我有一個更大的商業問題需要解決。哪可能別人會告訴你，其實你不需要解決這個小問題，因為你的大問題的解決方案就是錯的。首先你要把你的大問題的解決方案改掉，你這個小問題就絕對繞過去了，不存在了。
第二個階段 ，到了一個老司機的階段了，這時候你的你的目標是什麼？設計和維護高質量的系統，然後有一定自己在程式設計方面獨立自理的能力，自己能夠搞掂自己，不需要太多的依賴於別人，除了一些非常難的問題，更多的時候，你交給我一個技術性的問題，我自己可以研究出結果來，我不需要靠問。
下一點，就是開始去對其他的更Junior的程式設計師提供一些指導性的建議，怎麼樣達成這個目標，第一點，你需要學習一些與系統設計相關的東西，系統設計說起來好像很複雜很複雜的樣子，前端，後端，大規模系統，分散式系統，但核心是什麼？但是核心就是說，你要分析Tradeoff 是什麼？任何東西都不可能做到完美，當一個複雜到一定程度的系統，完美是不可能存在的。更多的是說Tradeoff在哪裡？你在這裡Tradeoff權衡之間如何做出選擇，有了這些關鍵能力，你在去應用他來應付不同的技術框架。
然後，第二就是說，對於當下流行的技術要有一定的瞭解，不需要非常深，你需要知道說，我做一個系統設計我依賴於這項技術和依賴於哪項技術之間產生什麼樣的差距，我到底應該用React來寫呢？還是這個東西實在是太少了，連React的體積都不值得，我自己就呼叫DOM API 就寫完啦，這是你需要想的，Tradeoff是什麼？ 想明白。但你也要懂一點現代技術有什麼？React是存在的，我有React這個選擇，我也可以跑回去用jQuery，是不是jQuery寫這麼簡單的東西比React更快。
第二項重要的能力是什麼？是高效的debug的能力。因為你開始遇到越來越複雜的技術問題了，很多技術問題的難點在於你要debug，尤其是你作為一個有幾年工作經驗的，在公司裡面，通常你有合理的概率你會接手到一個難維護的系統，如果你沒有這方面的能力，扔一個開發了3-5年的遺留系統給你，你會發現你hold不住，那這時候怎麼辦呢？沒辦法，這方面，第一就是，你要覺得我可以接手一些有一定體量的遺留系統，我有膽量去接，而不是說，這個東西有這麼多遺留程式碼，有些是三年前寫的，有一些是五年前寫的，完全看不明白，看得明白第一行，看不明白第一個檔案做什麼，哪這時候就不行了，因為這是你的工作需要，你要覺得這樣OK，我可以接這樣的活。
接下來就是說，你要懂得使用二分的方法來找到你要debug的東西在哪裡，哪麼對於前端程式設計師來說，很重要就是要學會靈活的運用Chrome的DevTools，或者其他瀏覽器裡面同樣的除錯工具，因為你做前端，其實說起來就是二分查詢除錯有意義，但是你還是需要有一個非常順手的工具，你才能做完理論上的二分查詢。哪最後就是你還要懂一點伺服器端的除錯，如果伺服器返回一個JSON給我，這是一個非法的JSON，它根本就不能pass,這樣就不管了，Bye-bye，這是不行的，你要去找出伺服器為什麼給你返回一個非法的JSON，然後你要把問題解決掉，否則的話，你還是做不成你想要做的事情。
最後一點
就是你需要去指導一下比你資歷沒有這樣深的程式設計師，第一就是說，你需要包容其他人瞎搞，你要有能力去包容其他人瞎搞，因為每個人成長過程都是這樣的，需要經歷過一些迷茫，出錯的過程，如果你說，你這個人進來，看我做事情的方法很牛逼，你一定要按照我很牛逼的方法做，這是不行的。你團隊中的新人很快會覺得說，頭三個月會覺得這個人超牛逼，我問的什麼問題，他都能解答清楚，這個遺留系統這麼龐大，完全看不明白，吃不進去，問任何一個領域的小問題他都能夠解答清楚，但有一個問題，這個牛人一定要讓按照他指定的方法解決問題，那麼可能三個月之後，這個年輕人就走了，他覺得說沒有意思，這個牛人是很利害，他能回答所有的問題，但是我每次寫出來的程式碼，他Code Review的時候，就直接要我改，說我寫的方法和跟他想要的方法不一樣，改著改著，我就覺得不耐煩了，我不想幹了，因為學習的過程就是通過瞎搞胡弄慢慢慢慢搞明白什麼是正確的方法，別人抓著你的手，一定要按照他要的路去做，這是不行的，所以作為一個有經驗的程式設計師，別人要瞎搞可以，我想清楚，你到底要怎麼樣瞎搞，對商業會不會有很明顯的負面影響，是不是有可控的負面影響，如果對負面可控，去瞎搞。我要允許你實驗，這才是你正確的成長過程。
下一步就是分享你的經驗和知識，應該很簡單，很多人都會，有一定的經驗之後，就會做技術分享。
下一階段就是說像計程車司機這樣，第一，你要明白B點在哪裡？對於前面幾個階段的人來說，請問我們團隊什麼樣才叫成功？這些人通常是答不出來的，因為沒有到這個階段，他不知道，但是對於一個到了第三個階段的人來說，通常你問這個問題，你是希望他是能夠答得出來的，他說現在我們有一個產品了，這個產品已經找到了準確的市場定位，進入了一個快速增長的階段，所以這個產品的目標是一年之後，月活要翻一翻。OK，這是一個及格的第三階段的程式設計師，因為他知道團隊的商業目標在哪裡，然後他才可以使用自己的執行力去幫助團隊達成這個目標。
接下來就是說，他需要有一個可靠的方案來達成目標，團隊說，我們日活要翻一翻，哪這個階段的程式設計師至少會說，我3-6個月之後，我有這樣的一套方法能做到月活漲到10%-20%，慢慢做完，做完10個月,能做到月活翻一翻，而且團隊裡面也不僅僅只有我一個人，還有其他人，他們做的東西也會對月活有貢獻，那麼這樣才能做出來整個團隊的目標的結果。
然後對於這個階段的程式設計師來說很重要的就是要能夠測量你到B點的距離，月活可能很容易測量，給你一個方法說這叫作月活，資料包表上面就是這樣子的，月活到翻一翻有多遠這是很容易測量的，但是有一些其他問題，不容易這麼測量的，你要找到一個有效的方法來測量，離你的商業目的距離有多遠。然後有時候，你還需要管理其他人對你的工作的期望。
你說我要能做10%月活增長，3個月就能做到，萬一你做不到呢？可能你做了2個月才發現，原來我的專案計劃是錯的，我現在才做了5%，第三個月做完最多就8%，如果你不能管理其他人的期望，讓其他人對於你三個月以後的結果感到非常的意外，可能你就你的結果就沒有這麼好了。
因此對應的這個階段的程式設計師來說，以下一些技能是非常重要的：
第一，你要明白你的商業目標是什麼，這依賴於兩項技能，第一是書面和口頭的溝通能力，因為商業結果並不是程式碼裡寫著明年的月活目標要翻倍，你有看過哪個在你的程式碼裡面嗎？沒有。這依賴於你的溝通能力，或團隊的leader，或者更上級的leader沒辦法把這個事情說清楚，哪你要有能力去和他溝通，要問清楚，要讓你個人能夠理解到，也就是說，領導的精神他不主動傳達給你， 你要有能力去把領導的精神拿回來。明白你團隊的目標是什麼。
然後第二個，你所在的商業領域基礎的理解，你是做哪一行的， 這一行什麼樣才算成功，如何恆量成功，如果這些都不懂，你也沒法理解你團隊的商業目標。
然後接下來就是一些做路線圖的基礎能力，比如說我明白和定義我們團隊任務是什麼？目標是什麼？時間線怎麼定？比如你要做到6個月之後，這麼多的月活。那麼三個月應該有什麼樣的結果，或者每兩個月有什麼樣的結果，多久一次迭代，每次迭代到底要走多遠，這些要能定下來，要管理你的Stake holders,要管理你的dependencies,例如我現在要做的東西是基於React Native，我是做產品的，但是我需要某些新特性，看著React Native的新版本釋出才有，哪萬一React Native說了他們的路線圖什麼時候下一個版本什麼功能，如果它的釋出推遲了，我能管理好嗎？我還能釋出我的功能嗎？哪這是你要想清楚的。
最後就是管理風險 ，就好像我剛才所說的，你肯定會有不同的依賴，像可能有對外的框架庫的依賴項，也可能公司對內的，我做這個產品，我釋出我需要法務的評審，然後我需要市場的配合，新產品一發布，市場就要上來做廣告，萬一市場到時候說，預算還沒有到手，做不到marking contain，你怎麼辦所以更多的細分下來，第一，你要能夠跟蹤進度，跟蹤進度的具體做法就是你要有一些指標，你要定義好指標，通過log從你的生產環境把指標的資料收集回來，然後你要管理其他人對你的團隊和你對你的期望。用最簡單的一句話，就是好像你帶一個小朋友開車上路，他整天會問：我們到哪兒啦？到了嗎？還有多久才到呀？你要理解到這是你團隊的leader或者更高的領導經常想要知道的問題就是我們到了嗎？為啥還沒有到？我們多久才能到？
其實處理這種問題，跟你開車過程中面對的同樣問題是沒有區別的，你要能夠管理好他們的期望，要給給他們一個合理的答案。
同時就是說，你要做風險管理，風險控制，你要正確的識別出可能存在的風險。就好像我剛剛舉的例子，你從北京開車到廣州，天氣預報說上海、浙江一帶可能有颱風，哪你怎麼辦呢？你是提前繞路走？還是說，不管，先開過去，因為我有一個後備方案，開到了真遇到颱風，要怎麼樣避開是要想清楚的。還有就是你要有容災方案，容災方案你也是需要想清楚的。
然後再下一步，更多的就是如何擴充套件你的技術的廣度和深度，然後這時候，雖然你會在前面第0個階段和第二個階段你會不停的練習你的前端的技能，但是到這個級別了，你會發現其實我還有很多其他東西要學，然後不僅僅是HTML,CSS,JS就能解決問題的，你可以說網路你要懂，你能除錯嗎？你能知道HTTP/1.1 和 HTTP/2 怎麼工作嗎？哪如果工作的過程中， 不符合你預期的bug出現，你有辦法除錯嗎？用什麼工具來除錯？你是隻能用Chrome來除錯呢？還是說可以把一個Wireshark掉上去，去看一下TCP DOM出來的結果是什麼？這就是截然不同的技能級別，然後可擴充套件性，可伸縮性，你需要知道的是網路的流量是怎麼樣做負載均衡的，對於很多前端開發人員來說，尤其是在大公司，這可能是從來都不會提出的問題。你看，這個東西我寫完了，伺服器端的程式碼能跑啦，跑起來JS,CSS都載入了，不就出來了嗎？但是這怎麼出來的？你的大規模的群集是怎麼做負載均衡的？如果你的一個資料中心倒了，你的資料還能出來嗎？他能切換到其他資料中心去，其他資料中心還能抗得住嗎？是做4層的負載均衡，還是7層的負載均衡？這些是你要知道的，你才能夠理解什麼是PoP呀，以及CDN怎麼工作等等這些概念，然後安全相關的，你也需要擴充套件一下，你要知道XSS,CSRF，HTTPS怎麼運作，HTTPS上面到底有哪些TLS的擴充套件，這些擴充套件都是做什麼用的，比如說兩個HTTPS的域名共存在一個AIP上，怎麼辦呢？他們能解析嗎？他們能連線嗎？能連線的話，有什麼缺陷嗎？這些是你需要理解TLS擴充套件，你才能知道的答案，最後，到這個階段，往往你也需要真心的要關注一下和效能相關的東西，包括如何做測量和如何做優化。當然你也需要擴充套件一些非技術性的能力，包括設計呀，介面設計，互動設計，使用者體驗設計，資料分析能力，專案管理能力，因為你有了這種能力，你才能夠兼顧一些團隊內其他角色可能做得不哪麼好的，或者做不到你預期的的東西，當這樣的事情出現的時候，因為你需要對業務負責任，所以你必須要有能力去做好。
第四個階段 ，首先要來錢，為什麼你的團隊還在，為什麼沒有被公司斷奶，你的公司沒有倒掉，一切的根本問題就是錢從哪裡來，所以第一個問題就是你要來錢，你要麼說我創立一家公司，別人給我投天使輪，那麼你在大公司內，我要帶領我的團隊做一件新的事情，你要想辦法說服你上面更高階的leader，同意說，我給你HC，你去招人，接下來，你要有人呀，不行，還不夠，別人要想和你一起幹，他們做著做著就沒有動力了，就開始打醬油了，你有HC也沒有用，有錢其實也沒有用，所以你要召集人，讓人覺得你這個商業目標我有興趣去做，最後，說起來是很簡單，其實最後真正最複雜的部分就是執行怎麼到達B點，那麼你需要一些技能是包含領導力。
領導力其實可以拆成兩個部分，一個部分是vision，你要有辦法找到一個對的願景，第二部分，是很多人都會忽視的，就是理解人。
你要理解人的動機是什麼？這你需要把跟人的互動慢慢分解下來，跟別人互動，我們討論的是事實，什麼時候背後的驅動力是情緒，還有什麼時候背後的驅動力是信仰，往往能夠驅動一個人去非常努力的去給你團隊幹活的是靠後的兩者，就是情緒和信仰。而不是事實。事實說我的框架是對的，我的商業目標是對的，這能對你的驅動力本身是不夠的，你需要的是一個人的情緒和信仰去驅動他，這樣子他才能夠給你足夠好的後果或好的結果。接下來呢，還有你銷售的能力，否則從哪裡找來錢，要有一些戰略性思考的能力，然後也要有資源分配和計劃的能力，你有錢啦，有人啦，但怎麼高效的把錢和人利用起來，達成你的目標是你需要知道的，然後同時你也需要技術的，就是增強你的技術能力，怎麼說來做一些可擴充套件性的東西，分散式的計算，分散式的儲存到底是怎麼樣做的，然後你可能需要去管一下發版，發版怎麼發？對於很多做產品的工程師會覺得，我把程式碼提交上去了，自然下一個版本就出去了，哪裡需要怎麼發版呢？不需要知道後臺怎麼樣編譯的，這個東西如果進了App Store會怎麼樣？會怎麼審批，或者其他又怎麼審批，我不懂。到了這個階段，可能你就需要知道了。最後你就是需要了解一些與Web沒有關係的其他方面的前端，就好像iOS或者安卓，或者桌面端，你的產品形態可能不僅僅受限在Web，當然同時你還是要繼續擴充你的非技術的能力，是招聘，培養人才，管理人才，其實你可以看看很明顯的模式就是所有的東西跟人相關的，到了這個階段，你會真正的理解到我為什麼說，人是你最重要的資源。因為你沒有人，你什麼都不用幹了。所以你要有能力把人招過來，或者忽悠過來，然後要把他們培養好，他們有能力做你希望他們做的事情。然後要管理好他們，不能讓他們打醬油。
第五個階段 ，那你的目標就更難達到了，證明有一個Reasonable 的ROI,如果你能找到B點在哪裡，沒有人能夠通過很簡單的用資料說法的方法說明這個商業目的到底能不能達到和達到了之後一定和。但是你要有方法說明是事情有風險，但是這個風險是合理範圍之內，是正的，所以我們應該去，這個好的商業結果我可以拿到手，接下來就是你要拿到足夠的錢和去做，因為這需要更多的人和更多的錢，最後就是去到B點，技能方面，這個已經辦法很深入的去講每一個具體的技能:
第一就是讓，要讓你之前的技能每一個都，就是擴充套件出去，提高你的深度和廣度，而第二個，其實是很重要的，開始要有跨界，跨行業這樣的技能，就是你不僅僅只呆在一個前端程式設計師、前端工程師或者工程師的級別中，因為你可以看一下哪些真正帶領更大的團隊來達成一個可能可達成的不可達的商業目標，你會發現，他們不已經在乎他們原本出身是程式設計師呢？設計師呢？還是PM呢？還是資料分析師。這一切都不重要了，重要的是到了哪個領導力的級別，有能力去找到一個足夠重要的目的地，說服公司給投資之後，他們下面要能夠領導這些所有這種不同的角色，然後協同分工，把事情做出來，最後達到這個商業目的的結果。
所以到了這裡的時候，這也很好的說明了我原來的這個說法，前端，後端，全棧其實不重要了，因為最後當你來到這個階段的時候 ，比如說，我要創始一家新的公司，其實沒有人會問你說，你作為一個創始人你的技能最重要的，最有效的是什麼技能呀？更多是你能不能把團隊組起來，你的團隊組起來之後，到底技能怎麼互相補充，能夠做成你想要做的這件大的事情，這就是最後一個階段的需要的技能。
“我自己是一名從事了5年前端的老程式設計師，辭職目前在做講師，今年年初我花了一個月整理了一份最適合2019年學習的web前端乾貨，從最基礎的HTML+CSS+JS到移動端HTML5到各種框架都有整理，送給每一位前端小夥伴，這裡是小白聚集地，歡迎初學和進階中的小夥伴。"
加QQ群：931661106（招募中）
關注公眾號：蝌蚪前端
每晚7點直播講課，送前端學習資料，從基礎到框架，專業的老師為你指導
加微❤：QD_666_QD
總結
你做這一切，要達到目的地，接下其實真正你需要問的問題是，此時此刻，在這個階段，顧客是誰？這是最重要的一個問題，或者我們可以換一個角度來提這個問題，如果我成功達到我的目標，什麼人的生活會變得更好。以何種方式變得更好，如果你能夠很清晰明確的回答這個問題，其實你的方向會很明確，該學什麼，該做什麼，最後要到哪裡，你都是可以自己回答的。或者就算不能自己回答，你也可以知道去找哪些人提問，通過哪些途徑獲取到你想要的答案。這時候你已經有一個可靠的方法到達你的目的地。