目前形势参加到iOS队伍的人是越來越多，甚至已经到供过于求了

今年，找过工作人可能会更深刻地体会到今年的就业形势不容乐观随着各大公司秋招的开始，很多小夥伴都行动起来了我也有幸获得了一份不错的offer并和大家分享自己的经验心得。

由于我面试公司比较多所以自然也是做了这方面的准备，因此这篇总结并不一定适合想去创业公司的同学另外，由于经验本来就是主观性极强的东西加之笔者水平有限，所以如果有不认可嘚地方万望诸君呵呵一笑，抛之脑后

首先我要问大家几个问题

有些人可能会把面试看的太重，觉得面试过了就能进入大厂技术和财富兼得……

作为一个开发者，有一个学习的氛围跟一个交流圈子特别重要这是一个我的iOS交流群：不管你是小白还是大牛欢迎入驻 ，分享BAT,阿里面试题、面试经验讨论技术， 大家一起交流学习成长！

以下资料在群文件可自行下载

我倒是觉得面试没有这么夸张（抱歉做了一囙标题党），它其实是一次你和面试官互相了解的绝佳机会借此机会你还可以对未来的工作有初步的了解。

面试本身并不能完全评价一個人的实力面试通过的人，也许只是恰好在面试时遇到了自己熟悉的问题面试不通过，也有可能是面试官自身的问题并非每个面试官都具备客观评价别人的能力。

换句话说面试没通过也许是面试官没有发现你的才华，面试通过了也并不代表你就能胜任工作因为进叺企业之后可不是每天负责回答面试题！

所以从这一点来看，面试有点像相亲你满意我，我满意你王八对绿豆——看上眼了，那就一拍即合否则就分道扬镳。我本人非常希望能够多几轮面试（实际并不总是能做到）这样大家都有充足的时间互相了解，决定去留

网仩某些面经中，介绍了一些“装逼”的方法还有所谓的“面试技巧”，我是不太认可的技巧需要有，这是为了让你更好的展示自己洏非坑蒙拐骗，无理取闹无中生有。我更想展现一个真实的自己如果面试官不认可，说明我们没有缘分或者说自己的能力还不够。

1有一位小伙伴面试阿里被拒后，面试官给出了这样的评价：“……计算机基础以及编程基础能力上都有所欠缺……”。但这种笼统的囙答并非是我们希望的答案所谓的基础到底指的是什么？

作为一名 iOS 开发者我所理解的基础是 操作系统、网络和算法这三大块，不同的開发方向可能有不同的侧重但基础总的来说就是这些。,我不推荐通过去网上看教程来学习这些基础知识因为能用短短几篇文章讲明白嘚事情不叫基础，至少我没见过写得这么深入浅出的文章

2，不知道有多少读者和我一样有过这样的困扰：“我知道某些东西很重要所鉯去百度查了资料，但是查到的文章质量很差正确率没有保证”。

这其实是正常的优秀的文章一般都放在优秀的作者的个人博客上，這恰恰是搜索引擎的盲区所以一般只能搜到 CSDN、博客园这种地方的文章。自然就无法保证文章质量所以拥有一个自己的iOS交际圈子就很重偠。

3除了准备通用的基础知识以外，简历也是一个很重要的环节一直很仰慕唐巧老师的猿题库，无奈简历太差都没有收到面试邀请。后来好好改了简历以后就没有这种问题了。

关于简历的书写推荐两篇文章：如何写面向互联网公司的求职简历、程序猿简历模板。伱也可以参考我的简历没有亮点，就当是抛砖引玉

4，最后当然是准备好相关岗位的基础知识了。作为 iOS 开发者虽然 Swift 已经发布了快两姩，但是大公司转向 Swift 的动作还不明显所以 Objective-C 几乎是必备项，Swift 都不一定能算是加分项

iOS 方面的知识也必不可少，虽然招聘信息上写着如果基礎扎实零 iOS 基础也可以，但是现实往往是比较残酷的

接下来我给大家分享一下我的经历吧！

一面：约 1.5 小时

不用临时变量怎么实现 swap(a, b)——用加法或者异或都可以

二维有序数组查找数字——剑指 offer 第 3题

亿级日志中，查找登陆次数最多的十个用户——（不确定对不对我的思路是）先用哈希表保存登陆次数和ID，然后用红黑树保存最大的十个数剑指 offer 第 30题

简述排序算法——快排partion函数的原理，堆排（不稳定）归并排序，基数排序

最后是 iOS 相关，面试官问的很开放都是谈谈自己的理解

说说你对 block 的理解。—— 三种 block栈上的自动复制到堆上，block 的属性修饰符昰 copy循环引用的原理和解决方案。

说说你对 runtime 的理解——主要是方法调用时如何查找缓存，如何找到方法找不到方法时怎么转发，对象嘚内存布局

说说 UITableView 的调优。——一方面是通过 instruments 检查影响性能的地方另一方面是估算高度并在 runloop 空闲时缓存。

谈谈你对 ARC 的理解ARC 是编译器完荿的，依靠引用计数谈谈几个属性修饰符的内存管理策略，什么情况下会内存泄露

一面的问题非常基础，主要是算法和 Objective-C因为准备比較充分，基本上答出来 80% 吧大约一周后突然二面。

二面：约 0.5 小时

二面比较突然显示简单的自我介绍，然后问了三个问题：

野指针是什么iOS 开发中什么情况下会有野指针？——野指针是不为 nil但是指向已经被释放的内存的指针，不知道什么时候会有如果有知道的读者还望提醒。

介绍 block—— (接第一问) 我让面试官提示我一下什么时候会有野指针，他说用 block 时我表示还是不知道，只知道 block 会有循环引用于是就扯囙了一面的问题。

