論一個前端開發者的自我修養

時間 2020-06-19

原文原文鏈接

先作個簡單的自我介紹：本人（大名：蕭文翰），Android 架構師/技術顧問。從2013年開始從事移動前端開發，主攻 Android 和跨平臺開發技術，具備豐富的實戰項目經驗。國內7項專利共同發明人；圖書《Android App Hook and Plug-In Technology》譯者（中譯英）；自2017年末至2019年，擔任天津/廣州三星通訊研究院代碼優化工做，期間6次當選 Best Tecknical-Report ，曾推進 App 性能優化活動，實現性能類別解決方案同比增加60%，整體解決方案領先於全球研究院的成果；此外，仍是 CSDN 認證的博客專家和認證講師；知乎專欄做家；微信訂閱號「前端開發實用技巧」做者兼運營；阿里 ACE 天津分會成員；著書《Flutter 核心技術》（即將上市）、《打造流暢的Android App》（正在寫）。業餘愛好頗爲普遍，圍棋、古典音樂、鋼琴、駕駛，反正啥都能玩得轉。
好了，先讓你們對我有個瞭解，再說說這篇文章。爲何此次選這個題目呢？有外因，也有內因。外因的話各位都有目共睹，「IT就業寒冬」相信即便不是軟件開發行業的朋友，都多少有所耳聞，加上Android就業形勢本就越來越走下坡路，一些 Android 開發者都不約而同地轉向大前端甚至是後端……再說說內因，瞭解個人朋友都知道，其實我是個土生土長的天津人，去年公司裁人，又由於夫人是廣州人氏，因而選擇公司內部調轉到廣州工做，到如今差很少有1年了，現在即將與妻一塊兒回津發展。恰逢本人即將踏上自由職業的生活，因此在此發表一下關於前端工程師，應該具有哪些自我素養。
這裏沒有代碼，更沒有學習路線，更多的是在談「態度」。我我的以爲，正確的人生觀和價值觀會成就正確的方法論。因此，在入行前端開發，或者意欲轉型以前，應該給本身留一點時間，去沉澱和反思。就如同咱們要駕駛汽車跑幾千千米的遠途，中間休息好，才能更好地上路。
先引一段 BMW 的標語，也是我本人一直以來很欣賞的幾句文字：前端

路有多遠，只有心知道。
向前走，最美的旅程，就是不斷地經歷。
這一次的抵達，是爲了下一次的出發。
真正的夢想，永遠在實現之中，更是在堅持之中。
與堅持夢想者同行。git

前端前端，上手容易作好難

前文中提到，正確的人生觀和價值觀會成就正確的方法論。在軟件開發行業如此，在前端開發領域尤爲如此。
有編程經驗的朋友都知道，不管是PC、Android、iOS 或是其它的用戶終端應用程序，想要作出個 Demo 來並非難事。去外面培訓班接受小半年的培訓，基本均可以到職場上混口飯吃，可是你願意一生只作實現功能的「小工」嗎？我想，但凡是有點志向的都會 Say No。那麼咱們如何提高本身呢？
我我的最熟悉 Android App 開發了，就拿 Android App 開發舉例吧。要想從「小工」變身爲「專家」真的不是一件易事。你多少得讀些 Android 源碼吧？多少得明白點框架的實現原理吧？多少得懂點性能優化吧？多少得有點重構的經驗吧？多少得能本身搞得定一個 App 的架構搭建吧？除了這些以外，多線程、事件分發、單元測試……這些可不是一個僅能實現功能的開發者能作得來的。
你說：「那我學不就完了嗎？」
但問題是：若是你的時間已經被工做填的很滿，而工做內容卻只是實現軟件功能；或者你的自控力不好，閒下來就打遊戲、刷電視劇；或者你真的很用功，學了這個學了那個，然而長時間不用，慢慢地，這些東西就被淡忘了……
怎麼樣？現實老是一次又一次打擊着咱們。編程

作副業，也有坑

