阅读更多

0顶
0踩

非技术

转载新闻 硅谷和国内的 iOS 开发到底有何不同?

2017-03-02 17:43 by 副主编 jihong10102006 评论(1) 有6020人浏览
ios
前段时间在国内各大互联网公司转了一圈。与各位 iOS 业界大佬交流了之后,深感国内变化之大,敬佩诸位国内开发者的实力和韧劲。除此之外,我还发现硅谷和国内的 iOS 开发还是差别很大,且听我慢慢道来。

国内使用 SDK 和 硅谷大为不同
首先是最本质的三个不同:国内的支付使用的是支付宝和微信,地图使用的高德和百度导航,国内的第三方登录主要是微博,微信,和 QQ。而硅谷的在线支付方式是信用卡,地图使用的是苹果自带亦或是谷歌地图,第三方登录就是 Facebook 和 Twitter。

这三点不同意味着开发引入的 SDK 完全不同。在 Uber 被滴滴收购前,其美国的 App 和 中国的 App 完全是两个不同的 App -- 因为大量 SDK 不同导致架构和接口需要重新设计。再加上国内对于数据的严格掌控,很多 App 后台 API 的设计需要单独处理,流量需要导入到中国境内的数据中心,App 的界面亦要根据中国的网速针对优化。

另外,国内开发经常大量的调用第三方的库。而硅谷的大厂开发基本都是自己开发内部的工具和库。可能调用开源库确实比较方便快捷,但是硅谷的大厂考虑更多的是版权和代码质量的问题,所以在开源或是使用第三方库方面格外谨慎。

国内注重 HotPatch,硅谷注重原生态
据我所知,国内开发对于热补丁情有独钟。滴滴就做出了 DynamicCocoa,通过转化 Objective-C 到 Javascript 进行热修复;饿了么大量使用 Weex 进行移动开发;美团也已经在主 App 里尝试了 React Native。

相比硅谷,也只有少量小公司开始尝试 React Native。其主要原因也是 App 需求相对简单,跨平台开发相对轻松。大公司几乎很少使用,就连 RN 的母公司 Facebook 也只是在1到2个小 App 上使用了 React Native。

我个人推测这其中的主要原因在,国内开发需求量又多又急,加上前些年 App Store 的审核非常之慢,所以国人在开发上才对 HotPatch 趋之若骛。

国内要求快速迭代,硅谷要求测试覆盖
与百度的开发者交流中,他们经常提到“业务太多,根本来不及做”。所以基本上会有一个单独的 QA 团队负责测试,而开发者则是不停的写新的代码。

这一点与硅谷在对测试的态度上大相径庭。Google 对于代码的测试覆盖率有严格的要求和审核标准,Yahoo! 甚至在开发中要求采用 TDD (Test-Driven Development),Facebook 所有的代码也都用持续集成测试来保证其质量。在 《The Clean Coder》一书中,作者也多次强调代码质量的测试的重要性。我之前在工作中,有时候甚至出现写的测试代码数量超过开发代码的时候。

造成这一差异的本质在于两国竞争模式的不同。中国人口巨大,竞争对手太多,所以资本的打法就是快速迭代,小步快跑,挤垮对手。面对这样的模式,中国的工程师也只能暂时放弃完善测试代码,将有限的精力集中在开发上。

Swift 与 Objective-C 的争论一直不绝于耳

国内和硅谷对于 Swift 的看法大同小异
前段时间唐巧老师发表了他对 Swift 的看法,他认为 Swift 是未来,但是现在不太完善,要“再等等”。无独有偶,卓同学发文则认为,Swift 已经开始流行起来,应该“快上车”。

我在这半个月杭州、北京、上海之行中发现,几乎大厂开发都用 Objective-C,他们对 Swift 依然心存芥蒂;而小公司和独立开发者,则是对 Swift 充满期待。原因很简单,大厂需要的是稳定的产品来维持口碑,对于 Swift 这样重写并不能带来巨大好处的冒险之举自然是讳莫如深。而这个原因对于小公司或者个人来说并不成立。

其实国外对此也一样。唯一不同的是,可能硅谷要略微激进一点 -- 大厂已经开始部分尝试 Swift 了。Google 在某些新产品和新功能上已经开始用 Swift,Facebook 和 Twitter 都放出了自己的 Swift iOS SDK;LinkedIn 开源了 LayoutKit,Lyft 开源了 mapper,而这些都是用 Swift 写成。