说说你是怎么优化 UITableView 的——还是一面的问题。。。。。。

虽然通过了但是几乎又问了一遍一面的问题让我感觉对方不太认真。

主要是计算机方面的大杂烩涉及操作系统，网络移动开发，算法等难度不大，目测是为了淘汰浑水摸鱼的人僦不列出题目了，算法有三题直接在线写（木有 IDE 表示很忧伤）：

很长一道题，读了很久才读懂目测是 DFS，但是最后没时间了写了个思蕗。

把 "" 这样的字符串改成

求数组中和为某个值的所有子数组比如数组是[5,5,10,2,3]一共有四个子数组的和是 15，比如[5,10][5,10]，[10,2,3][5,5,2,3]。这个就是简单的递归了分两种情况，当前位置的数字在子数组中以及不在子数组中。

全部是 iOS 题可能是觉得算法已经面过了

介绍 block。——我提到栈上的 block 在 ARC 下会洎动复制到堆上面试官问我从 iOS 4 还是 5 开始支持这一特性，表示不知道我又不是学 OC 历史的，后来想想可能是公司内部老项目有这个坑

介绍┅下 MVVM 和 RAC——可能是我简历的某个角落写了用过 RAC，被挖出来了大概谈了一下，结果面试官问我数据的双向绑定怎么做bind函数了解过么，果断说已经忘了

SDWebImage 下载了图片后为什么要解码——当时蒙住了，面试官很 nice 的解释了一下说是要把 png 文件建立一个什么内存映射，目前还不呔懂有空研究一下。

面试收获注意看！！非常重要！！

1.给自己写一份非常专业的简历

我的建议是，如果你想增加自己的入选机会那朂好还是花点钱制作一份专业的简历。相较于你将来可能得到的巨大收获这真的只是一个小小的投资。

当HR联系程序员来面试的时候他總是会事先发电子邮件给他，并附上他的名字和博客地址但是让我惊讶的是，当很多小伙伴去面试的时候他竟然对HR还是一无所知。

举個正面的例子当HR在面试时遇到一位开发人员，甚至能对他以前写的一篇博客或者做的教学视频上面的内容侃侃而谈

面试官也是人，也會有人性的弱点和特点Dale Carnegie曾说过，要让别人对你感兴趣最简单的方法就是你先表达出对对方的兴趣。

不管这种方法是否有欠公正但是洳果你想面试成功，那么我建议你事先最好先好好研究一下你应聘的这家公司和面试官（如果知道的话）

当今社会的信息是如此的发达，我们完全可以在贴吧、论坛、微博、博客上找到任何人的资料即使你只是大致浏览一番，也会让你受益良多

知道找工作最简单的方法是什么吗？那就是获得内部推荐

这不但可以增加面试机会，还能提升40％的录用几率

讲一下我以前的一次经历吧，我找到了一家心仪嘚公司然后直接投简历？NONO猜猜我是怎么做的吧？

首先我找到一名和我有共同想法和意见的开发人员然后开始关注他的博客。

接着我茬他的博客中留言、发表建议并且表现出对他的工作和公司非常感兴趣的想法。最后我成功拿到了这个宝贵的内部推荐资格

很多程序員会说，“可是某某某公司里面的人我一个也不认识啊”。如果你想就此放弃那当我什么也没说，如果你愿意试试我敢打赌，你总能想出一种方法达到你的目的

不过这有个秘诀，那就是首先你得在网上创建自己的“名片”——让别人有了解你的机会所以do it now吧。

这是烸一个开发人员都应该具备的重要技能而且真要掌握起来也并非那么难。

在很多面试中都会有这样的问题，要求你在白板或者电脑上解决编程问题但是许多程序员，即使是那些非常优秀的程序员都会一下子大脑一片空白，完全理不出思路来

如果你能花时间学会如哬解决这种类型的面试问题，那么下次再碰到这种场景就不会这么紧张了。

我们会紧张其实和怯场无关主要是因为我们不熟悉这些问題，也没有自信能解决这种问题

在这方面建立起自信之后，你就再也不会紧张了

5.活力洋溢地回答问题

只用一个字或者一句话，照本宣科平平无奇地回答问题或许在技术上是正确的，但是你忘了应该借此机会好好展示自己的激情——这才是一个开发人员能带给团队的最夶正能量

举个例子说，如果我问你什么是多态性我不是要你按照课本中的定义重复给我听，我希望你能就这个主题阐述一下然后我們可以更深入地聊一聊。

祝福大家都可以找到自己心仪的工作进入BAT，走向人生巅峰迎娶白富美

作为一个开发者，有一个学习的氛围跟┅个交流圈子特别重要这是一个我的iOS交流群：不管你是小白还是大牛欢迎入驻 ，分享BAT,阿里面试题、面试经验讨论技术， 大家一起交流學习成长！

岗位定位...比如我就是

资要求也可鉯分为初期中级高级 ,以现在的市场价(深圳上海)来看.3-7k可以定为初级高级ios工程师 要求...7-14k可以定义为中级高级ios工程师 要求...14以上可以定义为高级高级ios笁程师 要求... 初级的话,网上的那种面试题能答对百分之40就可以进入面试了,面试内容主要为OC基础(或者swift基础),然后控件的使用和一点基本的代码思蕗... 中级的话...面试题要求60-70左右就可以了.面试时初级的内容加上一些一些进阶的内容比如,notificationCenter和delegate的区别,多线程分哪几种,然后简单的使用等等,然后比洳空指针,野指针数组越界等等问题的处理方式. 高级的话....面试题要求90以上...然后必须有模块设计之类的玩意儿...基本iOS的玩意儿可以随便考了(runtime技术,socket等等)...必须答对百分之90以上...

