先說點什么吧

經(jīng)過大半年的踟躕，最終還是決定要寫一點關(guān)于我所從事的職業(yè)的文章。但與以往的分享或文章不同，這次的內(nèi)容無關(guān)任何具體的技術(shù)。我在“webpack指南”、“組件庫開發(fā)”和“可視化頁面編輯器”這三個選題中猶豫了很久，但最終是某次和同事們在樓下休息，聽著同事們吐槽身邊事情的時候確定的。那一刻我忽然不太想分享任何具體的前端技術(shù)經(jīng)驗，而是想泛泛地，隨意地就這“前端開發(fā)”這個主題本身來聊一聊我個人的一些想法和認(rèn)知。一方面對我自己來說是一次思維旅行和經(jīng)驗總結(jié)，另一方面也期望這些散碎的看法能對讀者有益。

當(dāng)然，還是要簡要地介紹一下自己的從業(yè)經(jīng)歷。我是2015年開始從事前端開發(fā)工作，期間經(jīng)歷了唯品會、融數(shù)金服、火幣、嘩啦啦四家企業(yè)。除了日常的項目任務(wù)，還開發(fā)了一套在融數(shù)期間成型的UI組件庫Admin UI。目前在嘩啦啦負(fù)責(zé)商戶中心前端組件化的相關(guān)工作，同時負(fù)責(zé)一個實驗性質(zhì)的低代碼前端頁面編輯器項目Primus。

前端開發(fā)工程師

在我們的職位名稱中，“前端開發(fā)工程師”這個詞中包含了我們這個群體主要的工作內(nèi)容、范圍，以及我們的職位。這里我使用了“表述”二字來拆解這個職位名稱，但很多時候有意或無意地，我們會以此畫地為牢，將自己牢牢地限定在這個范圍內(nèi)。

實際上可能很多時候你壓根不知道或者根本沒有思考過關(guān)于“前端”這個詞的含義。對于Web開發(fā)者來說，多數(shù)時候這意味著一些HTML頁面，包含著一些精心設(shè)計的結(jié)構(gòu)、樣式和交互邏輯。但從更廣義地范圍，“前端”指的是“面向用戶的那一端”。這意味著作為前端開發(fā)工程師，你是那個最終需要為用戶體驗負(fù)責(zé)的人。

我曾聽過同事抱怨由于后端同事提供的接口性能太差，過長的返回時間導(dǎo)致用戶需要在前端等待很久。我問他你為什么不去解決這個問題？他的回答是“我前端頁面的性能沒問題，這是后端的鍋”。這是個非常經(jīng)典的回答，同時也是一個完美的牢籠！

事實是大部分用戶根本不知道你這個頁面體驗這么糟糕到底是什么原因。他們不知道，不愿意知道，也不應(yīng)該知道。他們是用戶，而你是照顧他們的人。走出這個牢籠的唯一正確的信念只有一條：照顧好你的用戶。

照顧好你的中間用戶

既然要照顧用戶，自然首先需要搞清楚你的用戶到底是誰。常年在業(yè)務(wù)線的朋友可能不假思索就會回答，我的用戶就是用我們產(chǎn)品的人。這當(dāng)然是沒有錯的，但實際上，還有一些不太容易注意到的用戶被我們忽略了。

假設(shè)你目前正作為前端工程師參與某個OA系統(tǒng)的開發(fā)。其中一個功能點是“用戶能夠在組織結(jié)構(gòu)中準(zhǔn)確查找到部門”。為此你和產(chǎn)品經(jīng)理精心設(shè)計和實現(xiàn)了一個“部門篩選器”放在了頁面中。之后你又注意到很多其他的模塊也需要這個功能，于是你將它做成了項目內(nèi)通用的“組件”供負(fù)責(zé)開發(fā)其它模塊的同事使用。

在這件事上，我想問的是你真的清楚你的用戶是誰嗎？

毫無疑問你們整個OA項目所面向的用戶肯定是你的用戶，我習(xí)慣稱之為“最終用戶”。而使用了通用模塊“部門篩選器”的那些同事們，實際上是你的“隱藏用戶”，我習(xí)慣稱之為“中間用戶”。你可能對于如何照顧好“最終用戶”已經(jīng)駕輕就熟了然于胸了，但對于這些“中間用戶”，你如何照顧到他們？你可能需要花心思做好下面的事情：