「斜槓青年」一詞，相信不少人都聽過，更有甚者嘗試作過。有的人甚至利用工做摸魚的時間開展本身的副業；有的人下了班依舊在接私單；甚至有的人還去跑滴滴掙外快……
實話說，以上三種副業，本人都親自嘗試過，但都有坑。
這些副業看似能夠在短時間內解決燃眉之急——沒錢花，可是從長久來看，是不值得的。先看跑滴滴：開車這種勞動，只要有駕照，對車熟悉些時日，就能夠去接單了。但就目前的形勢來看：至少一線城市，跑滴滴的人愈來愈多，車愈來愈多，錢愈來愈很差掙。「滴滴司機」實際上是一種可替代性很是強的工做。何況，以兼職的方式作滴滴，現在確實已經不合適了。此外，這種工做還會佔據你不少的時間，你徹底能夠用這些時間提高本身的「主要技能」；再說接私單，接私單就回到以前咱們說的重複地使用已有技能狀態了。就比如一我的一生都在掃地，沒時間去發明掃地機器人。
以前看到一篇文章，大概意思就是說幾個好朋友都在同一所大學裏畢業，卻有着不一樣的人生。剛開始作副業的同窗過得真不錯，可隨着時間的推移，事實卻發生了反轉。那些看似一上來作技術深耕的同窗過得很慘，卻在後來脫穎而出，成爲黑馬。這其實並非什麼奇蹟，是前者一直不精進，後者一直在保持更新。當人類總體的技術發生進步時，前者被淘汰是很正常的。
因此說作副業，也有坑。後端

「工程師」思惟或將毀掉你的創業Idea

如今是個大衆創業，萬衆創新的時代，不少人都有一顆去創業，蠢蠢欲動的心。但若是你是工程師出身，我建議你仍是慎重，想好了再行動。
不少工程師在面對客戶需求的時候，會自動採用「自下而上」的思惟模式。即：客戶提出了一個需求 -> 我該採用技術方案A or 技術方案B…… -> 評估開發時間 -> ……。這種思惟方式的產生其實並不奇怪，不少在公司裏待久了的開發工程師，很容易地就會採用這樣一種思惟方式來知足客戶需求，但這實際上是不可取的。
且不說你的技術棧能不能知足客戶的需求，若是客戶往後看到成品，以爲並非他想要的，就會面臨修改甚至推翻重作的後果。這樣的話，不管是甲方仍是乙方，都是痛苦的。
這就要求創業的「工程師」扮演「產品經理」的角色，或團隊裏有「產品經理」角色。由於在討論用戶需求時，可能出現的認知誤差會致使最終的產品和客戶實際的需求不一樣。實際上，也有不少用戶根本也不肯定他想要的產品，究竟是什麼模樣。你可能以爲這很難以想象，沒法理解。如今請你考慮一個問題：在第一代 iPhone 面世前，若是去作用戶調研，問：「你能想象的一部完美的手機，應該是什麼樣的？」固然，不排除有比 iPhone 更好的設計建議，但相信不少人仍是會描繪出一部具備和當時市場流行的外觀相近的模樣的設備，而不會是具備大膽創新的大觸摸屏設備。
別忘了，「大衆創業」後面還有四個字——「萬衆創新」。
相似地，一個被說爛了的例子，用戶想要快一點到達目的地，總說要一匹更快的馬，這個時候，你給了他一匹世界上最快的馬，但仍是會遭到用戶的吐槽，嫌慢，你會怎麼辦？其實，用戶要的並非馬，而是一種可以送他到目的地的更快的方式。這個時候，你或許給他造一架飛機更能知足他的要求（固然要考慮成本等其餘要素）。
因此，正確理解客戶需求的思惟方式，是要理解客戶心裏真正的「需求」，而使用何種技術棧，則是後面要考慮的事情。要記住：技術爲業務服務。一個產品，作得再好，沒人買帳，頂多算是軟件「藝術品」，沒法變現，沒法產生更多價值，這對於公司而言是沒法實現盈利目的的。
運用「自頂向下」的思惟邏輯，是做爲一名前端工程師尤爲要學會的思惟方式，由於前端產品每每是整個系列產品的「門面」，直接和用戶交互。把客戶「伺候」好，是作前端產品的目標；而讓客戶「上癮」，用上停不下來，則是作前端產品的終極目標。性能優化

專心只作一件事最高效