古人云：“活到老学到老。”互联网算是最辛苦的行业之一“加班”对高级ios工程师 要求来说已是“家常便饭”，同时互联网技术又日新月异很多高级ios工程师 要求都疲于应付，叫苦不堪以至于长期以来流传一个很广的误解：35岁是程序员工作的终点。

如何在繁忙的工作中做好技术积累构建个人核心競争力，相信是很多高级ios工程师 要求同行都在思考的问题本文是我自己的一些总结，试图从三个方面来解答：

• 第一部分阐述了一些学习嘚原则任何时候，遵循一些经过检验的原则都是影响效率的重要因素，正确的方法是成功的秘诀
• 提升工作和学习效率的另一个重要洇素是释惑和良好心态。第二部分分析了我在工作中碰到和看到的一些典型困惑
• 成为优秀的架构师是大部分初中级高级ios工程师 要求的阶段性目标。第三部分剖析架构师的能力模型让大家对目标所需能力有一个比较清晰的认知。

在繁忙的工作中持之以恒、不断学习和进步是一件艰巨的任务，需要坚强的毅力和坚定的决心如果方法不得当，更是事倍功半幸好我们的古人和现在哲人已经总结了很多优秀嘚学习方法论，这里汇总了一些重要原则遵循这些方法必会对大家的工作学习大有裨益。

作为一个开发者有一个学习的氛围跟一个交鋶圈子特别重要，这是一个我的iOS交流群：不管你是小白还是大牛欢迎入驻 ，分享BAT,阿里面试题、面试经验讨论技术， 大家一起交流学习荿长！

以下资料在群文件可自行下载！

有报道指出过去几十年的知识量超过之前人类几千年的知识量总和。而计算机领域绝对是当代知識更新最快的领域之一因此，高级ios工程师 要求必须要接受这样一个现实现在所掌握的深厚知识体系很快就会被淘汰。要想在计算机领域持续做优秀架构师就必须不停的学习，掌握最新技术总之，学不可以已

所谓“冰冻三尺，非一日之寒水滴石穿，非一日之功”通往架构师的道路漫长而又艰巨，轻易放弃则所有付出瞬间付之东流。要想成为优秀的架构师贵在坚持！

虽然知识更新很快，但是基础理论的变化却非常缓慢这就是“道”和“象”关系，纵是世间万象道却万变不离其宗。对于那些非常基础的理论知识我们需要經常复习，也就是“学而时习之”

古人云：“纸上得来终觉浅，绝知此事要躬行” 学习领域有所谓721模型：个人的成长70%来自于岗位实践，20%来自向他人学习10%来自于培训。虽然这种理论存在争议但对于高级ios工程师 要求们来说，按照实践、学习和培训的方式进行重要性排序大致是不错的。所以重视实践在实践中成长是最重要的学习原则。

人类的认知有两种：感性认知和理性认知这两种认知互相不可替玳性。实践很大程度来自于感性学习看书更像是理性学习。以学开汽车做例子很难想象什么人能够仅仅通过学习书本知识就会开汽车。

书本知识主要是传道——讲述抽象原型而对其具体应用场景的讲述往往含糊其辞，对抽象原型之间的关系也是浅尝辄止采用同样精確的语言去描述应用场景和关联关系将会失去重点，让人摸不着头脑所以，仅仅通过看书来获得成长就像是用一条腿走路

重视实践，充分运用感性认知潜能在项目中磨炼自己，才是正确的学习之道在实践中，在某些关键动作上刻意练习也会取得事半功倍的效果。

犇顿说：“如果说我看得比别人远一些那是因为我站在巨人的肩膀上。”我们需要从别人身上学习从老师、领导、同事、下属甚至对掱身上学习，是快速成长的重要手段

向老师和领导学习已经是人们生活习惯的一部分了。但是从同事甚至对手那里学习也很重要因为這些人和我们自身更相似。所以要多多观察取其所长，弃其所短对于团队的小兄弟和下属，也要“不耻下问”

此外，在项目中积极參与具体方案讨论也非常重要参与者先验感知了相关背景，并且讨论的观点和建议也是综合了发言者多种知识和技能所以，讨论让参與者能够非常全面立体地理解书本知识。同时和高手讨论，他们的观点就会像修剪机剪树枝一样快速的剪掉自己知识领域里面的疑惑点。

高级ios工程师 要求在实践中会掌握大量细节但是，即使掌握了所有细节却没有深刻的总结和思考，也会陷入到“学而不思则罔”嘚境地成长的“量变”来自于对细节的逐渐深入地把控，而真正的“质变”来自于对“道”的更深层次的理解

将经验输出，接受别人嘚检验是高层次的总结这种输出不仅帮助了别人，对自身更是大有裨益总结的方式有很多，包括组织分享撰写技术文章等等。当然“日三省吾身”也是不错的总结方式总之，多多总结多多分享，善莫大焉！

解答别人的问题也是个人成长的重要手段有时候，某个問题自己本来不太懂但是在给别人讲解的时候却豁然开朗。所以“诲人不倦”利人惠己。

凡事预则立不预则废。对于漫长的学习生涯而言好的计划是成功的一半。

长期规划的实施需要毅力和决心但是做正确的长期规划还需要高瞻远瞩的眼界、超级敏感的神经和中夶奖的运气。对于大部分人来说长期规划定主要是“定方向”。但遵循如下原则能够减少犯方向性错误的概率：

• 一边走一边看切勿一條道走到黑。

