鹅厂6年在职架构师告诉你如何成为iOS大牛开发者【进阶篇】

序言:

如果从 13 年移动客户端大火开始算起,至今已经有五个年头了。现在移动端的形势也不需要太多的废话来描述,一句话总结就是:“浪潮退去,谁在裸泳一看就清楚。”我希望借助这篇文章来聊聊在我心目中,移动互联网下一个五年的趋势和机会,以及我们 iOS 工程师能做哪些准备,实现自我提高。本文主观性的看法比较多,文笔也比较激进,仅供参考。

我们都知道价格会受到供需的影响,如果某项技能在市场上紧缺,那么掌握这门技能的工作者工资就会相对高一些,比如 14 年前前后能写好 UITableView 就能找到一个相对不错的工作了。在我看来,未来几年的移动互联网,会出现“一个过剩,两个不足”,我会逐个分析并试着给出一些建议

在这里小编附带一些iOS开发的学习资料和面试题,至于其他资料视频我就不一一截图了,需要的可以加我新群领取 711413569

(一)UI 工程师过剩

这一点是我老生常谈的了,首先要注意的是避免成为 API 调用工程师,因为这些 UI 方面的知识对个人价值的增长不是线性的,如果你还记得高中数学,请回忆一下 y = ln(x) 这个函数的曲线。从零到写好 UITableView 给一个工程师带来的收益,远远不是从写好 UITableView 到写好 UIStackView 能比得上的。

就以 UIStackView 为例吧,先不说它从 iOS 9 才开始支持,而要想应用不支持 iOS 9,怕是要等到猴年马月了。就说它提供的功能,虽然简化了已有场景,但这个功能完全可以通过封装已有的组件来实现,相信很多大型项目都有,为什么还要费力气去兼容版本,以及再学习一个新的 API 呢?人的精力是有限的,如果你总是追着苹果的脚步,每年补 WWDC 上那些新坑和老债,那么视野就永远只能停留在 iOS 中了。

(二)专业技能人才不足

这里的专业技能指的是移动端这个大话题中里比较垂直的知识领域,大概包含以下几个方面:

1、图像/视频处理

随着网络基础设施的普及,以及流量费用的大幅度降低,4G 基本上已经全面商用了,如果说移动端前五年是文字为主,图片视频为辅的话,在接下来的几年中,用户对高质量图片和视频的要求会日益增长。

由于我对这个领域并不了解,所以能够推荐的并不多,在我印象中,OpenGL 这种跨平台的引擎,计算机图形学的知识,视频编码与协议都是可以花时间研究的,现在有很多优秀的创业公司也急需这类人才。严格来说这些知识都不算移动互联网方面的知识了,所以门槛较高,但门槛这东西是个双刃剑。它会增加你的学习难度,但一旦你掌握了这门知识,门槛又会变成你个人价值的护城河。

我格外想要声明的是,CoreAnimation 这类的东西如果不是工作中强制要用,一般就别碰了,就像没人会傻到用 SpriteKit/SceneKit 去写游戏一样,这种 API 密集型,又不能跨端的库是没有前途的,真正有价值的动画一定是用一套统一的 DSL(领域特定语言)去实现,然后导出到各个平台上,所以开发者一定要多在动画的原理上下功夫,比如了解矩阵变换,线性代数这些,而不是把时间浪费在阅读官方文档上。

2、逆向工程

研究逆向工程的作用不仅仅是破解 app,在我看来更多是学习底层的操作系统。在开发 app 的过程中,我们使用系统提供的库,调用 API 就可以实现需求,其中的过程完全是黑盒。而逆向工程的目的就是要开盒子,利用一些工具从二进制层面入手,反过来推测应用开发者的代码和逻辑。这其中会涉及到很多 C 语言,操作系统,编译原理方面的东西,相对来说门槛很高。逆向工程对企业对价值也很大, 因为大家都不希望自己被竞争对手一眼看穿,又对竞争对手对秘密颇感兴趣。

以上的内容都可以花时间研究的专业知识。这些知识大多是自成体系的,没有较长时间的积累,很难入门。这一点非常重要,因为很多知识看起来非常专业,门槛也很高,比如我下一节就会提到这样的例子,但这些知识我并不鼓励学习。区分的标准是,你学习的知识是一个知识点还是一个体系,如果你学习的只是知识点, 那么它只能是整个知识树上的枝枝丫丫,边边角角,如果你学习的是知识体系,就具备了衍生知识点的能力,也就是我反复强调的举一反三的能力。

上面举的两个例子都是我认为不容易遭到时间的淘汰,比较值得研究的话题。在这些领域上的投入可以理解为线性的,也就是一分耕耘,一分收获。