• 好好整理和設(shè)計“部門篩選器”組件本身的功能和接口，讓組件本身心智模型盡可能簡單；讓接口命名極盡可讀；讓接口數(shù)量在滿足功能和日后擴(kuò)展性的前提下盡可能少
• 支持盡可能多的安裝方式，并考慮各種安裝方式下的異同，如果安裝過程本身較為復(fù)雜，則應(yīng)該盡可能幫助你的同事們做掉這方面的額外工作（比如提供CLI工具來進(jìn)行安裝）
• 在同事們很方便就能訪問到的地方提供詳細(xì)的組件使用文檔，并開放QA，盡可能解答同事們的疑惑
• 盡量使用語義化的版本號，并盡可能在非大版本的升級上向前兼容

我只是拍腦袋列舉了幾條，實際上如果你正在開發(fā)一個組件庫，則需要做的事情遠(yuǎn)不止這些。

我們來看看另一種場景，假設(shè)你正在為一個新的項目做一些初始化工作。確定技術(shù)選型、選擇組件庫，制定各種項目約定、劃分路由和業(yè)務(wù)模塊等等這些前端架構(gòu)師的日常工作，除了面向最終用戶，更多時候是面向項目組內(nèi)的其它前端甚至后端伙伴。他們是你作為架構(gòu)師的中間用戶，照顧好他們意味著你需要這些事情：

• 編寫一個完善的README文檔，這個文檔應(yīng)該讓新進(jìn)的同事在不問你任何問題的情況下即可開始項目的開發(fā)工作，這是所有架構(gòu)師應(yīng)該完成的基本工作
• 不要過度設(shè)計，很多時候過度設(shè)計會帶來沉重的心智負(fù)擔(dān)，給你的團(tuán)隊造成巨大困擾。合理的程度應(yīng)該是“剛好能用”，比如在業(yè)務(wù)模塊的層面實際上可以不再進(jìn)行代碼復(fù)用，那些看起來一樣的樣式、邏輯和交互就讓它們在模塊層面重復(fù)編寫即可。業(yè)務(wù)模塊層面進(jìn)行代碼復(fù)用的后果很可能是你的伙伴們根本記不住都有哪些東西被提取出來了，久而久之那些被提取出來的東西就被遺忘了。另一方面業(yè)務(wù)模塊的頻繁變動通常會讓原本可復(fù)用的代碼失效，得不償失
• 沒有特殊需求的情況下，技術(shù)選型、項目內(nèi)的約定應(yīng)該盡肯能照顧到你的團(tuán)隊的大部分人。選型方面應(yīng)該盡可能使用他們最熟悉的技術(shù)和庫，項目內(nèi)的約定應(yīng)該盡可能符合大多數(shù)人的編碼習(xí)慣

所以廣義上來看，除了你的最終用戶們，整個公司內(nèi)甚至整個行業(yè)內(nèi)（開源事業(yè)）對你有依賴的同事和朋友們，實際上都是你的用戶。而面對所有這些用戶唯一正確的信念真的只有一條：照顧好他們。對于一個優(yōu)秀的前端開發(fā)者來說，無論面對的用戶是“最終用戶”還是“中間用戶”，一切擋在你和用戶之間的障礙，清除他們就是你的工作職責(zé)。

不只是寫代碼

想要成為一個優(yōu)秀的前端開發(fā)工程師，你的工作可遠(yuǎn)不止是寫代碼而已。

我曾經(jīng)聽過一句話“技術(shù)解決不了任何問題”。這當(dāng)然是一句極端的斷言，但并不全無道理。隨著工齡的增長，你是否曾發(fā)現(xiàn)工作中遇到的大量問題實際上根本不能或者不應(yīng)該靠技術(shù)來解決？《程序員的思維修煉》一書中講過一個故事，大意是某航空公司召集了大量技術(shù)人員，希望設(shè)計一種新型超音速客機來替代現(xiàn)有的亞音速客機。當(dāng)時正好有相關(guān)的領(lǐng)域?qū)＜以趫?，然而他并沒有立刻提出自己的技術(shù)方案，而是追問航空公司為什么需要超音速客機？航空公司答曰需要提高客運速度。大部分技術(shù)專家估計會止步于此不再追問，然而該領(lǐng)域?qū)＜覅s繼續(xù)追問：“為什么要提高客運速度？”航空公司答曰希望借此縮短旅客的旅程時間，提高旅客的用戶體驗。專家又追問：“旅客從家出發(fā)到目的地安頓好的這段時間中，在飛機上的時間占其中的多大比例？”