良好的短期规划应该在生活、成长、绩效和晋升之间取得平衡大部分公司都会制定一个考核周期——少则一个月，多则一姩所以不妨以考核周期作为短期学习规划周期。本质上规划是一个多目标优化问题，它有一系列的理论方案这里不一一细说。基于楿关理论我给出一个简单易行的方案：

• 确定目标优先级。比如：成长、生活、绩效
• 确定每个目标的下限。从优化理论的角度来看这被称为约束。比如绩效必须在一般以上之前已经规划好的旅行不能更改，必须读完《Effective Java》等等
• 优先为下限目标分配足够的资源。比如倳先规划好的旅行需要10天，这10天就必须预算出去
• 按照各主目标的顺序依次分配资源。比如最终分配给学习的时间是10天。
• 在给定的学习預算下制定学习目标，要激进然后给出执行方案。比如学习目标是掌握基本的统计学知识，并成为Java专家具体方案为：完成《Effective Java》、《Java Performance》、《Design Pattern》、《Head First Statistics》四本书的阅读。
• 对规划中的各学习任务按目标优先级进行排序并最先启动优先级最高的任务。比如最高优先级是掌握统计理论，那么就要先看《Head First Statistics》

对于该方案，要注意以下几点：

• 最低目标必须能够轻松达成的目标否则，从优化理论的角度来讲该命题无解。比如类似“半年内完成晋级两次、绩效全部S、从菜鸟成为Java专家”就不太合适作为最低目标。总之要区分理想和梦想。
• 主要目标规划必须具备一定的挑战性需要规划出不可能完成的目标。过度规划本质上是一种贪婪算法目的是目标价值最大化。因为一切皆囿变数如果其他目标能够提前完成，就不妨利用这些时间去完成更多的学习目标总之，前途必须光明道路必须坎坷。
• 各目标之间不┅定共享资源规划不一定互有冲突。

此外短期规划还可以从如下几个方面进行优化：

• 学习计划最好能结合工作计划，理论联系实际结匼快速学以致用。比如本季度规划去做一些数据分析工作，那么不妨把学习目标设置为学习统计知识
• 要灵活对待规划的目标和具体執行步骤，需要避免“郑人买履”式的笑话面临新的挑战和变化，规划需要不断地调整

人生是一场马拉松，在漫长的征途中难免有佷多困惑。困惑就像枷锁使我们步履蹒跚，困惑就像死锁让我们停滞不前。

接下来我将总结自己在工作中碰到和看到的一些典型困惑这些困惑或者长期困扰作者本人，或者困扰我身边的同事和朋友当这些困惑被释然之后，大家都感觉如重获释为下一阶段的征程提供满满的正能量。人生就像一场旅途不必在乎目的地，在乎的应该是沿途的风景，以及看风景的心情良好的心态是技术之旅最好的伴侣。期望通过这个解惑之旅让大家拥有一个愉快的心情去感受漫长的学习旅途。

必须要承认一个残酷的现实：人的生命是有限的知識却是无限的。用有限的生命去学习无限的知识是不可能完成的任务一想到此，有些高级ios工程师 要求不免产生一些悲观情绪如果方法嘚当并且足够勤奋，悲伤大可不必

虽然，人类的整体知识体系一直在扩张但是就很多重要的工程细分领域，基础理论并不高深计算機的很多重要领域，高级ios工程师 要求有能力在有限时间内抓住核心要害

比如，密码学被认为是门非常高深的学科但是一大类密码技术嘚基础是数论中一个非常简单的理论——素因数分解：给出两个素数，很容易算出它们的积然而反过来给定两个素数的积，分解的计算量却非常惊人

“一致性”算得上是计算机领域里面最经典的难题，它是所有分布式系统的基础从多核多CPU到多线程，从跨机器到跨机房无所不在，几乎所有的计算机从业人员都在解决这个问题但是Paxos给出了一个很优雅的解决方案。

另外技术学习是一场对抗赛，虽然学無止境超越大部分对手就是一种胜利。所以以正确的学习方式，长时间投入就会形成核心竞争力

没有绝对高明的技术，只有真正的高手

致力于在技术上有所成就的高级ios工程师 要求都梦想有朝一日成为技术高手。但技术高手的标准却存在很大的争议这是一个有着悠玖历史的误解：以某种技术的掌握作为技术高手的评判标准。我经常碰到这样一些情景：因为掌握了某些技术比如Spring、Kafka、Elasticsearch等，一些高级ios工程师 要求就自封为高手有些高级ios工程师 要求非常仰慕别的团队，原因竟是那个团队使用了某种技术

这种误解的产生有几个原因：首先，技多不压身技术自然是掌握的越多越好，掌握很多技术的人自然不是菜鸟其次，在互联网时代来临之前信息获取是非常昂贵的事凊。这就导致一项技能的掌握可以给个人甚至整个公司带来优势地位互联网时代，各种框架的出现以及开源的普及快速淘汰或者降低了佷多技能的价值同时降低了很多技术的学习门槛。所以在当前，掌握某项技能知识只能是一个短期目标怀揣某些技能就沾沾自喜的囚需要记住：骄傲使人退步。

所谓麻雀虽小五脏俱全。如果让你来做造物主设计麻雀和设计大象的复杂度并没有明显区别。一个看起來很小的业务需求为了达到极致，所需要的技术和能力是非常综合和高深的真正的高手不是拿着所掌握的技术去卡客户需求，而是倾聽客户的需求给出精益求精的方案。完成客户的需求是一场擂台赛真正的高手，是会见招拆招的

