先作个简单的自我介绍:本人(大名:萧文翰),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 的架构搭建吧?除了这些以外,多线程、事件分发、单元测试……这些可不是一个仅能实现功能的开发者能作得来的。
你说:“那我学不就完了吗?”
但问题是:若是你的时间已经被工做填的很满,而工做内容却只是实现软件功能;或者你的自控力不好,闲下来就打游戏、刷电视剧;或者你真的很用功,学了这个学了那个,然而长时间不用,慢慢地,这些东西就被淡忘了……
怎么样?现实老是一次又一次打击着咱们。编程
“斜杠青年”一词,相信不少人都听过,更有甚者尝试作过。有的人甚至利用工做摸鱼的时间开展本身的副业;有的人下了班依旧在接私单;甚至有的人还去跑滴滴挣外快……
实话说,以上三种副业,本人都亲自尝试过,但都有坑。
这些副业看似能够在短时间内解决燃眉之急——没钱花,可是从长久来看,是不值得的。先看跑滴滴:开车这种劳动,只要有驾照,对车熟悉些时日,就能够去接单了。但就目前的形势来看:至少一线城市,跑滴滴的人愈来愈多,车愈来愈多,钱愈来愈很差挣。“滴滴司机”实际上是一种可替代性很是强的工做。何况,以兼职的方式作滴滴,现在确实已经不合适了。此外,这种工做还会占据你不少的时间,你彻底能够用这些时间提高本身的“主要技能”;再说接私单,接私单就回到以前咱们说的重复地使用已有技能状态了。就比如一我的一生都在扫地,没时间去发明扫地机器人。
以前看到一篇文章,大概意思就是说几个好朋友都在同一所大学里毕业,却有着不一样的人生。刚开始作副业的同窗过得真不错,可随着时间的推移,事实却发生了反转。那些看似一上来作技术深耕的同窗过得很惨,却在后来脱颖而出,成为黑马。这其实并非什么奇迹,是前者一直不精进,后者一直在保持更新。当人类总体的技术发生进步时,前者被淘汰是很正常的。
因此说作副业,也有坑。后端
如今是个大众创业,万众创新的时代,不少人都有一颗去创业,蠢蠢欲动的心。但若是你是工程师出身,我建议你仍是慎重,想好了再行动。
不少工程师在面对客户需求的时候,会自动采用“自下而上”的思惟模式。即:客户提出了一个需求 -> 我该采用技术方案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 其实不少人都会用,可是能真正产出大做的却寥寥无几。换言之,编程技术只是“工具”,而可否用好这些工具才是最关键的“能力”。
最后,衷心但愿各位在各自的职业发展道路上越走越好。架构
还有一件事要交代给各位,若是你有兴趣学习大前端,我为你准备了一条从小工到专家的学习路线,是一篇图文课。涵盖了大前端学习的方方面面,主要包含如下内容。
连接:大前端学习之路