(三)全栈人才紧缺

这里的全栈没有明确的定义,并非前后端通吃才算是全栈。在我的理解中,只要是跨知识点的融合,都算是全栈,因为跨知识点的融合往往会产生 1 + 1 > 2 的效果。往小了说,全栈可以减少大量浪费在沟通上的时间。往大了说,一个人了解的领域越多,他就越能把这些领域融合在一起,既能站在更高的角度思考问题,也能作为团队的领导者和融合剂。这也就意味着,掌握全栈知识对个人价值的影响是指数形势的,你了解的越多,价值就会越快的提高,职业天花板也会越高。

很多技术是与业务绑定的,有了核心知识,在业务需求的推动下,很容易就会诞生一个框架。比如应用组件化,很多公司都有自己的组件化库,其实实现原理也就是两大类,但发表到博客里面以后,就会有非常多的业务背景干扰读者的认知,如果读者追着这类文章看,是非常难从框架中剥离业务的干扰,直接挖掘基本原理的。因此大公司搞出来的某些框架,真的没有那么神秘,早期都是一个简陋的基础框架,当面对业务业务需求时,运用一些合理的编程思想,逐步迭代,最后发布了一个完善的版本,大可不必看得晕头转向以后妄自菲薄。

在之前面试的过程中,我也注意到很多应聘者其实对技术很感兴趣,经常刷微博上的文章,了解的也很多。但大多数情况下只知其然,不知其所以然。这是因为这些技术偏离了你的应用场景。以前我总为微博上的好技术无法在项目中落地感到纠结,后来我突然就明白了,这个思路就是错的,我应该挖掘公司项目的痛点,去微博,Google 等平台上的文章中寻找解决方案。所以我反对面向微博学习,应该要学一些更通用的技术,把技术与自己的项目结合起来,争取能在项目中落地,这比看十篇似懂非懂的技术文章还管用。

(四)大公司所谓的基础知识

为什么建议不要研究单独的几个底层知识点,除了这种知识,以及逆向工程这种自成体系的,求职者只要具备扎实的基础,牢牢掌握一些基础知识就可以了。很多人都会觉得大公司对底层的基础知识考察很严格,基础知识不表示底层,也不一定就很简单,它们通常是那些被框架做了一层封装,以至于如果不用心思考,很可能就会忽略的知识,但不了解这些知识会对你的思考产生较大的影响,也很容易栽进某个坑里。

除非是变态公司以偏题怪题刁难人为乐,或者无能面试官只会问自己懂的东西以外,正常的大公司面试都会考察一些比较基础的问题,如果你还是觉得题目太底层,只能说明自己看问题的角度还不够深刻。

大公司着重考察基础知识,在我看来有两大原因:首先,在比较大型的项目中,业务逻辑非常复杂,所以很少有人有精力去大量的检查并提高你的代码质量,这就要求工程师具备相当扎实的代码功底,无论是代码风格还是语言的掌握都不能有太多问题。这样 Code Review 的时候才能把精力放在业务检查上,代码风格一笔带过,偶尔提醒一下就可以了。

另一方面,基础知识决定一个人思考问题的深度和交流问题的角度。一个不懂计算机背景知识的程序员,看问题的方式经常是错误的,错误的思考方式也就决定了他很难走到正确的道路上,比如我的一个外行朋友曾经接手了一个用 C++ 实现的 GUI,他的第一个问题是“如何在 C++ 中把字符串加粗”,读者大可不必感到荒谬,因为很多人思考问题的方式也不见得高明,在高水平,有经验的程序员看来,也许同样是不可理喻的。大公司复杂的业务逻辑同样也意味着很少有人会耐心的给你讲解每一个名词,比如哈希表,并发,并行,编译,链接等等名词,如果你听不懂或者理解不正确,往往意味着交流上会存在一些障碍。

因此我的建议是:数据结构,操作系统,计算机网络中的基础知识一定要扎实,怎么扎实都不为过,因为它决定了你看问题时候的高度,深度和思路。

(五)让脚本取代 GUI

脚本语言非常重要,绝对是提升工作效率的神器,我强烈建议每个客户端工程师都应该了解一些 Shell 脚本并且掌握 Python,Ruby 和 JS 中至少一门语言。

理论上来说没有什么是脚本语言做得到,Java 做不到的,但脚本语言最大的特点就是快,快到极点的那种快。对于一些极度简单的小需求,比如统计一个文件中某一列数字的平均数,我敢保证在我得出结果之前你肯定还来不及打开 Java 编辑器。