最后的結(jié)果是航空公司放棄了需要巨大研發(fā)成本和實際上乘坐體驗很差的超音速飛機方案，轉(zhuǎn)而著手優(yōu)化旅客從家到目的地的整個旅程上的各個其它部分的體驗，反而達(dá)到了更好的效果。

這意味著照顧用戶，很多時候技術(shù)解決不了太多問題。作為前端開發(fā)工程師，開發(fā)只是你的工作的一小部分。有時候你需要站在產(chǎn)品經(jīng)理的角度和他們一起去思考，幫助產(chǎn)品經(jīng)理設(shè)計出更合理的產(chǎn)品。有時候你也需要站在美術(shù)設(shè)計的角度上，幫助設(shè)計出更統(tǒng)一更漂亮的界面。還有些時候，你需要站在行業(yè)的山頂，俯瞰和審視你所開發(fā)的產(chǎn)品及其價值，幫助你的領(lǐng)導(dǎo)甚至公司糾正可能會發(fā)生的產(chǎn)品定位上的偏航。

為什么需要做這么多的事情？答案很簡單：你所有的工作價值，都是建立在用戶價值之上的。幫助用戶實現(xiàn)他們的價值應(yīng)該是你和你團(tuán)隊所有人的最終目標(biāo)。做出所有決定以及確定工作職責(zé)的時候，如果你正盯著這個最終目標(biāo)，那么你甚至?xí)X得我上面說的內(nèi)容少得可憐。至于前面提到的關(guān)于接口性能的事，我想讀到這里，你應(yīng)該有自己的想法了。

面對你的伙伴們

幫助你的伙伴做好他的工作，并不是說要越俎代庖。我們來稍微討論一下流水線上的不同職位。

國內(nèi)大部分公司的前端工程師們面對的工作流程通常是這樣的：產(chǎn)品經(jīng)理 -> 美術(shù)設(shè)計 -> 前端/后端 -> 測試 -> 運維 -> 用戶。

產(chǎn)品經(jīng)理通常負(fù)責(zé)研究用戶需求，并根據(jù)用戶需求確定和設(shè)計產(chǎn)品功能。對于他后面的同事來說，他應(yīng)該只負(fù)責(zé)提出功能要求，這也應(yīng)該是大部分人的期望。雖然有時候產(chǎn)品經(jīng)理們會負(fù)責(zé)設(shè)計一部分交互形式，但我認(rèn)為這實際上并不應(yīng)該由他們來負(fù)責(zé)。在一個沒有專門的交互設(shè)計師的團(tuán)隊中，交互形式的設(shè)計通常會由美術(shù)設(shè)計來完成。很多時候的實際情況是無論是產(chǎn)品經(jīng)理還是美術(shù)設(shè)計來負(fù)責(zé)，最終設(shè)計出來的交互形式從實現(xiàn)成本和易用性上看往往差強人意。關(guān)鍵的原因是如果沒有經(jīng)過專門的交互設(shè)計訓(xùn)練，產(chǎn)品經(jīng)理和美術(shù)設(shè)計，很多時候并不清楚不同的交互形式的優(yōu)缺點，以及實現(xiàn)它們大概的成本。而作為常年開發(fā)交互界面的前端工程師則恰恰相反，經(jīng)驗豐富的前端工程師往往把玩過極多的交互形式，也很清楚實現(xiàn)這些交互大概的技術(shù)成本，他們能夠找到平衡點。

美術(shù)設(shè)計在實際的工作中往往被稱為“UI設(shè)計”（交互界面設(shè)計），但基于上面的原因我并未使用“UI設(shè)計”一詞。美術(shù)設(shè)計決定了產(chǎn)品的顏值，如果說產(chǎn)品經(jīng)理提出的是“功能要求”，那美術(shù)設(shè)計提出的則是“視覺要求”。如果產(chǎn)品各部分的交互形式由前端工程師最終來決定，那么美術(shù)設(shè)計提出的“視覺要求”可能就需要基于前端工程師的交互形式來產(chǎn)生。但本質(zhì)上，對于后一個節(jié)點上的“前端/后端”來說，前面兩個節(jié)點產(chǎn)生的都是“要求”。這兩份“要求”就是工程師們的具體工作內(nèi)容了。