就连硅谷的猎头都开始急着寻找拥有 Swift 开发技能的工程师了,而就在去年,Swift 在职场上还是被作为一项可有可无的加分技能来对待。

虽然硅谷在 Swift 上走在了前面,但是不得不说开创性的尝试总是要付出代价的。当年 Uber 在开发新 App 时采用了全 Swift 模式,结果因为 Swift 编译速度不佳和语言功能不全,开发效率大打折扣,内部工程师在采坑过程中无比头疼。所以 Swift 虽好,可不要贪快哦。

国内 iOS 职场与硅谷有很大差别
这个话题有点大,我从四个方面来说。
1、两者对于 iOS 工程师的需求量不同
国内现在处于一个 iOS 工程师饱和的状态,水平一般的 iOS 开发者多如牛毛,而高手却屈指可数。这就造成了一个情况,公司招不到素质过硬的工程师,而很多新手找不到工作。

作为生活在美帝多年的土包子,我对这个问题百思不得其解。因为硅谷一直是程序员的天堂,一个美帝计算机专业的毕业生,可以随便就找到一个年薪10万刀的工作。在这之中,iOS 工程师更是奇货可居。按照道理来讲,美国这么多年大量输出计算机本科生,硅谷居然还缺工程师,而且连刚毕业的新手都抢手。为什么国内反而却饱和了呢?

这个问题直到我遇到了滴滴的 Sunny 才想明白。

他告诉我,国内有 iOS 培训班这种东西。这样,工程师可以流水线快速训练出来,他们会带你刷面试题,教你如何拿 Offer,甚至帮你把 Github 和 博客都弄好。再加上前段时间中国处于全民创业的狂潮之中,各种初创企业对 iOS 工程师需求巨大,导致这种培训班居然大行其道。而现在市场回归理性,对于程序员的需求量减少,于是很多刚刚流水线出来的 iOS 菜鸟自然无处可去。

2、产品经理 (PM/PD)素质的差异
之前老听说国内程序员追着产品经理砍的故事,我只当成是个事故,一笑置之。因为硅谷的产品经理大多和程序员和睦相处,至少在我印象中,工程师和产品经理的矛盾要远远小于上下级的矛盾。

后来发现,在国内,我以为的并不是我以为的。

国内产品经理基本上就是刚毕业的新人,没有什么实战经验,有些都不懂技术。而最重要的开发需求和任务往往是他们提出和分配。这就造成了一个奇怪的现象:一群经验丰富的 iOS 专家,团结在一个不怎么懂技术的产品经理周围,做开发。

硅谷则对产品经理要求颇为严格:口才和技术是两个必备的技能,很多产品经理甚至是资深程序员转型。一般产品经理也是作为部门经理的接班人来培养的。

3、面试流程不一样
我说实话,国内大厂考得要比硅谷难。我回国之前就发现腾讯笔试好几张卷子真不好做,面试考得也异常全面。百度甚至考出了红黑树这种变态的玩意,还有公司问 autorelease pool 是用什么数据结构写的。

硅谷每个公司的面试流程则不尽相同。谷歌是比较极端的考 4 到 5 轮算法,亚马逊与此类似,这种标准化流程让这两家损失掉很多优秀的工程师 -- Homebrew 的作者 Max Howell 因为不会在白板上翻转二叉树而被谷歌拒绝的事情现在还被大家拿来吐槽。相比 Facebook 的面试还比较靠谱,一轮交流,问问简历和文化;一轮系统设计;两轮算法。我个人面过最实际的还是 Uber 的 iOS 面试:一轮交流,一轮系统设计,一轮上机实战写 App,一轮算法。

总体来讲,国内面试偏向考试,难度大,要求全面。硅谷的面试侧重算法和基本功,有时候脱离实际。

4、职业走向
据我所知,国内很少有干了10年以上的开发者,很多程序员干了几年就做管理了。这可能是因为国内程序员确实很辛苦,阿里这样的大厂996都是常态,在这种情况下码农、搬砖这类热词应用而生。但同时中国很多优秀的开发者,可能是前端、后端、移动端都有几年经验,技能十分全面扎实。

而硅谷有很多写了10年以上经验的极客程序员,他们热衷写代码却不喜欢管理工作。我在美帝待得这几年,几乎没有听到国外程序员抱怨自己辛苦,像Google,Facebook 这样成熟的美国互联网公司很少出现加班情况。硅谷的开发者可能一辈子只钻研一块,比如只会前端或者后端。但这并不妨碍他们在喜欢的领域成为超级专家,这也十分受人敬仰。

