先做个简单的自我介绍：本人（大名：萧文翰），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前端工程师之路。
链接：大前端学习之路