如果項目中前端和后端是分離的兩個項目，并且前端并不負(fù)責(zé)展示層的接口（在有些項目中會存在Node/Python/Go等語言編寫的面向展示層的中間層，而這些中間層很可能也是由前端工程師們自己負(fù)責(zé)的），那么前端對后端就會存在“接口要求”。在后端工程師需要完全對展示層接口負(fù)責(zé)的前提下，接口的字段應(yīng)該由前端來設(shè)計。實際工作中雖然不會這么絕對，往往是后端提供一份“接口文檔”來列出接口的字段，但至少這份“接口文檔”應(yīng)該需要被前端認(rèn)可。而這份“接口文檔”實際上就是前端向后端提出的“接口要求”?？赡芎蠖斯こ處煏枰岸嗽谔岢觥敖涌谛枨蟆睍r稍微照顧到他們的模型設(shè)計，但原則上，前端工程師是要求的提出者，不應(yīng)存在太多的妥協(xié)。從這個角度上看前文的接口性能問題，“接口要求”中也應(yīng)該對后端工程師提供的接口性能提出具體要求。實際上接口性能要求的源頭是來自于最初產(chǎn)品提出的“功能要求”中的，因為產(chǎn)品經(jīng)理們在“功能要求”中大可以提出某些關(guān)鍵性能的要求。

大部分公司的測試們正在做著一份偉大的工作：為開發(fā)們擦屁股。通常測試需要負(fù)責(zé)每個迭代開發(fā)產(chǎn)物的各種測試工作，找出開發(fā)者們埋下的雷并反饋給開發(fā)者們讓其修復(fù)。在大部分公司中，測試是產(chǎn)品上線前的最后一道關(guān)口，如果出現(xiàn)線上BUG，測試往往需要對此負(fù)責(zé)。我曾經(jīng)遇到這樣的場景：測試在群里告訴某開發(fā)者他的模塊測出了幾十個BUG，但他并未錄入官方記錄，只是善意提醒其注意代碼質(zhì)量并盡快修復(fù)，結(jié)果該開發(fā)者反過來譏諷測試是在拿BUG數(shù)量耀武揚威，認(rèn)為其侮辱了測試這一職位。個人品性先放到一邊，我對這種認(rèn)為測試就應(yīng)該是給開發(fā)者擦屁股背鍋的認(rèn)知是極端鄙視的。測試們工作的職責(zé)是保障產(chǎn)品質(zhì)量，難道開發(fā)者們不應(yīng)該承擔(dān)這一責(zé)任么？你的良心不會痛么？很長時間我所在的團(tuán)隊都沒有這里說的這些傳統(tǒng)意義上的“測試”崗位。我們僅僅通過單元測試、自測和“集中測試”（我自己造的詞，團(tuán)隊所有人停下來，一起測試某個迭代結(jié)果）來保證開發(fā)質(zhì)量。而原本“應(yīng)該”做這些事的測試們，去做測試平臺了。產(chǎn)品在上線之前，需要通過測試平臺的各種自動化測試才能繼續(xù)部署，我認(rèn)為這才是真正的“測試”。

最有意思的是運維同學(xué)。往往只有項目需要部署發(fā)布，開發(fā)者們才能感知到運維的存在。我觀察到一個有意思的現(xiàn)象：很多公司的運維在做著原本應(yīng)該是業(yè)務(wù)線的開發(fā)者們應(yīng)該做的部署工作，并且以此為榮。在這個背景下，業(yè)務(wù)線想要部署發(fā)布時，氣氛就變得很微妙了：運維覺得你們這些開發(fā)者什么都不懂，但真的需要打包發(fā)布的時候卻不得不反過來詢問開發(fā)者你這個項目應(yīng)該怎么打包，怎么發(fā)布...真是耐人尋味。除了運維們的小心思，這里的問題跟測試非常類似，運維應(yīng)該提供運維工具或平臺，業(yè)務(wù)運維應(yīng)當(dāng)由業(yè)務(wù)開發(fā)者自己來完成?？夏苣闼诘墓灸壳斑€不具備這種條件，但當(dāng)你面對運維時，你應(yīng)該有這樣清醒的認(rèn)識。