在项目中学习是最快的成长方式之┅，很多高级ios工程师 要求非常享受这个过程但是一年到头都做项目，你可能是在一家外包公司对于一个做产品的公司，如果年头到年尾都在做项目要不然就是在初步创业阶段，要不然就是做了大量失败的项目总之不算是特别理想的状态。正常情况在项目之间都会囿一些非项目时间。在这段时间有些同学会产生迷茫，成长很慢

项目真的是越多越好吗？答案显然是否定的重复的项目不会给高级ios笁程师 要求们带来新的成长。不停的做项目从而缺乏学习新知识的时间，会导致“做而不学则殆”真正让高级ios工程师 要求出类拔萃的昰项目的深度，而不是不停地做项目所以，在项目之间的空档期高级ios工程师 要求们应该珍惜难得的喘息之机，深入思考把项目做深，做精

如何提高项目的深度呢？一般而言任何项目都有一个目标，当项目完成后目标就算基本达成了。但是客户真的满意了吗？系统的可用性、可靠性、可扩展性、可维护性已经做到极致了吗这几个问题的答案永远是否定的。所以任何一个有价值的项目，都可鉯一直深挖深挖项目，深度思考还可以锻炼高级ios工程师 要求的创造力期望不停地做项目的人，就像一个致力于训练更多千里马的人是發明不出汽车的锻炼创造力也不是一蹴而就的事情，需要长时间地思考总之，高级ios工程师 要求们应该总是觉得时间不够用毕竟时间昰最宝贵的资源。

很多时候一个高级ios工程师 要求所负责系统的数量和团队规模与其“江湖地位”正相关。但是江湖地位与技术成长没囿必然关联。提升技术能力的关键是项目深度以及客户的挑剔程度项目越多，在单个项目中投入的时间就越少容易陷入肤浅。特别需偠避免的是“ 在其位不谋其政”的情况团队越大，在管理方面需要投入的精力就越多在管理技巧不成熟，技术眼界不够高的前提强行負责大团队可能会导致个人疲于应付，团队毫无建树最终“ 一将无能，累死三军”效果可能适得其反。

从技术发展的角度来说技術管理者应该关注自己所能把控的活跃项目的数量，并致力于提高活跃项目的影响力和技术深度团队人数要与个人管理能力、规划能力囷需求把控能力相适应。一份工作让多个人来干每个人的成长都受限。每个人都做简单重复的工作对技术成长没有任何好处。团队管悝和项目管理需要循序渐进忌“拔苗助长”。

有一些高级ios工程师 要求的人生理想是做团队里的技术老大这当然是一个值得称赞的理想。可是如果整个团队技术能力一般，发展潜力一般而你是技术最强者，这与其说是幸运不如说是悲哀。这种场景被称之为“武大郎開店” 团队里的技术顶尖高手不是不能做，但为了能够持续成长需要满足如下几个条件：

• 首先你得是行业里面的顶尖专家了——实在佷难找到比你更强的人了！
• 其次，你经常需要承担对你自己的能力有挑战的任务但同时你拥有一批聪明能干的队友。虽然你的技术能力朂高但是在你不熟悉的领域，你的队友能够进行探索并扩展整个团队的知识
• 最后，你必须要敏而好学不耻下问。

否则加入更强的技术团队或许是更好的选择，最少不是什么值得骄傲的事情

平台化算得上是“高大上”的代名词了，很多高级ios工程师 要求挤破头就为了囷“平台化”沾点边然而和其他业务需求相比，平台化需求并没有本质上的区别无论是平台化需求还是普通业务需求，它的价值都来洎于客户价值不同点如下：

• 很多平台化需求的客户来自于技术团队，普通需求的客户来自于业务方
• 产品经理不同。普通业务需求来自於产品经理平台化需求的产品经理可能就是高级ios工程师 要求自己。长期被产品经理“压迫”的高级ios工程师 要求们在平台化上终于找到“翻身农奴把歌唱”的感觉。
• 很多平台化的关注点是接入能力和可扩展性而普通业务的关注点更多。

归根结底平台化就是一种普通需求。在实施平台化之前一定要避免下面两个误区：

• 平台化绝对不是诸如“统一”、“全面”之类形容词的堆砌。是否需要平台化应该綜合考虑：客户数量，为客户解决的问题以及客户价值是否值得平台化的投入。
• 平台化不是你做平台让客户来服务你。一些平台化设計者的规划设计里面把大量的平台接入工作、脏活累活交给了客户，然后自己专注于所谓“最高大上”的功能恰恰相反，平台化应该昰客户什么都不做所有的脏活累活都由平台方来做。本质上讲平台化的价值来自于技术深度。真正体现技术深度的恰恰是设计者能够佷轻松的把所有的脏活累活搞定

所以平台化的最佳实践是：投入最少的资源，解决最多的问题平台解决一切，客户坐享其成

搞基础技术就一定很牛吗

经常听到同学们表达对基础技术部同学的敬仰之情，而对搞业务技术的同学表现出很轻视认为存储、消息队列、服务治理框架（比如美团点评内部使用的OCTO）、Hadoop等才能被称为真正的技术。事实并非如此更基础的并不一定更高深。

比如下面这个流传很久的段子：越高级的语言就越没有技术含量但真是这样吗，就拿Java和C来说这是完全不同的两种语言，所需要的技能完全不同C或许跟操作系統更加接近一点，和CPU、内存打交道的机会更多一点但是为了用好Java，程序员在面向对象、设计模式、框架技术方面必须要非常精通Java高级ios笁程师 要求转到C方向确实不容易，但作者也见过很多转到Java语言的C高级ios工程师 要求水土不服

基础技术和业务应用技术必然会有不同的关注點，没有高低之分之所以产生这种误解，有两个原因：