脚本语言的另一个特点是高度的自动化,只要 Unix 和 Linux 系统一天不死,shell 脚本就会永远存活,你学习的知识就永远不会过期,比如 awk 和 sed 这样的神器,年龄比我大得多,至今还非常实用,未来的 20 年也丝毫看不出淘汰的迹象。试问一下,有什么知识能比一个几十年不会过期,而且每天都能用上的知识更值得学习呢?由于 Shell 是距离操作系统最近的脚本,了解了它以后,很多复杂的操作都可以被自动化。比如想找到项目中无用的图片,也就是一行命令的事。

考虑到脚本语言极高的开发效率,很多对性能不敏感的框架都会选择用脚本语言来实现,比如 Node,Flask,Rails,mitmproxy 等等。作为一个大前端工程师,不能总是依赖后端工程师,否则没了后端就只能搞单机模式了。因此了解脚本语言还有iOS助于我们快速上手后端框架,这绝对是应聘时的加分项。

当然,很多人也会抱怨,我们是 iOS 工程师,平时的工作也接触不到脚本语言,该如何学习并投入使用呢。我的建议有三个:

1、整理自己的痛点, 并尝试着用过脚本去解决,这对学习 Shell 有奇效

2、整理公司项目开发中的痛点,尝试着用脚本去解决,适合练习 Python,Ruby 和 JS

3、抛弃 GUI

GUI 诞生的目的是为了更好的显示信息,而不是成为技术残疾者的拐杖。举一个简单的例子,我发现很多人都装了很多编程效率方面的工具,比如 gitx,sourcetree,tower 之类的 git 工具,还有什么快速打开模拟器目录,Derived Data 目录的小工具,我觉得这实在是太愚蠢了。放着大好的学习 Git 和 shell 的机会不要,把时间浪费在了解一个软件的 GUI 上,我觉得是完全不能接受的。尤其是对于 git 来说,我建议多问问自己,学会的是 git 还是 sourcetree 的按钮,将来换一个 GUI 工具,毕生功力还剩几成?至于某些小工具,这种绝佳的练手机会,怎么能拱手相让给别的软件呢,尤其是脚本可以自动化,软件就几乎不可能了。

啰啰嗦嗦说了很多,其实总结下来没几点:

1、学习一个技术之前不妨先思考一下它在整个互联网体系中目前的位置,有什么样的未来,会对个人价值有多大的提高

2、数据结构,操作系统,编译原理,计算机网络这些基础知识不能丢,它决定了你看问题时候的高度,深度和思路

3、未来需要特定技术领域里的专才,更需要全栈,归根结底是需要最大化自己的价值。我个人的建议是掌握好脚本语言提高效率,打通前后端,这样无论在外包,独角兽创业公司还是大公司,都能独当一面

4、学习新技术时要避免好高骛远或者盲目迷信大厂,转发或艾特印象笔记提高不了自己,要结合实际场景,最重要的是要能落地!

在这里小编附带一些iOS开发的学习资料和面试题,至于其他资料视频我就不一一截图了,需要的可以加我新群领取 711413569

原文地址:http://blog.51cto.com/13800182/2126836

时间: 2024-10-29 02:53:10

鹅厂6年在职架构师告诉你如何成为iOS大牛开发者【进阶篇】的相关文章

8年iOS架构师告诉你,为什么iOS现在不行了!

前言: 在近一段时间里,笔者会经常听到在职iOS开发人员的各种吐槽,各种无奈,各种对于iOS市场唱衰,更是在某度搜索引擎上随便一点iOS就是各种负面新闻,事实上,经过笔者的一番了解,断定其实你们看到的一定是个假iOS! 如果你的工作只是为了赚钱, 不管换什么工作,只要过个一两年到了瓶颈期,你都会有类似的感觉,请不要随意怀疑一个行业的高峰或者低潮期,请正视自己,正视一个行业. 做为一个开发者,有一个学习的氛围跟一个交流圈子特别重要这是一个我的iOS交流群:638302184,不管你是小白还是大牛欢

阿里架构师告诉你最新Java架构师学习路线图

1.Java架构师是什么?要想往Java架构师的方向发展首先要知道Java架构师是什么?Java架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物.一个Java架构师得需要足够的想像力,能把各种目标需求进行不同维度的扩展,为目标客户提供更为全面的需求清单.Java架构师在软件开发的整个过程中起着很重要的作用.说的详细一些,架构师就是确认和评估系统需求,给出开发规范,搭建系统实现的核心构架,并澄清技术细节.扫清主要难点的技术人员.主要着眼于系统的"技术实现

阿里P8架构师告诉你什么是分布式架构