Leader

實際工作中除了與你通力合作的伙伴們，你往往還需要面對你的領(lǐng)導(dǎo)。我想稍微討論一種在面對領(lǐng)導(dǎo)時很有意思的態(tài)度：唯命是從，領(lǐng)導(dǎo)說的都是對的，無條件服從。這一態(tài)度有兩種表現(xiàn)：其一是從最一線的員工到中層到高層，層層對上負(fù)責(zé)，所做的一切，只為得到領(lǐng)導(dǎo)的認(rèn)可；其二是將所有細(xì)節(jié)都暴露給領(lǐng)導(dǎo)，所有需要決策的地方都讓領(lǐng)導(dǎo)來進(jìn)行。

對于第一種表現(xiàn)，實際上單獨拿出來說并沒有意義，出現(xiàn)在這里只是明確表現(xiàn)出了這些人對自己工作的認(rèn)知和態(tài)度。想要升職加薪無可厚非，但工作的意義本身似乎對他們來說無足輕重。我并不想討論工作的意義這種過于深刻的問題，但我認(rèn)為大家都應(yīng)該要思考這個問題。但凡是思考過這一問題，就幾乎不會出現(xiàn)“單純討好”領(lǐng)導(dǎo)這種表現(xiàn)。

我想仔細(xì)討論一下第二種表現(xiàn)，這也是我最近觀察到的最多的情況。我經(jīng)常看到同事們跑去找公司的SVP級領(lǐng)導(dǎo)，討論各種產(chǎn)品的具體問題，并討要解決方案這種迷惑的行為。甚至好幾次我觀察到某些一線產(chǎn)品經(jīng)理去找他討論按鈕應(yīng)該擺在哪里這種蠢問題。一個典型的情形是：產(chǎn)品經(jīng)理跑去找領(lǐng)導(dǎo)，從領(lǐng)導(dǎo)那里獲得了一個某按鈕應(yīng)該放在某位置的方案，執(zhí)行下去后，用戶反饋抱怨說該按鈕放的層級太深特別不好用。這時產(chǎn)品經(jīng)理根本不需要承擔(dān)責(zé)任，至少不會被領(lǐng)導(dǎo)責(zé)難，因為這是領(lǐng)導(dǎo)決定的。

問題在哪里？問題出在迷一般的工作職責(zé)和范圍。SVP應(yīng)該關(guān)心技術(shù)方案細(xì)節(jié)和產(chǎn)品細(xì)節(jié)嗎？產(chǎn)品經(jīng)理或開發(fā)者應(yīng)該讓SVP關(guān)心具體細(xì)節(jié)嗎？SVP不應(yīng)該是只關(guān)心方向和結(jié)果嗎？下屬們不應(yīng)該是只對結(jié)果負(fù)責(zé)嗎？出現(xiàn)這一情況的原因我認(rèn)為一樣來自雙方：大佬的問題是太過和善，每次都能滿足他們；而下屬的問題則是不愿擔(dān)責(zé)。

一個正常的上下級交互模式是這樣的：領(lǐng)導(dǎo)只關(guān)心整體目標(biāo)以及達(dá)成該目標(biāo)的大致方向，而下屬工作范圍內(nèi)的所有決策應(yīng)該由下屬自己進(jìn)行，并對決策結(jié)果負(fù)責(zé)；團(tuán)隊以此模式層層向下。這種模式實際上與OKR的思想不謀而合。一個典型的假想的例子：

• 公司：在移動辦公領(lǐng)域發(fā)力，對標(biāo)其它移動辦公OA產(chǎn)品在該領(lǐng)域分一杯羹，并最終做到行業(yè)前三
• 技術(shù)中心VP：上線一款類釘釘?shù)膽?yīng)用“聽聽”，并覆蓋Web，iOS，安卓、各大小程序
• 產(chǎn)品中心副VP：組織“聽聽”Web端及小程序端的研發(fā)，并在三個月內(nèi)上線1.0版本
• 前端架構(gòu)：“聽聽”Web端項目技術(shù)選項、架構(gòu)設(shè)計...
• 前端開發(fā)：開發(fā)“用戶詳情”頁面