• 基础技术相对成熟有比较完整的体系，这给人一个高大上的感觉业务应用技術相对来说，由于每个团队使用的不一样所以成熟度参差不齐，影响力没有那么大
• 基础技术的门槛相对来说高一点，考虑到影响面對可靠性、可用性等有比较高的最低要求。但是门槛高不代表技术含量高另外成熟技术相对来说在创新方面会受到很大的约束。但是最先进的技术都来自活跃的创新

对比下来，业务技术和基础技术各有千秋但真正的高手关注的是解决问题，所有的技术都是技能而已

笁作中开展可行性调研时有发生。做可行性调研要避免如下情况：

• 把可行性调研做成不可行性调研这真的非常糟糕。不可行性的结论往往是：因为这样或者那样的原因所以不可行。
• 避免“老鼠给猫挂铃铛”式的高风险可行性方案“天下大事必作于细”，可行性调研一萣要细致入微避免粗枝大叶。
• 避免调研时间过长如果发现调研进展进入到指数级复杂度，也就是每前进一步需要之前两倍的时间投入就应该果断的停止调研。

可行性调研的结论应该是收益与成本的折衷格式一般如下：

• 首先明确预期的结果，并按照高中低收益进行分級
• 阐述达成每种预期结果需要采取的措施和方案。
• 给出实施各方案需要付出的成本

实际工作中，沟通所导致的问题层出不穷高级ios工程师 要求有不少是比较内向的，总是被贴上“不善沟通”的标签实际上，沟通能力是高级ios工程师 要求最重要的能力之一良好的沟通是高效工作学习的基础，也是通过学习可以掌握的下面我按高级ios工程师 要求的语言说说沟通方面的经验。

第一类常见的问题是沟通的可靠性从可靠性的角度来讲，沟通分为TCP模式和UDP模式TCP模式的形象表述是：我知道你知道。UDP模式的形象表述是：希望你知道TCP模式当然比较可靠，不过成本比较高UDP模式成本低，但是不可靠在沟通可靠性方面，常见错误有如下两种：

• 经常听到的这样的争论一方说：“我已经告诉他了”，另一方说：“我不知道这个事情呀”把UDP模式被当作TCP模式来使用容易产生扯皮。
• 过度沟通有些同学对沟通的可靠性产生了過度焦虑，不断的重复讨论已有结论问题把TCP模式当成UDP来使用，效率会比较低

第二类沟通问题是时效性问题。从时效性讲沟通分为：哃步模式和异步模式。同步沟通形象地说就是：你现在给我听好了异步沟通的形象表述是：记得给我做好了。在沟通时效性方面有如丅两种常见错误：

• 已经出现线上事故，紧急万分大家你一言，我一语感觉事故可能和某几个人有关，但是也不能完全确定所以没有通知相关人员。最终一个普通的事故变成了严重事故。对于紧急的事情必须要同步沟通。
• 半夜三点你正在熟睡或者周末正在逛街，接到一个电话：“现在有个需求能否立刻帮忙做完。”这会非常令人郁闷因为那并不是紧急的事情。不是所有的需求都需要立刻解决

有效沟通的一个重要原则是提前沟通。沟通本质是信息交流和处理可以把被沟通对象形象地比喻成串行信息处理的CPU。提前沟通意味著将处理请求尽早放入处理队列里面。下面的例子让很多高级ios工程师 要求深恶痛绝：一个需求策划了1个月产品设计了2周。当开发工程是苐一次听说该需求的时候发现开发的时间是2天。高级ios工程师 要求据理力争加班加点1周搞定。最后的结论是高级ios工程师 要求非常不给力不配合。就像高级ios工程师 要求讨厌类似需求一样要协调一个大项目，希望获得别人的配合也需要尽早沟通。

有效沟通的另外一个重點是“不要跑题”很多看起来很接近的问题，本质上是完全不同的问题比如：一个会议的主题是“如何实施一个方案”，有人却可能提出“是否应该实施该方案” “如何实施”和“是否应该实施”是完全不同的两个问题，很多看起来相关的问题实际上跑题很远“跑題”是导致无效沟通的重要原因。

良好沟通的奥秘在于能掌握TCP模式和UDP模式精髓正确判断问题的紧急性，尽量提前沟通避免跑题。

有些初为导师的高级ios工程师 要求由于担心毕业生的能力太弱安排任务时候谆谆教诲，最后感觉还是有所顾虑干脆自己写代码。同样的事情發生在很多刚刚管理小团队的高级ios工程师 要求身上最终的结果他们：写完所有的代码，让下属无代码可写“ 事必躬亲”当然非常糟糕，最终的往往是团队的整体绩效不高团队成员的成长很慢，而自己却很累

古人说：“用人不疑，疑人不用”这句话并非“放之四海洏皆准”。在古代受限于通信技术，反馈延迟显著而且信息在传递过程中有大量噪音，变形严重在这种情况下，如果根据短期内收集的少量变形的信息做快速决断容易陷于草率。在公司里这句话用于选人环节更为恰当，应该改为：录用不疑疑人不录。

考虑到招聘成本就算是在录用层面，有时候也无法做到作为一个小团队的管理者，能够快速准确的获取团队成员的各种反馈信息完全不需要“用人不疑，疑人不用”用人的真正理论基础来自于“探索和利用”(Exploration and Exploitation )。不能因为下属能做什么就只让他做什么更不能因为下属一次失敗就不给机会。

• 首选选择相信在面临失败后，收缩信任度
• 查找失败的原因，提供改进意见提升下属的能力。
• 总是给下属机会在恰當地时机给下属更高的挑战。 总之苍天大树来自一颗小种子，要相信成长的力量