一般，咱們面對一個複雜的前端產品，可能會由於其複雜度、工期短而煩惱。而最快捷的方法是——作好開發計劃，而後無視複雜度。
這其實就是把複雜需求，逐步分解成若干小需求的過程。回想一下剛開始學習編程的體驗，相信有點編程基礎的朋友都還記得那道題——打印三角形，後來它升級了，變成打印菱形，再後來又升級了，打印空心的菱形。代碼邏輯上能夠說是愈來愈複雜，但咱們仍是一步一步地實現了。若是一上來就要求打印空心的菱形，會不會成爲「從入門到放棄」系列呢？
在面對實際需求時，咱們就能夠把一個複雜的需求看作是那個空心的菱形，而後逐步拆解它。在實際開發中，咱們只關注當下的難題。好比，解決打印單個三角形的問題，解決空心的問題等等。相信我，若是你的思惟能力符合正常人類的思惟能力，你不可能在同一時間照看到一個複雜軟件產品的方方面面。作着 A 需求同時還想着 B 需求，大機率作很差 A ，也想很差 B 。
因此，在有開發計劃的前提下，作好天天該作的，就是效率最高的方式了。前端框架

不要小看代碼規範

前端和後端的一個很大的區別就是前端產品具備很強的「操做不定向」性。你永遠也不會猜到用戶會以怎樣的操做組合來使用你的產品。
當你在處理某個Bug時，它所影響的可能不只僅是出現Bug的功能。作過開發的朋友都知道，一段代碼的做用和具體邏輯，就算是寫它的人，過兩個禮拜也會把它忘乾淨。因此，諸如代碼註釋等代碼規範問題，咱們一樣要引發重視。
我曾經在作代碼優化的過程當中就踩過相似的坑，一個方法體裏面的代碼看似無用，實際上當這個方法被不一樣的代碼調用時，這段看似無用的代碼會對特定的傳入參數作特定的處理。致使我當時花了大把的時間，才發現其中的端倪。若是在開發期間註明，在後期維護時就會節省時間成本。固然，這仍是好的結果，至少在我這一關發現了問題。一旦流入到用戶手中，就將成爲Bug存在。原來的目的是優化，結果弄巧成拙。微信

學習前端框架，究竟是在學什麼

隨着技術的不斷更迭，以及某種技術的使用狀況，咱們會淡忘一些不經常使用的技術。這些「不經常使用的技術」並不是不流行，它可能只是咱們當前工程不使用而已。那麼問題就來了：咱們學了一個又一個前端框架，到底在學什麼呢？
答案是——思想。
就拿三大Web前端框架舉例吧，這個有Web前端開發的朋友大概很熟悉了，就是 Angular、React、Vue。可能將來的某一天，有一個更好用的框架替代它們，那麼學習它們的目的是什麼呢？
即便有一天，它們被替代，或者很久不用，把 API 都忘到腦後，但雙向綁定，你還記得吧？組件化，你還記得吧？沒錯！框架不重要，重要的是「思想」。這些思想纔是每一個框架最有價值的部分。前端工程師

正確看待項目代碼的「不完美」

求職到一家公司，可能大部分時間是在對現有版本進行Bug修復。看到寫得比較爛的代碼，咱們可能會下意識地吐槽幾句。可是吐槽彷佛沒什麼用，仍是得鑽進去修修補補。
那麼，咱們應該以何種態度，看待已有項目的種種「不完美」呢？
首先，你要明白，這個世界上不存在所謂「完美」的事物。咱們想要打造並使用一個沒有Bug的軟件產品，這是一個很好的願望。但很遺憾，這只是願望。世界上不存在沒有「Bug」的軟件產品，對於前端產品而言更是如此。正如前文所述，用戶的操做具備很強的不定向性。
對於「爛代碼」，它可能真的漏洞百出，也可能採用了過期的技術，致使程序運行效率低下。這實際上對於前端開發者而言也是一個「福音」，由於這正是一個鍛鍊的機會。咱們能夠對其重構，熟悉使用一種新技術等等。試想一下，若是公司的產品已經足夠完善，那留給咱們鍛鍊的機會也就少了。
因此，正視代碼的缺陷，珍惜每一次鍛鍊的機會。最後別忘了：尊重那個留下爛攤子的人。多線程

寫在最後

在本文的最後一部分，我要告訴你的是：那些編程知識，框架的 API 等等，只佔了一個前端開發工程師所有技能的20%，剩下的80%就是這些看不見的「實力」。就好像 Photoshop 其實不少人都會用，可是能真正產出大做的卻寥寥無幾。換言之，編程技術只是「工具」，而可否用好這些工具纔是最關鍵的「能力」。
最後，衷心但願各位在各自的職業發展道路上越走越好。架構