在這個至上而下的過程中，產(chǎn)品中心副VP根本不應(yīng)該關(guān)心前端Leader在技術(shù)選項上的決策，他只應(yīng)該關(guān)心是否能在三個月內(nèi)上線；而前端Leader原則上不應(yīng)該向副VP暴露他工作范圍內(nèi)的細(xì)節(jié)。當(dāng)然，不是說不能和你的上級討論一些有意思的工作內(nèi)容，你的上級也不是說不能給你一些合理的意見或建議，而是本質(zhì)上你需要對你工作范圍內(nèi)的所有決策負(fù)責(zé)。比如副VP建議前端架構(gòu)可以使用React作為框架，前端架構(gòu)基于各種原因，可能是團(tuán)隊、工期或成本等等，最終是可以決定使用Vue的。這時候架構(gòu)師只需要對產(chǎn)品中心副VP的目標(biāo)，也就是他的工作結(jié)果負(fù)責(zé)：在三個月內(nèi)上線。

最后對于Leader這個話題，我想以我對Leader的認(rèn)知結(jié)尾：作為一線的兵，我對Leader的目標(biāo)負(fù)責(zé)，沖鋒陷陣苦活累活甚至罵街掀桌，我來；作為后方的將領(lǐng)，Leader對我的后勤及保障負(fù)責(zé)，爭取獎金保障調(diào)休甚至背鍋扣帽，他來。

Mentor

很多外企都有Mentor制度，新進(jìn)的同事在第一年都會有一個負(fù)責(zé)指引他的導(dǎo)師。國內(nèi)的公司則大多沒有這么明確的制度，但我建議或多或少要有這個意識。

作為新進(jìn)的或低等級的萌新開發(fā)者，不要羞于尋找你的Mentor。一個好的老師勝過十本書，一個好的指引者對被指引者的影響是巨大而深遠(yuǎn)的。不僅僅是技術(shù)上的指導(dǎo)，Mentor更多的時候是在價值觀、思維方式、工作態(tài)度和做事方法上起到指引和示范作用。我本人就是一個活生生的例子，我開始從事開發(fā)工作后不久，遇到了第一位老師。當(dāng)時他也是我的上級，雖然他并不是前端開發(fā)者，甚至基本上他已經(jīng)不寫代碼了，但進(jìn)入他的部門后，他主動承擔(dān)起了Mentor的工作，言傳身教，向我打開了新世界的大門。到今天雖然我和他已經(jīng)不在一個公司，但在我作為一個萌新時他所展現(xiàn)的那些價值觀、思維方式和做事方法，直到現(xiàn)在還在深深影響著我。雖然他不是前端開發(fā)，但卻正是基于他的引導(dǎo)和培養(yǎng)，我的前端技術(shù)才能得以突破，迅速成長到架構(gòu)師的程度。

我的第二位老師，后來一直是我的領(lǐng)導(dǎo)。雖然他從來沒說過是我的Mentor之類的話，但我一直將其看成是Mentor，他也一直在扮演著Mentor的角色，引導(dǎo)和培養(yǎng)著我和我的那些伙伴們。我是幸運的，工作中能遇到這兩位老師。但同時我也是精明的，我知道遇到好的Mentor很難，一旦遇到，應(yīng)該珍惜。

而當(dāng)你成長到一定程度，你要有作為Mentor的覺悟。從技術(shù)等級上說，高等級的開發(fā)者應(yīng)該主動承擔(dān)起對低等級的開發(fā)者的指引工作，這是大部分公司技術(shù)分級中的實際要求。作為Mentor去指引他人對自己也是有好處的：一方面教學(xué)相長，你在指引的過程中自己肯定也會需要進(jìn)一步思考提升，；另一方面這也是你對你所在團(tuán)隊的貢獻(xiàn)，因為你肯定不希望新來的同事是豬隊友。這里涉及了另一個話題：主動性。

主觀能動性

環(huán)境和個體是相互作用的：你所處的團(tuán)隊影響著你，你也可以反過來影響你的團(tuán)隊。除了主動承擔(dān)新進(jìn)成員的Mentor工作以外，更重要的是，作為團(tuán)隊的成員需要有主觀能動性，主動地去影響你所處的團(tuán)隊。