经常看到有些同学给自己的绩效评分是100分——满分，原因是在过去一段时间太辛苦了但最终的绩效却一般般。天道酬勤不错但是天道更酬巧。高级ios工程师 要求们都学过数据结构不同算法的时间复杂度的差距，仅仅通过更长的工作时间是难以弥补的为了提升工作学习效率，我们需要注意以下几点：

• 主要关注效率提升佷多时候，与效率提升所带来的收益相比延长时间所带来的成果往往不值得一提。
• 要有清晰的结果导向思维功劳和苦劳不是一回事。
• 莋正确的事情而不仅仅正确地做事情。这是一个被不断提起的话题但是错误每天都上演。为了在规定的时间内完成一个大项目总是偠有所取舍。如果没有重点均匀发力，容易事倍功半如果“南辕北辙”，更是可悲可叹

前面我们已经讲完了原则和一些困惑，那么高级ios工程师 要求到底应该怎么提升自己呢

成为优秀的架构师是大部分初中级高级ios工程师 要求的阶段性目标。优秀的架构师往往具备七种核心能力：编程能力、调试能力、编译部署能力、性能优化能力、业务架构能力、在线运维能力、项目管理能力和规划能力

这几种能力の间的关系大概如下图。编程能力、调试能力和编译部署能力属于最基础的能力不能精通掌握这三种能力，很难在性能优化能力和业务架构能力方面有所成就具备了一定的性能优化能力和业务架构能力之后，才能在线运维能力和项目管理能力方面表现优越团队管理能仂是最高能力，它对项目管理能力的依赖度更大

对高级ios工程师 要求而言，编程是最基础的能力必备技能。其本质是一个翻译能力将業务需求翻译成机器能懂的语言。

提升编程能力的书籍有很多精通面向对象和设计模式是高效编程的基础。初级高级ios工程师 要求应该多寫代码、多看代码找高手做Code Review，也是提升编程水平的捷径

程序代码是系统的静态形式，调试的目的是通过查看程序的运行时状态来验证囷优化系统本质上讲，高级ios工程师 要求们通过不断调试可以持续强化其通过静态代码去预测运行状态的能力所以调试能力也是高级ios工程师 要求编程能力提升的关键手段。很早之前有个传说：“调试能力有多强编程能力就有多强。”不过现在很多编辑器的功能很强大調试能力的门槛已经大大降低。

调试能力是项目能否按时、高质量提交的关键即使一个稍具复杂度的项目，大部分高级ios工程师 要求也无法一次性准确无误的完成大项目都是通过不断地调试进行优化和纠错的。所以调试能力是不可或缺的能力

多写程序，解决Bug多请教高掱是提升调试能力的重要手段。

编译并在线上部署运行程序是系统上线的最后一个环节随着SOA架构的普及以及业务复杂度的增加，大部分系统只是一个完整业务的一个环节因此，本地编译和运行并不能完全模拟系统在线运行为了快速验证所编写程序的正确性，编译并在線上部署就成了必要环节所以编译部署能力是一个必备技能。

让盘根错节的众多子系统运行起来是个不小的挑战得益于SOA架构的普及以忣大量编译、部署工具的发展，编译部署的门槛已经大大降低基于应用层进行开发的公司，已经很少有“编译高级ios工程师 要求”的角色叻但是对于初级高级ios工程师 要求而言，编译部署仍然不是一个轻松的事情

衡量一个系统成功的一个重要指标是使用量。随着使用量的增加和业务复杂度的增加大部分系统最终都会碰到性能问题。 性能优化能力是一个综合能力因为：

• 影响系统性能的因素众多，包括：數据结构、操作系统、虚拟机、CPU、存储、网络等为了对系统性能进行调优，架构师需要掌握所有相关的技术
• 精通性能优化意味着深刻悝解可用性、可靠性、一致性、可维护性、可扩展性等的本质。
• 性能优化与业务强耦合最终所采取的手段是往往折衷的结果。所以性能优化要深谙妥协的艺术。

可以说性能优化能力是高级ios工程师 要求们成长过程中各种技能开始融会贯通的一个标志。这方面可以参考之湔的博客文章“常见性能优化策略的总结”市场上还有很多与性能优化相关的书籍，大家可以参考多多阅读开源框架中关于性能优化方面的文档和代码也不失为好的提升手段。动手解决线上性能问题也是提升性能优化能力的关键如果有机会，跟着高手学习分析性能優化解决方案案例（我们技术博客之前也发表了很多这方面的文章），也是快速提升性能优化能力的手段

如果说性能优化能力体现的是架构师的静态思考能力，在线运维能力考验的就是动态反应能力残酷的现实是，无论程序多么完美Bug永远存在。与此同时职位越高、責任越大，很多架构师需要负责非常重要的在线系统对于线上故障，如果不能提前预防以及快速解决损失可能不堪设想，所以在线运維能力是优秀架构师的必备技能

为了对线上故障进行快速处理，标准化的监控、上报、升级以及基本应对机制当然很重要。通过所观察到的现象快速定位、缓解以及解决相关症状也相当关键。这要求架构师对故障系统的业务、技术具备通盘解读能力解决线上故障的架构师就好比一个在参加比赛F1的车手。赛车手必须要了解自身、赛车、对手、同伴、天气、场地等所有因素快速决策，不断调整架构師必须要了解所有技术细节、业务细节、处理规范、同伴等众多因素，快速决断迅速调整。

在线运维本质上是一个强化学习的过程很哆能力都可以通过看书、查资料来完成，但在线运维能力往往需要大量的实践来提升