一.前言 我们都知道,当今无论在BAT这样的大公司,还是各种各样的小公司,甚至是传统行业刚转互联网的企业都开始使用分布式架构,那么什么叫分布式架构呢?分布式架构有什么好处呢?分布式架构经过了怎样的发展呢?是哪家企业开启了分布式架构的时代呢?读完本文,你就会得到这些答案,下面让我们一起来开启分布式概述的奇妙之旅吧! 二.分布式架构的发展历史 1946年2.14日,那是一个浪漫的情人节 , 世界上第一台电子数字计算机在美国宾夕法尼亚大学诞生了,她的名字叫ENIAC.这台计算机占地170平米.重达 3

10年架构师告诉你,他眼中的Spring容器是什么样子的

相关文章 如何慢慢地快速成长起来? 成长的故事之Spring Core系列 你是如何看待Spring容器的,是这样子吗? Spring的启动过程,你有认真思考过吗?(待写) 面向切面编程,你指的是Spring AOP吗?(待写) Spring的声明式事务,这次你彻底明白了吧?(待写) §如何提问,如何回答? 记得大学时,思想道德修养课的老师说过,现在的大学生都不太会表达自己的观点.她举了这么个例子,如果你在食堂,随机采访几个学生,就问:“你觉得食堂的饭菜怎么样啊?” 你得到最多的答案大概是像这样

阿里P7架构师告诉你Java架构师必须知道的 6 大设计原则

在软件开发中,前人对软件系统的设计和开发总结了一些原则和模式, 不管用什么语言做开发,都将对我们系统设计和开发提供指导意义.本文主要将总结这些常见的原则,和具体阐述意义. 开发原则 面向对象的基本原则(solid)是五个,但是在经常被提到的除了这五个之外还有 迪米特法则和合成复用原则等, 所以在常见的文章中有表示写六大或七大原则的: 除此之外我还将给出一些其它相关书籍和互联网上出现的原则: S单一职责SRP Single-Responsibility Principle, 一个类,最好只做一件事

添物零基础到大型全栈架构师 不花钱学计算机及编程(预备篇)- 概述

不花钱学计算机及编程 (预备篇) --概述:如何学习计算机及编程 个人是98年进入大学,开始学习计算机的,当时对计算机等于零了解,只有初中的时候在镇上一个同学家见过,当时放卡拉OK听,别的也不知道什么了,高中的时候学校有校友会捐赠不少计算机,可是没让我们摸过.到大学连回车是什么都不知道,当时学校还是DOS操作系统,Windows也有好像是Windows3.1,不过很简陋. 学了几年大学,基本对计算机有个感性认识,理性认识不是太多,虽然学了计算机基础,计算机组成原理,计算机体系结构,C语言,操作系

.NET 高级架构师0003 架构师之路(2)---架构师的职责

2 架构师的职责 近来看到CSDN上有个CTO俱乐部,里面聊得是不亦乐乎.我怀着无比崇敬的态度,拜读了一下牛人们的发言.里面有个哥们发起一个话题:"CTO, 你多久没有写程序了?".有人回答:"不写代码的CTO,属于......这公司问题大了!".看到这里,我就赶紧撤了,怕忍不住反驳几句,反而遭到牛人们的群殴.试想,一个上点规模的IT公司,还得靠CTO来写程序的话,那是不是才叫问题大了呢.当然,我没有做过CTO,所以我有我的不同看法,而且还愿意表达出来,无知者无畏.

系统架构师-基础到企业应用架构-系统建模[中篇](上)

一.上章回顾 上篇文章主要简单的介绍了建模中使用的标准建模语言UML的相关内容,包括用例图与类图的使用方法及如何建模.相信大家对UML建模语言已经有了初步的认 识,还请大家谨记UML不同的建模图形的用处.比如,用例图主要用来描述系统的功能需求.类图主要用来描述实体间的关系.谨记这些就可以帮助我们在系统架构的 过程中深入的分析. 首先向大家道歉,上篇中有部分描述错误的地方,可能对大家造成一定的错误引导.  这是上篇给出的图,我描述的是组合关系. 特别更正为:  这是正确的结果.箭头指向聚合类.描述

如何从普通程序员晋升为架构师 面向过程编程OP和面向编程OO

引言 计算机科学是一门应用科学,它的知识体系是典型的倒三角结构,所用的基础知识并不多,只是随着应用领域和方向的不同,产生了很多的分支,所以说编程并不是一件很困难的事情,一个高中生经过特定的训练就可以做得到.但是,会编程和编好程绝对是两码事,同样的程序员,有的人几年之后成为了架构师,有的人却还在不停地coding,只不过ctrl-c.ctrl-v用得更加纯熟了.在中国,编程人员最终的归途无外乎两条:一是转向技术管理,它的终点是CTO:二是继续深入,它的终点是首席架构师,成为CEO的人毕竟是少数.如