我聽過太多類似的抱怨：工作不順利，因為所處的團(tuán)隊太糟糕。當(dāng)團(tuán)隊出現(xiàn)或者存在問題時，我們當(dāng)然可以抱怨，但僅僅抱怨是沒有用的。我認(rèn)知中的主觀能動性，實際上有三個方面的表現(xiàn)：

• 以身作則，自我管理：不管所處的團(tuán)隊或環(huán)境有多么糟糕，出現(xiàn)了多少問題，這不能成為你放低對自己要求的理由。比如你的團(tuán)隊沒有人寫單元測試，但這不能成為你不寫單元測試的理由
• 發(fā)現(xiàn)問題，解決問題：主動去解決或者幫助、推動解決你看到的那些問題，而不是去關(guān)心這個問題你有沒有責(zé)任，或者是不是在你的工作范圍內(nèi)
• 正向引導(dǎo)，改變團(tuán)隊：盡可能去向團(tuán)隊其他成員傳遞正確的價值觀和做事方法，幫助他們改善和糾正自身問題，幫助他們提升自己，進(jìn)而提升整個團(tuán)隊

你可能會發(fā)現(xiàn)，這些事情應(yīng)該是一個團(tuán)隊的Leader應(yīng)該做的事情，作為團(tuán)隊成員你好像有些越俎代庖。我認(rèn)為擔(dān)心完全是多余的：其一是不想當(dāng)將軍的士兵不是好士兵，這是應(yīng)有的想要進(jìn)步的表現(xiàn)；其二是你對團(tuán)隊做出的這些貢獻(xiàn)，在KPI層面將全部算到你的團(tuán)隊Leader的身上，聰明的Leader應(yīng)該為有這樣的團(tuán)隊成員而感到興奮。

關(guān)于范式、語言、框架、庫和工具

我并不想列舉前端領(lǐng)域那些常見的編程模型、語言或者框架、庫和工具。如果讀者對這方面內(nèi)容有興趣可以留言，我擇日另開文章再行分享。這個話題下我想聊的是作為一名開發(fā)者我們應(yīng)該如何看待這些東西。我經(jīng)常能在網(wǎng)上看到類似這樣的評論：“求不要更新了，學(xué)不動了”。雖然是一句玩笑話，但實際上的確有不少開發(fā)者是有類似的心態(tài)的。我們不能說這種心態(tài)有什么不對，只是這種心態(tài)會給我們自己造成困擾。

實際上我們對新技術(shù)的恐懼是由不恰當(dāng)?shù)恼J(rèn)知造成的。很多朋友看到一門新的技術(shù)、框架等，往往只是看到了其是什么，比如說大部分人聊到Vue，可能順嘴就把官網(wǎng)的介紹說出來了：“漸進(jìn)式JavaScript框架”。的確，官方介紹準(zhǔn)確描述了這門技術(shù)，但這句官方介紹并未傳遞一個非常重要的信息：它解決了什么問題。

這實際上是我個人非常推薦的看待各類范式、框架、語言等等的方法。還拿Vue舉例，如果是剛剛上手，一定要帶著這個問題去看官方文檔：它解決了什么問題？這個問題背后隱藏了很多信息：

• 相對于vanilla JS，Vue解決了什么問題
• 相對于React、Angular這類同類型的框架，Vue又解決了什么問題
• 你期望Vue解決你的什么問題

我并不想展開這些點去討論，而是希望你能帶著這些問題去看待一個新的技術(shù)。

你會發(fā)現(xiàn)實際上“解決了什么問題”幾乎可以用來看待一切技術(shù)的更迭：

• 面向?qū)ο蠓妒浇鉀Q了什么問題？響應(yīng)式編程解決了什么問題？MVC/MVVM/MVI這些范式又解決了什么問題？這個框架解決了什么問題？這個庫解決了什么問題？這個工具解決了什么問題？
• 這次升級解決了什么問題？這個選型解決了什么問題？這個架構(gòu)解決了什么問題？這個約定解決了什么問題？
• ...