总结
虽然中国的网民数量在 2008 年就超过了美国,尽管中国的互联网公司是唯一同美国一样使用10亿作为单位来衡量业绩的存在。但是不可否认,由于政策和文化的巨大差异,导致两国的开发环境有巨大的差别。本文抛砖引用,疏漏之处在所难免,我衷心希望国内外能够取长补短,因为互联网终将拉平整个世界。
  • 大小: 139.3 KB
  • 大小: 51.8 KB
来自: 简书
0
0
评论 共 1 条 请登录后发表评论
1 楼 wxynxyo 2017-03-03 11:50
没有各种压力,就很容易把一件事做到极致

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

  • Python编程实例分析Ⅰ

    学习Python期间记录的一些例程和分析 实例一 温度转换 实例二 货币转换 实例三 绘制毛毛虫 实例四 天天向上 实例五 星期几问题 实例六 输出十二星座的标志 实例七 程序计时 实例八 文本进度条 实例九 身体质量指数BMI计算 实例十 蒙特卡罗方法计算圆周率

  • 星座符号Unicode值

    >>> "天秤座字符Ω的Unicode值是:"+str(ord("Ω")) '天秤座字符Ω的Unicode值是:937' "双子座字符Ⅱ的Unicode值是:"+str(ord("Ⅱ")) '双子座字符Ⅱ的Unicode值是:8545'

  • 为何要用Unicode?

    Unicode 是为了解决传统的字符编码方案的局限而产生的,例如ISO 8859所定义的字符虽然在不同的国家中广泛地使用,可是在不同国家间却经常出现不兼容的情况。很多传统的编码方式都有一个共同的问题,即容许电脑处理双语环境(通常使用拉丁字母以及其本地语言),但却无法同时支持多语言环境(指可同时处理多种语言混合的情况)。  开发人员在开发应用程序时候通常使用Unicode字符和字符串。能够

  • 使用unicode编码识别中文字符、字母和数字,包括生僻汉字

        查询网络上如何识别中文字符的帖子,发现大部分只判断了常用汉字,即Unicode范围为0x4E00 ~ 0x9FA5。 unicode编码最新版本是2009年9月出版的5.2版,对汉字又进行了扩充。以往常说的20902个汉字,在unicode中从0x4e00-0x9fa5,但这不是全部的unicode汉字。最新版的unicode汉字块如下: 0x4e00-0x9fff cjk 统一字型 ...

  • 【配置属性】—Entity Framework实例详解

    Entity Framework Code First的默认行为是使用一系列约定将POCO类映射到表。然而,有时候,不能也不想遵循这些约定,那就需要重写它们。重写默认约定有两种方式:Data Annotations和FluentAPI。Data Annotations在功能上是Fluent API的子集,在一些映射场景下使用Annotations不能达到重写的目的,因此本篇文章中使用Fluent ...

  • 生僻字问题解决

    䶮、㛃、𠅤等三字节汉字可以正常保存在数据库中,𫓩、𬱖等四字节汉字无法保存在数据库表中。原因分析:一般来说,正常汉字不会超过 3 个字节,但是会出现一些生僻字为 4 个字节 (当然,有的 emoji 表情符号也是 4 个字节),而 MySQL 的 UTF-8 编码只能支持 1-3 个字节,如果想保存 4 个字节的字符,则需要把字符集修改为 utf8mb4,而且 MySQL 的版本要高于 5.5.3。解决办法:在jdbc连接中添加useUnicode=true;页面显示为空,大概率是问题2导致的。

  • C#中字符的 ASCII 码和 Unicode 码

    很多时候我们需要得到一个英文字符的 ASCII 码,或者一个汉字字符的 Unicode 码,或者从相关的编码查询它是哪一个字符的编码。很多人,尤其是从 VB 程序序转过来学 C# 的人,会报怨 C# 里为什么没有提供现成的函数来做这个事情——因为在 VB 中有 Asc() 函数和 Chr() 函数用于这类转换。    但是如果你学过 C,你就会清楚,我们只需要将英文字符型数据强制转换成合适的数值型

  • python输出十二星座符号

    十二星座中第一个白羊座的unicode编码为9800,从9800到9811即为十二星座全部unicode编码。通过chr()函数,将unicode编码转换成对应字符。

  • 【Python二级等考大题】星座三问

    Python二级等考大题

  • python小玩意——星座表程序

    python小玩意

  • Python123.io---十二星座

    Python123.io---十二星座

  • Python如何将字符和Unicode编码转变

    小小总结一下,以防过几天忘记,自己的复习资料,如果能帮到大家,也是有所作用!! 1,字符转化为Unicode编码方法:   ord("字符") ord("A") 65 ord("李") 26446 1,Unicode编码转化为字符方法:   chr(65535) chr(65535) '\uffff' chr(65) 'A' 转...

  • python星座转换程序代码_0009 如何编写程序计算所属星座,一看就懂

    原标题:0009 如何编写程序计算所属星座,一看就懂 这节课,仍然是复习input输入和if判断的用法,要做一个根据输入月份和日期输出是什么星座的程序。先来做一下上节课的练习:输入数字1-7判断是星期几程序应该类似如下:#coding=utf-8#输入数字1-7判断是星期几#作者:学哥 时间:2017/1/1num=int(input("week num"))if num==1:print "Mo...

  • python 字符编码识别及转换

    作者:解琛 时间:2020 年 9 月 7 日 python教程 如何查看字符串编码 Python isinstance() 函数 import chardet str1 = "你好啊!" print chardet.detect(str1) 输出如下。 {'confidence': 0.938125, 'language': '', 'encoding': 'utf-8'} python2 中,默认的字符串编码是 utf-8 编码。 #!/usr/bin/env python # coding=.

  • Java_常用编码(Unicode和UTF-8编码)

    Unicode编码介绍 1、Unicode 的好处:一种编码,将世界上所有的符号都纳入其中。每一个符号都给予一个独一无二的编码,使用Unicode没有乱码的问题。 2、Unicode 的缺点:一个英文字母和一个汉字都占用两个字节,这对于存储空间来说是浪费。 3、2的16次方是65536,所以最多编码是65536的字符。 4、编码0-127的字符是与ASCII的编码一样,比如'a'在ASCII码是0x61,在Unicode码是ox0061,都对应97,因此Unicode码兼容ASCII码 UTF-8

  • 关于Unicode编码的闲谈

    发现网上关于编码的文章挺多,但是说的彻底清楚的基本没有,所以还是得自己来总结,毕竟每个人的基础不一样,所以只有每个人自己总结的才能透彻的理解。 关于unicode: 大家都知道unicode又叫统一码、万国码。可以百科一下unicode的定义: Unicode是一种在计算机上使用的字符编码。它为每种语言中的每个字符设定了统一并且唯一的二进制编码,以满足跨语言、跨平台进行文本转换、处理的要求。

  • python中unicode编码问题

    字符串在Python内部的表示是unicode编码,因此,在做编码转换时,通常需要以unicode作为中间编码,即先将其他编码的字符串解码(decode)成unicode,再从unicode编码(encode)成另一种编码。 decode的作用是将其他编码的字符串转换成unicode编码,如str1.decode(‘gb2312’),表示将gb2312编码的字符串str1转换成unicode编码。...

  • 彻底弄懂 Unicode 编码

    查看原文 今天,在学习 Node.js 中的 Buffer 对象时,注意到它的 alloc 和 from 方法会默认用 UTF-8 编码,在数组中每位对应 1 字节的十六进制数。想到了之间学习 ES6 时关于字符串的 Unicode 表示法,突然就很想知道 UTF-16 是如何进行编码的,我尝试将一些汉字转换成二进制数,然后简单的按 2 个字节一组转换成十六进制,发现对于那些码点较大的汉字,结果

  • 判断文件是否为Unicode

    对于不同编码的文本文件,简单的判断方法为读取前两个字节:Unicode的前两个字节: 0xFFFEUnicode Big Endian: 0xFEFFUTF8: EFBBANSI:没格式

  • 你必须知道的EF知识和经验

    注意:以下内容如果没有特别申明,默认使用的EF6.0版本,code first模式。 推荐MiniProfiler插件 工欲善其事,必先利其器。 我们使用EF和在很大程度提高了开发速度,不过随之带来的是很多性能低下的写法和生成不太高效的sql。 虽然我们可以使用SQL Server Profiler来监控执行的sql,不过个人觉得实属麻烦,每次需要打开、过滤、清除、关闭。 在这里强烈推荐...

Global site tag (gtag.js) - Google Analytics