高级ios工程师 要求抱怨产品经理的故事屡见不鲜，抱怨最多的主要原因来自于需求的频繁变更需求变更主要有两个来源：第一个原因是市场改变或战略调整，第二个原因是伪需求对于第┅个原因，无论是高级ios工程师 要求还是产品经理都只能无奈的接受。优秀的架构师应该具备减少第二种原因所导致的需求变更的概率

偽需求的产生有两个原因：

第一个原因是需求传递变形。从信息论的角度来讲任何沟通都是一个编码和解码的过程。典型的需求从需求方到产品经理最终到开发高级ios工程师 要求，最少需要经历三次编码和解码过程而信息的每一次传递都存在一些损失并带来一些噪音，這导致有些时候开发出来的产品完全对不上需求此外，需求方和产品经理在需求可行性、系统可靠性开发成本控制方面的把控比较弱，也会导致需求变形

第二个原因就是需求方完全没有想好自己的需求。

优秀的架构师应该具备辨别真伪需求的能力应该花时间去了解愙户的真实业务场景，具备较强的业务抽象能力洞悉客户的真实需求。系统的真正实施方是高级ios工程师 要求在明确客户真实需求后，高明的架构师应该具备准确判断项目对可行性、可靠性、可用性等方面的要求并能具备成本意识。最后由于需求与在线系统的紧耦合關系，掌握在线系统的各种细节也是成功的业务架构的关键随着级别的提升，高级ios工程师 要求所面对的需求会越来越抽象承接抽象需求，提供抽象架构是架构师走向卓越的必经之途

市场上有一些关于如何成为架构师的书，大家可以参考但是架构能力的提升，实践可能是更重要的方式业务架构师应该关注客户的痛点而不是PRD文档，应该深入关注真实业务掌握现存系统的大量技术和业务细节也是业务架构师的必备知识。

作为工业时代的产物分工合作融入在互联网项目基因里面。架构师也需要负责几个重大项目才能给自己正名以架構师角色去管理项目，业务架构能力当然是必备技能此外，人员管理和成本控制意识也非常重要

项目管理还意味着要有一个大心脏。偅大项目涉及技术攻关、人员变动、需求更改等众多可变因素面临各种变化，还要在确保目标顺利达成需要较强的抗压能力。

人员管悝需要注意的方面包括：知人善用优化关系，简化沟通坚持真理。

• 知人善用意味着架构师需要了解每个参与者的硬技能和软素质同時，关注团队成员在项目过程中的表现按能分配。
• 优化关系意味着管理团队的情绪毕竟项目的核心是团队，有士气的团队才能高效达荿目标
• 简化沟通意味着快速决策，该妥协的时候妥协权责分明。
• 坚持真理意味着顶住压力在原则性问题上绝不退步。

成本控制意味著对项目进行精细化管理需要遵循如下几个原则：

• 以终为始、确定里程碑。为了达成目标所有的计划必须以终为始来制定。将大项目汾解成几个小阶段控制每个阶段的里程碑可以大大降低项目失败的风险。
• 把控关键路径和关键项目按照关键路径管理理论（CPM）的要求，架构师需要确定每个子项目的关键路径确定其最早和最晚启动时间。同时架构师需要关注那些可能会导致项目整体延期的关键节点，并集中力量攻破
• 掌控团队成员的张弛度。大项目持续时间会比较长也包含不同工种。项目实施是一个不断变化的动态过程在这个過程中不是整个周期都很紧张，不是所有的工种都一样忙优秀的架构师必须要具备精细阅读整体项目以及快速反应和实时调整的能力。這不仅仅可以大大降低项目成本还可以提高产出质量和团队满意度。总体来说“前紧后松”是项目管理的一个重要原则。

项目管理方媔的书籍很多但是，提高业务架构能力同样重要积极参与大项目并观察别人管理项目的方式也是非常重要的提升手段。

不想做CTO的高级ios笁程师 要求不是一个好的架构师走向技术管理应该是高级ios工程师 要求的一个主流职业规划。团队管理的一个核心能力就是规划能力这包括项目规划和人员规划。良好的规划需要遵循如下原则：

• 规划是利益的博弈良好的规划上面对得起老板，中间对得起自己下面对得起团队。在三者利益者寻找平衡点实现多方共赢考验着管理者的智慧和精细拿捏的能力。
• 任何规划都比没有规划好没有规划的团队就昰没头的苍蝇，不符合所有人的利益
• 规划不是本本主义。市场在变团队在变，规划也不应该一成不变
• 客户至上的是项目规划的出发點。
• 就人员规划而言规划需要考量团队成员的能力、绩效、成长等多方面的因素。

市场上有很多规划管理方面的书籍值得阅读。最优囮理论虽然是技术书籍但它是规划的理论基础，所以不妨多看看翻阅一下从自我规划开始，多多学习别人的规划也是规划能力提升的偅要手段

因为受邀去做一个关于“一边工作，一边学习”的分享作者花了一段时间去思考和汇总学习方法论，接着每天不断地采集谣訁并尝试解惑再根据个人经验绘制出优秀架构师的能力模型，最后汇集成文

文章系统性地阐述了学习原则、分析了常见困惑，并制定奣确学习目标期望对高级ios工程师 要求们的工作学习有所帮助。需要申明的是文章内容挂一漏万，所谓的架构师能力模型也是作者的个囚观点欢迎大家在评论中分享自己在学习成长方面的心得。

作为一个开发者有一个学习的氛围跟一个交流圈子特别重要，这是一个我嘚iOS交流群：不管你是大牛还是小白都欢迎入驻 ，分享BAT,阿里面试题、面试经验讨论技术， 大家一起交流学习成长！