為什么這副“解決了什么問題”的眼鏡，可以拿來看待所有的技術(shù)？因為這是技術(shù)的本質(zhì)：任何技術(shù)的出現(xiàn)都是為了解決已經(jīng)存在的問題。只有存在需求，新的技術(shù)才能出現(xiàn)。你會發(fā)現(xiàn)透過這幅眼鏡，大部分的技術(shù)都不新鮮。人類的本質(zhì)需求實際上是非常固定的，而作為技術(shù)需要服務(wù)的對象，只要需求沒有變更，任何將該需求作為目標(biāo)的技術(shù)本質(zhì)上都不是真正的“新”技術(shù)。React相對于Angular是新技術(shù)嗎？不是，因為它們本質(zhì)上在解決同一個問題。Vue是新技術(shù)嗎？不是，因為它甚至跟React用了類似的方式來解決同一個問題。

面向?qū)ο笫切录夹g(shù)嗎？不是，因為即使沒有面向?qū)ο螅銓憥资甏a，自然而然也會為了省事寫成面向?qū)ο蟮臉幼?，因為不管有沒有面向?qū)ο筮@種范式，你都要做抽象。響應(yīng)式函數(shù)式編程是新技術(shù)嗎？不是，因為它實際上也是在解決“抽象”的問題。

所以你看，戴著這副“它解決了什么問題”的眼鏡，你將從各個方向?qū)徱曇婚T技術(shù)：

• 橫向：同當(dāng)前市面上解決該問題的其它技術(shù)進(jìn)行比較
• 縱向：不同時間段上（或各版本間）該技術(shù)的各次迭代的比較
• 時間線：在人類最早開始解決該問題到現(xiàn)在，使用過的所有技術(shù)與該技術(shù)的比較？
• 遞歸：該技術(shù)各個部分分別解決了什么問題，該問題的橫向、縱向和時間線的比較

思考完這些問題，就只剩下一件事了，面對某個具體問題，這個技術(shù)是怎么解決的。這時候去看官方文檔，它們的文檔要是寫的稍微好點，你會發(fā)現(xiàn)你甚至輕易就能背下來。

至此，媽媽再也不用擔(dān)心我學(xué)不動了。

路的盡頭

最后一個話題是前端開發(fā)這個職業(yè)，未來會是什么樣子？

我前段時間有一年多把大量時間花在了一個叫做“Primus”的項目上。這個項目是一個類似阿里“云鳳蝶”的項目，一個前端低代碼開發(fā)平臺。目的是希望產(chǎn)品經(jīng)理、后端、實施等非前端人員也能很方便創(chuàng)建前端項目和頁面。我認(rèn)為這是前端開發(fā)未來一個重要的方向。

從技術(shù)更迭上講，微軟很早就在.net上幾乎完成了這種更迭，從寫代碼到低代碼最后甚至到無代碼。從目前常見的流程來看，開發(fā)后面的兩塊已經(jīng)有很多公司出現(xiàn)了“平臺化”的做法，也就是測試平臺和運維平臺。接下來一定是開發(fā)平臺化，產(chǎn)品經(jīng)理和設(shè)計師在開發(fā)平臺上就能開發(fā)產(chǎn)品了。

再往遠(yuǎn)看，平臺化之后一定就是智能化。目前已經(jīng)有大廠們在嘗試了，比如淘寶的智能切圖。未來的前端開發(fā)很有可能會被AI所取代，我們的出路很可能是作為前端專家去開發(fā)和維護(hù)某個智能平臺。

這只是我一些美好的愿景和幻想而已，但路漫漫其修遠(yuǎn)兮，諸君共勉吧。

截止到當(dāng)前的行文時間，“云鳳蝶”目前只支持創(chuàng)建移動端運營頁面，還不支持創(chuàng)建PC端的管理頁面，但他們悶頭做了很久了，相關(guān)文章也出了很多，就是不開放出來讓我抄一下...

結(jié)束語

好了，終于結(jié)束這篇沒有任何干貨的文章了。這些觀點實際上并沒有任何依據(jù)，我也不善于引經(jīng)據(jù)典。也請一定不要認(rèn)為我的這些觀點就一定是對的或者合適的。我只是期望通過這種漫無目的的探討，能夠引起讀者的思考。如果能對讀者有任何微小的幫助或啟發(fā)，我將不勝榮幸。感謝！