先做個簡單的自我介紹：本人（大名：蕭文翰），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 的標語，也是我本人一直以來很欣賞的幾句文字：
路有多遠，只有心知道，
向前走，最美的旅程，就是不斷地經歷，
這一次的抵達，是為了下一次的出發，
真正的夢想，永遠在實作之中，更是在堅持之中，
與堅持夢想者同行，
前端前端，上手容易做好難
前文中提到，正確的人生觀和價值觀會成就正確的方法論，在軟體開發行業如此，在前端開發領域尤其如此，
有編程經驗的朋友都知道，無論是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 其實很多人都會用，但是能真正產出大作的卻寥寥無幾，換言之，編程技術只是“工具”，而能否用好這些工具才是最關鍵的“能力”，
最后，衷心希望各位在各自的職業發展道路上越走越好，
One More Thing
還有一件事要交代給各位，如果你有興趣學習大前端，我為你準備了一條從小工到專家的學習路線，是一篇圖文課，涵蓋了大前端學習的方方面面，主要包含以下內容，
- 為什么要學習大前端；
- 上手大前端，都需要做哪些準備；
- 大前端的初、中、高級階段概述；
- 進擊初級Web前端工程師之路；
- 進擊中級Web前端工程師之路；
- 進擊高級Web前端工程師之路，
鏈接：大前端學習之路
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/49628.html
標籤：其他
上一篇：常見的Dos命令大全