分类
未分类

被嫌弃的程序员的35岁!

作者 | 刘燕
35 岁,逃不掉中年危机?
1 程序员的 35 岁“魔咒”

不知道从什么时候起,35 岁变成了一个很“残酷”的年龄。35 岁的中浪,稍不留神,就可能被前浪和后浪拍打在沙滩上,连浪花都不剩。

中年危机已是一个普遍的社会问题。但对程序员这个群体来说,35 岁的危机感似乎格外重一些。

“因为程序员的工资普遍高于其他行业,一旦这个行业不要你了,(薪资)可能会面临断崖式下跌,所以才会有危机”,资深程序员赵可(化名)说。

35 岁是一道界限分明的职场分水岭,最尴尬莫过于“高不成、低不就”。如果到了 35、40 岁还没晋升上管理层去,就会面临失业、被社会淘汰的风险。一位 35+ 程序员在求职网站自述,他在今年年初被裁后的 2 个月里,疯狂海投简历、面试,只拿到了 6 个非大厂 offer,最终他决定平薪入职其中一家。

打击面并不仅限于职场。在某社交平台上,一位程序员愤愤表示,新认识的交友对象对“程序员到了 35 岁就退休”的定律感到介意,以致于感情快告吹了。

越临近 35 岁,焦虑感越发强烈起来。打开不少社交平台的相关话题页,你很容易被各种忧心忡忡的情绪所感染,35+ 程序员懊恼失业,就连 20+ 的年轻人也开始担忧未来会失业…

InfoQ 接触到的几位 35+ 技术人坦言,自己曾因为年龄的问题而感到焦虑。

我产生过年龄上的焦虑,首先觉得自己没有财务自由,也不是老板,随时会面临各种选择,跟年轻时的状态确实不一样了。

当到 35 岁时,我确实感觉到,自己和更年轻的同学间有些不同。身体的能力没有以前充沛了,感觉没以前那么能熬夜了,学习新事物的速度也慢了一些,可能需要更规律的管理时间以保持充沛精力投入工作。

尤其当我成立了家庭,有了孩子后,需要承担的角色和责任更多了,一开始觉得有转变的时候,内心其实还是有点慌的。

就像懂得所有道理却还是过不好生活。中年焦虑“魔幻”之处在于当你置身其中时,你明知道它是正常现象,却很难逃离负面情绪的“手掌心”。而这个时候,就越不能做情绪的奴隶,得尽快调整好心态,以防沉浸其中。

“其实中年危机时刻伴随着我,但我觉得只有不断提升自己,剩下就看运气了,尽人事听天命。我觉得大部分普通人过着一天天‘推着车轮子’往前走的生活,顾虑太多反而徒增压力,还是多关注一些眼前得到的东西最实际”,赵可的乐观心态里透着点“佛系”。

Juicedata 合伙人苏锐今年 38 岁,他很庆幸自己现在的心态和 20 多岁时差不多。走出短暂的焦虑期后,苏锐意识到,年龄沉淀下的经验果实对他走上创业之路大有裨益 — 对人的理解、对事物运行规律的体悟比 20 多岁清晰多了。

“干的活儿我挺喜欢的,还能挣钱,工资拿的还不低,为什么要焦虑呢”,从业 20 多年的程序员任从文(化名)是个天生的乐天派。

“我从来没有产生过年龄焦虑。因为我坚信技术是有价值的,随着时间的积累,技术掌握的越纯熟,越有价值。在我从业的十几年里,我尽量使自己朝着一个能够有积累的方向走”,Juicedata 创始人 &CEO 刘洪清十分笃定。

2 35 岁不转管理“混吃等死”?

“我没焦虑过,因为我在 35 岁之前就转型管理了”,70 后技术人陈岳(化名)自 2006 年开始转做架构师,兼做技术研究。在陈岳看来,较早转型让他“跳”过了 35 岁这道槛。

35 岁以上的程序员都去哪了?经常有人发出这样的灵魂拷问。很多人会选择在 35 岁的当口转型以渡过中年危机。

一般来说,35+ 程序员的职业路径主要有三个大方向:技术专家、技术管理、跨行业就业(非技术向)

转做技术管理,大多数程序员都会走上这条路。

在国内科技公司,大龄程序员想要一直做研发需要运气和实力。公司得提供这样的岗位,还要有足够的开放度允许他们长期写代码。而 35+ 程序员也要证明自己写的代码对公司有利,年轻人还替代不了。

另一方面,技术做久了,升到管理层,也是正常的职场晋升流程。

柳疏桐(化名)从 2016 年开始逐渐转向管理,到 18 年年底才完全从一线工作中解放出来。“那个时候我是技术骨干,同时还要周旋在各项管理会议里,大家很多事都需要等我做完才能往下推进,渐渐地我就成了团队的‘瓶颈’,这促使我下定决心把一线研发工作下放到团队中去”。

但需要注意的是,并非所有程序员都适合做管理

二者在思维和工作性质上有很大不同,程序员主要与机器打交道,通过程序驱动机器运作、服务,做管理多和人打交道,得擅长对技术方向做把握、协调、判断、决策。

从技术到技术管理,要跨过的“坎”不少。

刚转到管理时,柳疏桐有挺多地方不适应。“主要还是改不了程序员那套习惯,很多事愿意亲力亲为,参与细节,对别人不放心,我自己做最放心。一开始感觉在向务虚的方向走,感觉写的代码少了就和技术脱钩了,时常感到焦虑”。

经过 2 年多磨合,柳疏桐已经是一个成熟的技术 Leader 了。与工程师对自己负责,对程序负责不同,他意识到,舍得权力下放,推动整个技术体系前进,带动团队成功是从技术开发者进阶到技术领导者必须要面对的事。

38 岁的赵可刚刚渡过“管理小白”的阶段。加入一家创业公司 3 年后,今年年初,他被提拔到前端组负责人,手底下管着十几个人。

开始管人后,要给团队制定 kpi 和 deadline,以前习惯了和同事平级交流,赵可对“下命令”这事感到很别扭。日常工作也变得手忙脚乱,“天天觉得特别忙,在做这件事,马上就有人来找我,还没处理完呢,另一个人又来找我”;“以前核心代码都是我写的,我来处理可能只需要 1 天就解决了,交给别人可能需要 1 个礼拜”…..

花了一年多时间,通过看管理书,听管理课程,赵可才慢慢培养起了管理思维。

另一个程序员经常纠结的问题是,去大厂做管理还是去小厂做管理?

一般大厂不太可能空降“管理者”,它更看重对团队、业务的熟悉度及对公司的忠诚度,因此多倾向于内部孵化技术管理者。如果一个从大厂出来的程序员在小厂呆了几年后再想回去做管理就很难了。因此有不少从大厂出来的程序员选择去中小创业公司做技术 Leader,有些人不止自己去还带着自己原来的团队一起加入。

“35 岁不转管理就‘混吃等死’”,很多程序员觉得到了 35 岁、40 岁,再不转管理就来不及了。

对此,苏锐认为这一说法不成立。“多大年纪都可以转管理,转管理岗是一个挺大的角色转换,工作的重点会从自己产出变成支持团队去产出,需要对团队的成员、团队与团队之间提供支持,做桥梁。能否胜任这些工作与年龄无关,而与你是否愿意去做,是否擅长去做有关。”

现实情况下,技术管理岗位相比普通程序员岗位要少得多,所有人都去做高管显然不切实际,市场空间小且需要在技术和管理能力上具有相当的竞争力。

在这种背景下,程序员到了 35+ 还在一线写代码的人一定大有人在。实际上,如果热爱技术工作,就算到了 35 岁不转管理,坚守在一线岗位也未必就发展不好。

到底要不要转型,当你做决定的时候,可以先思考下这两个问题,一是想转到什么岗位及评估自己是否具备该岗位所需的技能;第二,是否热爱这个行业,并愿意始终在这个行业学习。

3 “最愁 35+ 技术 Leader 不写代码”

转向技术管理后,一个最直接的变化是,代码量越来越少了

InfoQ 接触到的几位技术管理者都表示,做了管理后,多数时间花在管理上,写代码的频次和数量与以前相比大大减少。

但他们并没有完全“抛弃”代码。他们仍然关注新的技术趋势,当有新技术(产品)出来时也会抽空直接上手“跑一跑”。

作业帮 NLP 技术负责人蒋宏飞喜欢在周末或者晚上有空档时就一些新出的算法模型开源代码进行分析并跑跑尝试一下。“这个过程有点像小孩拆玩具再组装起来的感觉,你在研究一个东西,完全沉浸在里面了。不掺杂任何功利和紧迫的东西,那一刻我感到特别放松”。

对很多技术管理者来说,偶尔研究下新出的技术,既能让自己保持技术敏锐度,同时也能更好地帮助作技术判断和决策。

近期,一则阿里巴巴 CEO 张勇对 35 岁程序员的看法流传网络。张勇表示,不会对程序员限制年龄,对 35+ 还在写代码的程序员表示鼓励。但他同时表示,“现在我最不发愁的事情不是 35 岁以上的员工写代码,而是 35 岁的员工不写代码”。

(源自网络)

张勇的表态引起热议。那么,35 岁 + 的程序员到底要不要写代码?各个层级的技术管理者是否必须要保持一定的代码量?

蒋宏飞觉得,技术管理者不能失去技术敏感度,否则管理可能会“变形”。新技术点、新模型,新框架能否在业务场景中形成新应用或改造升级旧应用,能否结合业务场景改造现有技术并推动业务升级,这些都考验着技术管理者的判断能力。固步自封和盲目跟风都不可取,不能产生业务价值,团队成长也会成问题。

陈岳强调了对风险控制的重要性。当生产运作遭遇突发风险时,亟需快速定位症结所在。如果技术 Leader 不写代码,对内部结构、上下游关系了解不够细致,一旦出了问题,可能不知道从何处着手解决。

“如果一个技术 Leader 完全不写代码,并不一定会对他开展管理工作有影响”,在创业之初,苏锐还会贡献一些代码,随着技术团队扩大,他现在绝大部分精力都放在了产品、市场上。但他仍然会从工程师的角度去思考问题,这也为他开展市场工作提供了另一种视角。

代码留给技术人的是观察世界和思考世界的方法,这种方法是‘道’,真正优秀的技术人会将这种‘道’吸收进而内化成为自己的一项能力。而代码水平是‘术’。即便管理工作多用“道”,也许术的部分有些生疏,但本质上计算机的逻辑没有变,并不妨碍成为一个优秀的技术人”,苏锐说。

35 岁 + 管理者代码量的问题或许很难给出一个统一的答案或者标准,因为公司类别、规模、岗位等的不同,对管理者的要求也必然不尽一致。

从公司规模的角度看,大公司的技术 Leader 不写代码并不意味着没有价值。平时可能很少见哪个大公司的 CTO 还在写代码。对他们来说,设计和把控技术方案更重要。

而对于中小公司,尤其是初创团队而言,不太可能单纯只招一个只负责管理而不能从事技术工作的人。自 2017 年创业以来,刘洪清目前仍是公司核心产品 JuiceFS 存储系统的主要代码贡献者。他的技术团队目前不到 10 人,除每天早上花一个小时左右开会外,剩下的时间,刘洪清几乎全都扑在产品研发上。

在以业务为导向的应用型公司,企业运营、战略管理可能比写代码更为重要。而若是纯技术型公司,技术 Leader 最好需要保持一定的代码量。

涛思数据创始人陶建辉今年 52 岁了,仍在一线写代码,据他介绍,他现在平均每天花 12 个小时写代码,最高 14 个小时。陶建辉是公司核心产品物联网大数据平台 TDengine 的主要代码贡献者,已为其写了 5 万多行代码。

他认为,代码是底层技术公司最重要的工作和价值所在,如果 CEO 不亲自写代码会失去对产品的把握,“如果 CEO 不写代码或者不懂代码,那我觉得这个公司不可能成为伟大的公司”。

4 互联网不需要中年“打工人”

回过头来反思一下,为什么 35 岁成了程序员的职场终点?

表面上看,这是个人的职场发展遇到了困境。更深层次的原因与当前激烈的就业环境不无关联,这里面很大程度上是市场“倒逼”的结果。

华为劝退 35 岁员工,强制退休补偿 45 岁员工;腾讯裁撤 10% 高管,劝退 35+ 员工… 如今的快速迭代的互联网和职场环境,都在向中年人传递出一个信号 —“你老了”。正如马化腾所说,或许你什么错都没有,就错在太老了。

“不要 35 岁以上的中年人,再便宜也不要”。虽没有明文,但 35 岁定律已是国内科技互联网公司招聘标准里的“潜规则”。


图源网络

年轻人能修 996 福报,对薪资要求不高,中年人精力和体力双下滑,家庭负担拖累成长空间,对薪资要求还高。于是“橄榄枝”更多伸向了年轻人。


图源网络

挡住大龄员工求职的主要就是在招聘过程。

一位运维工程师在脉脉上讲述他电话面试阿里的经历,“刚开始聊的挺好的,当听到我的年龄是 35 的时候,感觉面试官比我还紧张了”。最终,不出意料,他收到了拒绝邮件。

InfoQ 查询 Boss 直聘发现,有些公司在招聘 JD 上直接写明了年龄范围 。某软件公司招高级程序员的任职要求之一是“3 年以上经验,40 岁以下”。某教育公司的招聘 JD 上要求道“ 18 年毕业的 -35 岁以内都有的聊”,HR 备注卡年龄的原因是因为“年龄大职级可能 hold 不住” 。


截图来自 Boss 直聘

到了 35+ 的年龄再去找工作,市场的期待值也会变高。

有程序员表示,猎头找他的理由很直接“你的年龄也不太年轻了,想邀请你过来,希望你带一个团队”,聊的话题也基本围绕过往的管理经历。这或许能解释为什么程序员们担忧过了 35 岁再不转管理就来不及了。这就好比很多人 30 多岁了被催婚,传统的观念总认为,到了某个年龄,就意味着必须要到达一个阶段。

“我之前去面试国内某大厂,一面时被提问的所有问题我都答上来了,最终面试的人明显比我要年轻很多,面完之后,他说让我等一等他就走了,然后就再也没有然后了。那年,我三十四,面试官看起来也就二十七八岁。我当时猜测他可能‘嫌’我岁数大,觉得 30+ 的人水平应该更高”,胡伟(化名)向 InfoQ 讲述自己上一份面试经历。

现在做了技术 Leader 的胡伟似乎也成了当年那个“拒绝”他的面试官。

“现在招聘看简历,如果是 32 或 33 岁以上的,我就不会再看了。因为他们要求的工资待遇比较高,我们创业公司可能承受不了。另一个是好不好管的问题,像这个年纪,一般已做过一些管理岗位,价值观已基本定型了”。

“但每当我直接 pass 这些 30+ 候选人的简历时,我心里其实还是有一个坎儿的。反射到我自己的经历,也会同样感到不舒服。但这确实是正常现象”。

胡伟的矛盾,反映出了市场的选择。这可能不能简单称之为“偏见”或“歧视”。

不同企业对不同技术岗位有着差异化的需求和成本上的考量。如果一个技术岗对技能的要求并不高,考虑到性价比,企业更愿意少花钱招一个合适的人。如果 30+ 的工程师还在做基础工作,那与年轻人相比显然不具备竞争力。而那些技能要求高、犯错成本高的岗位,企业会更倾向于花更多的钱找一个有经验的人。

蒋宏飞在招人时发现,其实市场上很缺人,但又有很多大学生找不到工作。这并不矛盾。“很多程序员的简历上写着做过很多项目,但真聊起来发现他做的并不深入。行业真正需要的是经验丰富、能实际解决问题的人才”。

从另一个角度看,市场的“优胜劣汰”机制,也并非全都是坏事。它能鞭策程序员不断提高自己,形成自己的竞争优势。

国外程序员从不谈中年危机,35 岁退休是中国特色?

与国外相比,国内的互联网公司似乎更崇尚年轻文化。

从平均年龄上看,国内的互联网员工要比国外更年轻。

今年 3 月脉脉研究院发布的《互联网人才流动报告》统计,19 家企业的人才平均年龄为 29.6 岁,其中滴滴算是“最老”的,员工平均年龄为 33 岁,最年轻的是字节跳动和拼多多,人才平均年龄仅为 27 岁。

另据美国调查机构 PayScale 数据,截止 2018 年年底,苹果员工平均年龄 31 岁,谷歌员工平均员工 30 岁,Facebook 和 LinkedIn 员工平均年龄为 29 岁。

值得一提的是,Facebook 是一家极其奉行年轻文化的企业,这家公司简直就是年轻人的天下,年轻就是王道”是 Facebook 的用人准则。

而在脉脉研究院所统计的 19 家公司中,有 9 家公司的员工平均年龄低于或者与 Facebook 持平。其中不乏网易这种 20 多岁的“中年”公司。


图片源自脉脉数据研究院

还有一个很有意思的现象,在国内的公司里,似乎很少见到中年的程序员,但国外就能见到很多中年程序员。

有数据为证。

2019 年搜狐科技《中国互联网简史》报告显示,国内近一半的程序员年龄在 25-29 岁之间,其次为 30-34%,占比 24.6%,35 岁 -39 岁的程序员占比 6.1%,而 40+ 的仅占 1.2%。

2019 年,Stack Overflow 对全球(中国参与者较少)近 9 万名开发者的调研报告显示,国外 20-34 岁程序员人数占比最高,35 岁以上的程序员占总数的 25.7% 。

上周,已经退休的 64 岁 Python 之父 Guido van Rossum 因为觉得退休生活太无聊了,而重返职场成了微软“打工人”。前段时间美国一位数据科学家 Gene D’Angelo 在社区表示他已经 74 岁了,从事编程 57 年,至今仍没有退休的打算。

国外 IT 行业对于大龄程序员也有着较高的包容度。此前,同样 60 多岁的 Java 之父 James Gosling 曾自述在求职时感受到的善意“我们虽然不愿意招你这个年龄的程序员,但可以对你特殊考虑”。

而且在海外程序员眼里,中年危机压根并不是一件多么严重的事情。陶建辉此前在美国留学,后又先后在美国 Motorola、3Com 等公司从事技术工作。他介绍,在美国、欧洲的科技公司,无论规模大小,40-50 岁的程序员工作状态非常好,在他们的观念里,程序员并不一定非得带团队,做管理晋升到 CTO、CEO 级别才能证明人生是正常,圆满的。“在美国,从来不讨论 35 岁程序员的问题,美国程序员没有年龄危机,大家只是把它当做一份正常的工作”。

35 岁中年危机,难道是中国特色?

刘洪清向 InfoQ 表示,这种差异与两个国家的 IT 行业的发展历史有关。美国的 IT 行业从上个世纪 70 年代开始发展,而中国差不多晚了 20 年。在这种时代背景下,国内年长的程序员的数量肯定要少很多,中国四十岁以上的第一代程序员,相当于美国六十岁以上的那一代。

自 1994 年中国接入国际互联网开始,从 PC 到移动互联网,中国出现了三次大的互联网浪潮,带动国内 IT 行业在最近 10 年 -20 年间获得了井喷式增长,程序员数量也迎来爆发。这促使整个从业者群体的年龄结构更加年轻,再加上管理层的“空白”,公司需要有经验的程序员去做管理。


图为华为 1996 年招聘启事,要求所有岗位应聘者年龄在 35 岁以下。图片来源:微博 @程序员的那些事

到这里你可能就明白为什么中年危机会聚焦在 35 岁了。在中国,时代的红利已经让最早的一批程序员(70 后)实现了财富自由,他们用不着焦虑。而随着产业壮大,时代红利渐消怠,80 后成了第一批遇到这个问题的群体。没有前人的经验可以借鉴,而更有年龄优势的 90 后,00 后正在快速成长,80 后程序员的焦虑感可能更重。

陶建辉认为,“35 岁现象”出现的根源在于中国的 IT 水平还相对落后,国内在操作系统、中间件、内核软件、数据库等底层技术上与国外差距大,做移动应用的公司较多,软件开发门槛低,甚至有些程序员从培训班出来就能写,对高级人才需求不足。

“中国目前还没有任何一家软件公司开发的软件,真正走向全球。如果国内做基础开发的公司越来越多,那可能不会再有 35 岁程序员的问题”。

5 结语:如何打破 35 岁定律

35 岁定律就像一把高悬在头顶的达摩克利斯之剑,悬而不落的状态最“折磨”人。但时间永在流逝,没有人能避免 35 岁的来临。

如果一个程序员随着年龄的成长,每天还只是在重复做着基础工作,那么当 35 岁来临时,危机大概率也会找上门。

对抗 35 岁危机,不能打无准备的“仗”。最关键的是,一定要对自己有清晰的人生定位,“你在 35 岁之前最好想明白,任何行业、任何岗位,都能创造奇迹”,陶建辉建议。

如果真的热爱技术,希望在技术领域长期发展下去,就要持续学习,以让自己在技术上有积累,有系统化的理解和认知。如果有志向转型管理,那也要做相应的准备,注意培养自己的管理思维。而对于那些觉得干这行不是特别突出,竞争力相对较弱的普通程序员来说,提早准备 Plan B ,探索第二职业,谋求合适的时机转型 ,也不失为明智之举。

总之,无论是继续坚守技术道路还是转型,遵从自己的内心和志趣是最重要的,也都少不了持续学习,方能打破 35 岁悖论。商业世界瞬息万变,必须紧跟脚步才能不被时代抛弃。

克服 35 岁现象,除了个人努力突破职业瓶颈外,还需要良好的舆论环境,不要“妖魔化”35 岁。

更重要的是,职场生态需要进一步改善,希望企业为大龄技术人营造更加公平良性的就业机会和就业环境,给予大龄程序员更加包容、开放的空间。

据了解,在美国、欧洲等国家,为减少经验干扰和就业歧视,求职简历上不允许写年龄,也避讳问年龄,涉及年龄是违法行为。这就意味着,求职者全靠作品说话。

对 35 岁以上员工“一刀切”可能会令企业与那些真正富有经验累积的优秀人才失之交臂。我们呼吁,国内互联网科技公司在招聘技术人员时不要太限制年龄,例如在招聘 JD 里不写年龄规定,面试环节尽量不问年龄。就像招聘时不问肤色、种族一样,年龄也应该逐渐避免成为干扰因素。

我们欣然看到,已经有一些企业做出了改变。某企业在招聘 JD 中表示,自己是知乎 995 程序员白名单企业,公司没有 996,倡导有幸福感的工作。另一创业公司“有搞头”特意强调自己招 35 岁以上的程序员,因为 CEO 就是 35 岁找不到工作而创业的。


截图来自 Boss 直聘

在陶建辉公司 20 来人的技术团队中,超过 50 岁的就有 3 个,“我没觉得丢面子,也没觉得影响公司的发展。因为我自己年龄的原因,一般挑简历的时候,我不太在乎年龄,我更看重他心态是不是很年轻,是不是能像我一样挽起袖子到‘田里’做事”。

程序的世界,不应以年龄论英雄。

(应受访者要求,赵可、任从文、陈岳、胡伟、柳疏桐均为化名)


点个在看少个 bug 👇

分类
未分类

PC 巨变!抄苹果作业,Windows 10 明年将原生支持安卓 App,微软真慌了?


计算机与移动应用生态的融合,将成为趋势。

作者 | 李帅飞

最近半年,相对于苹果的高歌猛进,微软显得过于不思进取。

尤其是它的 Windows 10。

要知道,在不到半年的时间里,苹果已经实现了 Mac 有史以来最为重磅的一次更新。

具体来说,苹果在 6 月份宣布 Mac 平台迁移到苹果自主芯片;5 个月后,苹果就拿出了三款搭载其最强 M1 芯片的 Mac 新品——关键是,它们都可以运行 iOS 应用。

而再来看微软的 Windows 10。过去四五年,它一直忙着获取新用户,但自身的前进步伐实在是过于缓慢,连 UI 都还在折腾,更不用说应用生态的突破了。

不过,从目前的最新情况来看,面对苹果的冲击,微软似乎要有所行动了。

1


2021 年,Windows 10 将原生支持

运行 Android App

最新的消息显示:

Windows 10 正在加速拥抱 Android 应用生态。

11 月 25 日,名为 Zac Bowden 的博主在 Twitter 上表示,微软将把原生 Android 应用带到 Windows 操作系统,具体时间是在明年——但在这篇推文中,他并没有就细节进行展开。

需要注意的是,Zac Bowden 是一名来自 Windows Central 网站的作者,该网站长期跟进 Windows 和微软相关资讯,而且 Zac Bowden 从业多年,其也爆出过不少后来被证实的微软相关资讯,因此可信度比较高。

到了 11 月 27 日,Zac Bowden 在 Windows Central 发布了更多消息。

他援引知情人士的说法称,微软正在打造一个软件解决方案,该解决方案允许开发者将他们的 Android App 几乎不经改动就发布在 Windows 10 平台——具体来说,就是开发者可以将自家 Android App 打包成 MSIX 应用,然后提交给 Microsoft Store。

这一方案的代号是 “Latte”,将最早在明年亮相。

雷锋网(公众号:雷锋网)了解到,其实,微软早在 2015 年就已经宣布了一个名为 Project Astoria 的方案,目的是帮助开发商将它们的 Android 应用移植到基于 Windows 10 的手机、平板电脑和 PC 上——但在 2016 年,微软宣布放弃 Project Astoria。

然而,这一次,微软卷土重来。

按照 Zac Bowden 的说法,微软致力于打造一个与此前未曾亮相的 Project Astoria 类似的方案,不过在该方案中,微软需要在 Windows 10 提供一个 Andorid 子系统,来允许 Android App 运行。

不过,尽管 Android 是一个开放型系统,但微软的计划也面临着不少问题。

比如说,Android 系统向来与 Google 旗下的 GMS(Google Mobile Services)密切关联——不过,在这次的 Project Latte 中,微软不大可能增加对 Google Play Services 的支持,因为 Google 并不允许 Play Services 安装在 Android 手机和 Chromebook 之外的设备上。

这意味着,一些需要 Google Play Serivces API 才能运行的 Android App 要想在 Windows 10 平台运行,恐怕要做出一些必要的更新。

除非,微软和 Google 达成相关的合作,但可能性比较小。

值得一提的是,有消息称,在 M1 版 Mac 设备发售之后,一位名为 Alexander Graf 的开发者,通过在一个打了补丁的虚拟机中成功地让 Windows 10 on ARM 在他的苹果 M1 Macbook 上运行,其 CPU 运行速度居然超越了 Surface Pro X2。

这下,微软更是有足够的动力做出改变了。

2


拥抱 Android,微软这次要动真格了

其实,微软对 Android 的垂涎,已经是由来已久了。

众所周知,微软的 Windows 系统是桌面操作系统中的王者——不过,当移动互联网的大潮到来之时,微软并没有能够抓住机会,它所主张的 Windows Phone 由于微软的一连串失误而走向式微,并最终夭折了。

不过,自从 Satya Nadella 上台担任微软 CEO 以来,微软开始深度拥抱 Android。

比如说,2015 年 3 月,微软宣布与三星之间签署了一项新的改进协议;根据该协议,微软应用将预装于搭载 Android 系统的三星设备中,预装包括 Skype、OneNote、OneDrive 等在内的应用。

不仅如此,在当时,微软方面还表示,公司将与其它 11 家 Android 设备制造商合作以开展同样的业务。

后来到 2017 年,微软逐渐放弃了 “移动为先、云为先” 的策略,它和三星的合作更近一步——微软推出了微软版 Galaxy S8,除了原有搭载的 App,这款微软版的 Galaxy S8 还搭载了微软的 Outlook 和 Cortana 语音助手。

当然,除了应用预装,微软也选择在坚持推进 Windows 10 继续进化的基础上,积极与移动设备进行对接。比如说:

  • 在 2017 年的 Bulid 大会上,微软不断强调 Windows 10 PC 与其它不同平台的设备(比如说 Android 手机 和 iPhone)之间的互动关系,并提出了 “Windows PCs Love All Your Devices” 的口号;

  • 在 Build 2018 开发者大会上,微软又在 Windows 10 中发布了 Your Phone 功能,该功能旨在让用户可以在 PC 上访问手机中的内容。

不过,虽然微软用力推进,但不同操作系统和应用生态之间的界限是非常明显的,微软能做的其实非常有限——实际上,由于苹果对于 iOS 的严格限制,实际上微软只能在相对开放的 Android 生态中(这一点也得感谢 Google)有所作为。

于是,为了进一步推进 Windows 10 与 Android 的深入对接,微软再次选择与三星深度合作。

2019 年 8 月,微软宣布,三星 Galaxy Note 10 系列与微软 Windows 10 实现系统对接,具体来说,用户可以使用手机屏幕镜像功能将手机屏幕映射到 PC 上,并且能够使用 PC 键盘,鼠标和触摸屏直接与手机应用程序进行交互。

也就是说,某种意义上,通过 Your Phone 功能,Windows 10 系统也可以在三星手机运行 Android 应用——但从实际效果来看,运行效果并不稳定,而且只能局限在三星设备。

因此,如果能够在 Windows 10 PC 上实现对 Android App 的原生支持,其运行效果当然会更好,而且不用受限于品牌。

现在微软终于决定这样做了。

要知道,目前全世界已经有超过 20 亿的 Android 设备,如果能够对接成功,对于微软的 Windows 生态来说,无疑是一个重大利好。

3


计算机与移动应用生态的融合,

将成为趋势

对于个人计算机行业来说,2020 年,无疑是一个转折之年。

这一年,苹果凭借自己强大的芯片实力、软硬件整合能力和应用生态掌控力,成功实现了 Mac 向 Apple Silicon 的迁移,并由此促进了 macOS 和 iOS 应用生态的融合——某种程度上,这也预示了 ARM 生态对 Intel X86 生态的一种冲击。

当然,在苹果之前,微软、高通也都做出了类似的努力;比如微软 Windows 10 努力拥抱 Android,而高通骁龙芯片也的确已经出现在 PC 设备上。

但 2020 年,在强大的实力和执行力下,苹果一步到位地实现了计算机与移动生态的初步融合,在软硬件层面做到了微软和高通都未能做到的事情,其影响不仅仅体现在 Mac。

更重要的是,M1 版本 Mac 的推出,某种程度上也预测了另外一个技术趋势——未来,包括 Windows 在内的整个 PC 生态,也有可能以某种方式走向与移动生态的融合,从而使得个人计算都迁移到 ARM 之上。

这一次,微软可能真的要好好考虑如何与 Android 应用生态进行融合了。

本文参考内容:

  • https://www.windowscentral.com/windows-10-project-latte-android-apps

  • https://www.windowslatest.com/2020/11/25/windows-10-is-reportedly-getting-native-android-apps-support/

  • https://twitter.com/zacbowden

  • https://www.leiphone.com/news/202006/t28K1saB2LZnN1Uo.html

  • https://www.leiphone.com/news/201908/Pxijag74q2jxijeq.html


往期推荐


▎区块链第一股的AI芯片生意
▎小米的“铁蹄”
▎华为海思缺货,国产高端芯片谁来续命?
▎谷歌大举封杀麒麟SoC安装应用,彻底堵死华为;任正非回应剥离荣耀的真实原因;小米卢伟冰吐槽行业双标严重


分类
未分类

要不要读博?机器学习博五学生和强化学习博士展开了一场battle

机器之心报道

编辑:魔王
要不要读博?读博值不值得?如何才能顺利完成博士生涯,并为职业发展打好基础?最近,社交网络上就此展开了一场争论。

读博还是不读博,这是个问题。

是否读博、读博有多难是个经久不衰的话题。最近,一个 reddit 热帖再次点燃了大家的讨(tu)论(cao)热情。

一位机器学习方向博五学生谈论了他的读博经历,而主旨竟然是「为什么你不应该读博?」。


为什么不应该读博?

这位博士生分享了他在「博士之旅」中的一些观察,并表示自己的读博经历和体验并非个例。

以下是他的观察结果:

首先,读博耗时长,机会成本高,而最终的回馈却并不丰厚。这有点像是一个骗局。一些朋友还分享过教授不让学生毕业的「恐怖故事」……

但这只是发帖人认为不应读博的表层理由。

主要原因是读博伤害创造力和创新性。博士项目吸纳了很多视野广阔、有创造力和创新性、有抱负、积极进取的学生,略微天真但有梦想。这些学生在开始读博时拥有独特的想法和视角,以及解决问题空间的新方法,并且期待自己能产生影响力。

然而博士项目把这些都毁掉了。在博士项目结束时,学生被变成了机器,用和他人同样的方式来解决问题。他们被这样教导:这是 SOTA 方法,你只要对这些算法做出哪怕微小的改进就已经很幸运了

问题在于 SOTA 可能只是局部最优解呢。也就是说,这些学生被灌输的想法是用次优方法解决问题空间。这就难怪他们无法做出有影响力的东西呢,方法本身就处于平台期了。

那么如何使机器学习模型跳出局部最优解呢?对探索 / 随机化给予奖励。

发帖人认为我们需要反省教学方式。显然,为了高效,博士生需要具备一定程度的特定领域专业知识,但这不能以想象力作为代价,更不能是寻求新方法的勇气。99% 的新方法可能结果不如 SOTA 方法,但也许正是一个独特的、疯狂的 idea 会使领域变得更加开阔。

当你成为「专家」的时候,你获得了很多,同时也失去了很多。发帖人表示:「在开始读博前,我能够很兴奋地发动自己的想象力,思考一些天马行空的方法来解决问题。其中大部分想法存在致命缺陷,但我对此并不设限。」

科研应当是一场富有创造性的疯狂冒险。而博士项目吸引了有潜力带来巨大影响力的学生,然后又浇灭了他们的激情和创造性。这就像明星大学生运动员进入了一个执教糟糕的队伍,最后变得越来越差。

这篇帖子发出后,引发了大家对「创造性」、「一味追求 SOTA」等的激烈讨论。今天,reddit 上出现了一个回应帖,其标题是「为什么应该读博」。

为什么应该读博?

这位发帖人是一位强化学习方向的博士,ta 表示很享受自己的博士生涯,并阐述了从读博经历中学到的东西,给出了关于读博的一些建议。

ta 认为以下这些事情使得读博经历令人满意:

  1. 与导师建立富有成效的关系。如果你足够幸运,你的导师可能是世界级专家,还能即时回应你的问题,对你的 idea 感兴趣并提出有益的改进建议。

  2. 在不要求具体产出的前提下,了解自己感兴趣的主题。

  3.  日常工作能够匹配你想要建立的技能组合。

  4.  基于自己的 idea 自主创建项目。

  5.  拥有实验室专家资源,并锻炼与其合作、社交、接受反馈的能力。

  6.  获得去工业界实习的机会。

  7. 在顶级会议和期刊上发表工作。


如果你能从读博生涯中获得这些,那这次经历一定是有趣且值得的。如果你足够幸运,这还将为你之后的职业生涯奠定基础。

那么如何评估以上 7 点呢?发帖人提供了一些建议:

  1. 仔细阅读潜在导师的最佳出版物和近期有影响力的工作,确认其此前是否指导过优秀的学生。与潜在导师现在或之前的学生联系,询问他们与导师合作时的工作状态。如果可以的话,你还可以参与实验室轮转项目。

  2. 了解实验室同事是否有很大的论文发表压力。如果是,那么你可能很难了解其他领域。你所在的实验室 / 大学是否欢迎来自不同角度的创造性想法,是否有参加有趣讲座、和有才能的人进行交流互动的机会?

  3. 你将成为 PhD 所学方向的领域专家。思考这会带给你什么技能组合,读博结束后你又能凭借它们获得什么。同样地,你还需要思考获取这些技能的过程,以及你是否享受这一过程。

  4. 导师给你的是涉及狭窄主题的项目还是一幅更广阔的图景?(推荐后者,尽管风险性更大。)导师的发表文章主题局限于狭窄的主题还是多个相关领域?导师的工作是否具备较高质量?

  5. 与现在实验室的成员见面,尝试了解他们的兴趣、专业方向和合作意愿。如果他们近期发表过文章,阅读并与他们进行讨论。

  6.  博士期间的实习对学习和未来职业生涯很有帮助。机器学习领域能够提供很好的机会,请尽量利用好这些机会。

  7. 实验室同事是否经常在顶级会议和期刊上发表文章?他们的工作是否被广泛引用,或者更具体地,是否对领域研究产生直接影响?


最后,请记住一点,在现实中,你不太可能有机会满足所有这些标准,所以你的期望要合理,将读博可能获得的机会与非博士的机会进行仔细权衡,认真评估所有证据,然后跟着自己的直觉做出是否读博的选择。

此外,这位发帖人还强调:

沉没成本谬误是真实的。在考虑现有项目和未来项目时,如果你在一个想法上下了很大功夫却没有成功,不要害怕改变方向。同样地,如果你尽力了,但事情并没有解决,也不要怯于更换导师或合作伙伴。在止步不前时要及时发现这一点,并尽己所能(当然是在合理的范围内)摆脱它。如果事情变得很糟糕,不要害怕辍学。读博生涯应该充满兴奋和机会,而不是对失败的恐惧。


没有人能随随便便读完博士。去年,Nature 进行的博士生调查揭示了博士学位攻读中那些艰难的真相:科研压力、与导师的交流问题、就业压力等等。然而,依然有很多令人艳羡的「别人的博士生涯」。

当我们羡慕「别人的博士生涯」时,真正羡慕的是什么?当我们面临读博挫折时,是否要撑下去,能否撑下去?

以及最根本的,读博还是不读博?这个问题,你怎么答?

参考阅读:


参考链接:
https://www.reddit.com/r/MachineLearning/comments/k28qgr/d_why_you_shouldnt_get_your_phd/
https://www.reddit.com/r/MachineLearning/comments/k2pd9n/d_why_you_should_get_your_phd/

2020 NeurIPS MeetUp

12月6日北京,机器之心将举办2020 NeurIPS MeetUp。活动设置4个Keynote、 12篇论文报告与30个Poster,邀请顶级专家、论文作者与现场参会观众共同交流。

点击阅读原文,立即报名。

© THE END 

转载请联系本公众号获得授权

投稿或寻求报道:content@jiqizhixin.com

分类
未分类

从 iOS 1.0到 iOS 14,一文看完iPhone14年变迁史



  新智元报道  

编辑:白峰

【新智元导读】最近,苹果搭载M1的新Mac真是有点让人审美疲劳了。有谁还记得iPhone和Mac最初的样子?今天我们就从一个全新的角度,来回看下iOS的演进史。

最近看到A14和M1的报道,是不是有点莫名烦躁?

大家可能都忘了最初的iOS是啥样了,如果把iOS各个系统文件拆一下,会是怎样的体验?

今天我们就来扒一下iOS的演进史,不过,我们是从一个奇怪的角度,矩阵树图!

iOS的变迁史

What?2G的iPhone,发短信的年代回来了?

如果透视下文件大小,初代iPhone就长下面这样。


这能看出啥来,下面我们加点标注。


熟悉的/usr用户目录来了。

可以看到,iOS刚开始跟macOS差不多,框架占用了超过三分之一的大小,而字体竟然占了25%!

如果再细分一下:


这回我们看到了iOS 1.0的所有特性:


可以看到UIkit占总体大小的13% 以上, 墙纸和手机铃声占6%, ICU 需要超过5%,SpringBoard大约是2%。

接下来我们看看为啥字体占了这么大地方?

字体块由两部分组成:字体本身占了2/3,缓存区占了1/3。

那我们看看乔布斯,都在 iPhone OS 1.0中内置了哪些字体:


好像都不太熟,就一个Arial还勉强见过。好,我们快进一下。


可以看到,随着每个新 iOS 版本的发布,构建块的数量都在增加,而组件的数量却在减少。

转眼已经到了0202年,iOS 14已经上市。

毫无疑问,iOS 14要比 iPhone OS 1.0复杂得多:

iOS14变成啥样了?


这么乱!我们一个个来梳理。

主体结构仍然与最初的 iPhone OS 1.0版本非常相似: 字体、框架、应用程序、库、/usr都还在。

然而,两者还是有一些很大的区别:

iOS14包含了很多Preinstalled Assets  及Linguistic Data,这些组件用于设备上的机器学习: 语言检测器、声音、标记词、发声器;

Dyld 共享缓存是 iPhone OS 3.1中引入的一种缓存机制;

健康成为 iOS 14的一个重要特征

在 iOS 14中有如此多的组件,要想看清所有的组件得拿个放大镜了。

虽然现在很难列出所有的功能,但是有一些明显的趋势:

iOS 14设备上添加了更多的机器学习技术: 人脸检测,深度卷积网络,视觉框架,文本识别,神经网络等等;

许多组件与相机和照片有关: 效果,记忆,视频处理,照片库,Siri和语音都清晰可见。

以及这些年来增加的一些功能: HomeKit,Watch,CarPlay,Spotlight,Emoji,News,iWork,Wallet,Shortcuts,ARKit..

现在字体的大小还不到6%,语言数据几乎占总数的8%, 尽管自 iPhone OS 1.0以来,ICU 的规模增加了3倍以上,但现在大约只占总数的0.5%

为了更好的比较,我们将 iPhone OS 1.0与 iOS 14按一定比例放在一起,你会发现整个 iPhone OS 1.0基本上就只是 iOS 14壁纸的大小:




iPhone OS 1.0在2007年发布时,它重新定义了智能手机。现在 iOS 14包含了大量的智能组件。

通过树图的形势来观察一个系统,是不是变的很有意思,一些重要的特性变迁,清晰可见。

苹果的图像、视频、语言分析、声音分类和文本识别等人工智能技术,让iOS吃成了一个大胖子,但这个「胖子」正在让iPhone变的更加智能

未来的iOS,是不是要拿显微镜了?



分类
未分类

GitHub标星201K!这些爆火的Vue.js项目你知道几个


开源最前线(ID:OpenSourceTop) 猿妹编译

链接:https://medium.com/javascript-in-plain-english/top-7-vue-js-projects-on-github-19ba006d34e8


近日,VUE 作者尤雨溪在社区意见征求稿(RFC) 上提交了一份 Ref 语法糖的提案,引发了社区的争议。相关的语法更新,不过我们今天要讨论的不是这个。


说起Vue,可以说是前端人士必备的框架,在GitHub上基于它创建的优质项目也是数不胜数,今天我们就一起来看看GitHub上排名前7的Vue.js开源项目,累计标星高达210K:



1.Vue Element Admin

https : //github.com/PanJiaChen/vue-element-admin Star 61K


Vue Element Admin是PanJiaChen使用Vue和Element UI开发的可用于生产的前端管理仪表板。它具有许多功能,例如登录/注销,权限认证,多个构建环境,表,预构建组件等,这些功能都是直接可用的。



2. Awesome Vue.js

https://github.com/vuejs/awesome-vue Star 57K



该项目是由Vue.js创建和维护的,包含一系列的Vue.js的精选内容,对于刚学习Vue的新开发人员,甚至对于正在寻找示例,框架,库,工作等的经验丰富的开发人员来说,这个项目都是很适合的,这里面涵盖了大量的内容,因此很值得去看一看。



3. Element

https://github.com/ElemeFE/element Star 47.7K



Element是为Vue.js 2构建的最受欢迎的UI工具包。它由ElemeFE创建,旨在实现一致性,效率和可控制性。它专注于Web和桌面应用程序,因此不专注于移动开发。



4. Hoppscotch

https://github.com/hoppscotch/hoppscotch Star 24.2K



Hoppscotch是一个免费开源的API请求构建器。除了REST API支持外,它还支持GraphQL。它能够轻松快捷地为你的API生成文档。它是高度可配置的,提供身份验证,这绝对是你必备的工具之一。



5. best-resume-ever

 https://github.com/salomonelli/best-resume-ever Star 13.6K



这个项目可以快速帮助你构建美观的简历,它支持使用Vue和LESS构建的各种模板。你可以在本地预览自己的简历,还可以在模板之间随意切换,方便选择合适自己的简历。



6. vue-typescript-admin-template

https://github.com/Armour/vue-typescript-admin-template Star 2.9K



与PanJiaChen的Vue Element Admin类似,Vue TypeScript Admin Template具有相同的功能,但它具有TypeScript支持。



7. iHateRegex

https://github.com/geongeorge/i-hate-regex Star 2.4K



iHateRegex提供了正则表达式的可视化表示,你可以在“测试”区域中使用字符串测试正则表达式,并将可视化效果嵌入到你的站点中去,比如用户名、邮箱、日期、电话等,你只需要键入类型,它就会返回给你对应的表达式和演示字符。




分类
未分类

我们如何使用 Kong 替换现有的 Nginx?

作者 | 尤锦忠

API 网关 (API-Gateway) 是整体系统的唯一入口,作为流量入口,统一处理请求。它具有以下传统的功能:

  • 反向代理和负载均衡;

  • 动态上游、动态 SSL 证书和动态限流限速等运行时的动态功能;

  • 对上游的主动和被动健康监测。

其他附加功能:

  • 身份认证,限流熔断,统计,性能分析等。

网关主要有两种类型:

  • 接入层网关,为多样的客户端提供统一的流量入口,通过不同路由策略进行负载均衡,主要负责的是路由,限流,日志,缓存等功能, 我们使用的是 Kong;

  • 应用层网关,提供服务注册、服务发现以及熔断功能,我们当前使用的是 sidecar(ZuulFilter)。

好大夫的接入层网关最初使用的 nginx,在 2020 年初替换成 Kong。

1 为什么我们用 Kong 替换现有的 Nginx?

名词解释:

  • BFF(Backend For Frontend)聚合层:将后端微服务适配到不同前端;

  • Sidecar:我们使用的应用层网关,实现异构语言的服务注册和发现,以及熔断限流功能;

  • Microservices:微服务。

先聊一聊好大夫在线的架构:

  1. API 网关层,提供客户端流量的唯一入口,用于做反向代理和负载均衡,最初使用的 nginx 提供一些如路由、缓存、访问控制等基本功能;

  2. BFF 层,我们主要有 PHP(老)和 NodeJs(新)两类,这一层主要是做接口聚合,以及业务逻辑层的权限验证等;

  3. BackEnd 层,是我们的微服务层,是多语言实现的 (php,java,python),其中 php,python 通过 sidecar 注册到 Eureka 上,java 本身支持服务注册和发现到 Eureka。

我们引入网关 Kong 的契机是线上的流量有一部分是模拟用户抓取类流量,它的特点在于 QPS 的波动很大,当一波集中的抓取到来时,BackEnd 服务可能会因为 QPS 突增,导致机器负载的升高,响应变慢,同时影响正常用户的访问。如果不及时处理可能会引起雪崩效应。

为了解决这个问题,我们需要细化区分各种流量,要有较强的识别和控制能力,以保障正常用户、正常抓取的流量,同时排除掉异常访问的流量。在未引入 Kong 之前,我们能想到的办法是在 Api 网关 nginx 层做流量控制,以及在我们的应用层网关 sidecar 做流量控制。但是这两种方案都有一定的问题:

  1. 使用 nginx 进行流量限制,问题在于 nginx 的配置规则是以静态文件的形式进行管理的,无法通过 api 或者后台灵活的修改流量的封禁、降级和调度策略,同时配置生效需要 reload;

  2. 从我们的架构图可以看出,应用层网关 Sidecar 只负责处理服务出口的流量 (即请求发起端),发起端可能来自各个系统,因此通过 Sidecar 进行发起端限流,限流值设置的波动会非常大,粒度也因为过细而不好控制。

以上两种解决方案,对我们日常精细化运维流量都不够友好,所以经过调研,决定在接入层引入 Kong 来替换 nginx,进而从源头细化流量。

2 网关选型,为什么选择 Kong

从表格上可以看来,Kong 的社区的活跃度比较高,基础插件功能支持的也比较多,而且 Kong 的技术栈是 nginx+lua+openresty,从学习成本上来说,由于我们原先的技术栈是 nginx 的,因此选用 Kong 的学习成本会比其他语言的网关低很多,而且在迁移老的 nginx 配置过程中,转化旧配置的 nginx 配置也会比较友好,所以我们最终决定选择 Kong。

3 Kong 网关介绍

Kong 是一款基于 OpenResty(Nginx + Lua 模块)编写的高可用、易扩展的,由 Mashape 公司开源的 API Gateway 项目。Kong 是基于 Nginx 和 Apache Cassandra 或 PostgreSQL 构建的,能提供易于使用的 RESTful API 来操作和配置 API 管理系统。

Kong 的优势:

  • 可扩展:数据存储在 PostgreSQL 数据库中,连接相同数据库的节点为同一集群,方便集群的水平扩展。

  • 模块化:可以通过插件功能来扩展 Kong 的功能,官方提供了一些免费的开源插件,而且自定义开发相对来说简单,插件的通过 RestFul 接口进行配置,非常灵活。

  • 可视化:Kong 所有规则对象都提供 RestFul 的接口,这就意味着可以实现配置的可视化管理,开源的工具:Konga。

Kong 的基本概念

名词解释:

  • Route 路由通过 host, path, header 等维度匹配客户端 url, 如设置规则 host:www.haodf.com path:/test1 匹配 url: http://www.haodf.com/test1。

  • Service 服务是对后端服务的抽象。

  • Upstream 负载均衡对象,用于设置主动或者被动心跳检测机制, 负载均衡规则(轮询或者 hash)等。

  • Target 配置的是后端服务的实际 ip 和端口。

  • Plugins 插件,附加功能支持身份验证, 限流, 拦截等,可作用层级 Route,Service, 全局。

请求流程简要说明:

当客户端发起请求时流量会先统一打到 Kong,Kong 通过 Route(路由) 对象来匹配规则,再通过 Route 去找当前请求对应的 Service 服务,最后通过 Upstream 负载均衡至后端机器。附加功能(身份验证,黑白名单等)通过 Plugins 插件的形式,附加到 Route 或者 Service 上动态加载,作用于 nginx 请求的各个阶段。

Kong 插件加载

Kong 的限流、身份验证等功能都是通过插件来实现的,我们来了解一下 Kong 插件的加载机制。

Kong 是 nginx+lua+openresty 的一个实现,上图描述的是 openresty 运行的各个阶段。

init_by_lua 用于加载 nginx master 进程配置,init_worker_by_lua 用于加载 nginx worker 进程的配置,rewrite_by_lua 是用于重写 url 和使用缓存的阶段,access_by_lua 用于权限控制,限流等功能,header_filter_by_lua 用于对 response header 头进行处理,body_filter_by_lua 用于对 respone body 体进行重写,log_by_lua 用于请求的日志记录。

Kong 就是在 openresty 各个阶段加入了 Kong 的 lua 代码来实现一些 Kong 的功能,以下是 Kong 的 nginx 简要配置。

init_by_lua_block {    kong = require 'kong'    kong.init() // 完成 Kong 的初始化, 路由创建,插件预加载等}init_worker_by_lua_block {    kong.init_worker() // 初始化 Kong 事件, worker 之间的事件,由 worker_events 来处理, cluster 节点之间的事件,由 cluster_events 来处理,缓存机制}
upstream kong_upstream { server 0.0.0.1; balancer_by_lua_block { kong.balancer() // 负载均衡 } keepalive 60;}
# ... 省略若干
location / { rewrite_by_lua_block { kong.rewrite() // 插件生效策略的筛选, 并执行对应的操作,只能处理全局插件 (kong 插件级别,全局 (作用于所有请求),route(作用于当前路由),service(作用于匹配到当前 service 的所有请求)),路由匹配未开始。 } access_by_lua_block { kong.access() //1. 完成路由匹配,2. 确认加载的插件 (并加入缓存) 3. 进入 balancer 阶段 }
header_filter_by_lua_block { kong.header_filter() // 遍历在缓存中的插件列表,并执行 } body_filter_by_lua_block { kong.body_filter() // 遍历在缓存中的插件列表,并执行 } log_by_lua_block { kong.log() // 遍历在缓存中的插件列表,并执行 }}
Kong 插件加载源码
for plugin, plugin_conf in plugins_iterator(singletons.loaded_plugins, true) do  plugin.handler:rewrite(plugin_conf)end

上述的源码是 Kong 在 rewrite 的阶段执行的,主要工作就是对已加载的插件进行遍历,然后执行各个插件的 rewrite 方法,其他阶段的插件执行基本也都是这个逻辑。因此简单来说,Kong 插件加载就是在 openresty 的各个执行阶段,对符合规则的插件进行遍历,然后执行这个节点插件对应的方法。

好大夫插件功能使用

Kong 原生插件:

  • rate-limiting 限流插件;

  • file-log 本地日志存储;

  • acl 访问控制列表;

  • key_auth 身份验证;

自定义插件:

  • 灰度发布插件;

  • rate-limiting-agent 插件;

rate-limiting,rate-limiting-agent 与 key_auth 结合实现按角色进行限流

我们的网站无时不刻的有流量在访问,如果流量远远大于我们系统可承载的范围的话,会导致系统的响应时间变慢,系统的吞吐量下降。因此为了防止这种情况的发生,我们对网站的各个路由都设置了限流规则。

流量划分

我们将流量区分为:正常用户的流量,蜘蛛流量,恶意抓取的流量。

  1. 其中蜘蛛流量和用户流量是根据 UA 进行划分的,蜘蛛流量的 UA(User-Agent)上会带有特殊的标识,比方说 spider,bot 等。

  2. 用户流量中根据访问行为分为了正常用户流量和恶意抓取的流量,对于我们网站而言,恶意抓取的流量的特点在于 ip 很散,但是 UA 不变,而且访问在短时间内突增。

限流流程
  1. 通过 key_auth 插件根据 UA 的特殊标识, 将蜘蛛流量和用户流量进行角色上的划分。

  2. 在蜘蛛角色的路由上设置 rate-limiting 限流插件,对蜘蛛的流量进行限流,限流值的设定是通过压测以及长期观察前端请求数与后端容量得到的结果。

  3. 用户角色中含有正常用户的流量和恶意抓取的流量,我们认为同一个 UA 的请求属于一个用户,而在短时间内同一个 UA 流量突增的请求属于恶意流量,因此对用户角色设置了 rate-limit-agent 限流插件,限制同一个 UA 单位时间的请求量。

告警监控

限流值的设置与调整是一个长期观察的过程,因此我们配套的做了一些监控画像,并在大量限流发生时进行告警。

1、非正常 UA 抓取(恶意流量)监控

非正常告警就是恶意流量,从监控图像上我们可以看出当前流量增长的 UA 是哪一个,在极端情况下我们可以对这个 UA 进行封禁(封禁操作可能会“误杀”到正常用户)。并且当抓取流量超过我们设置的阈值时,会触发告警。

2、触发限流的监控

当触发限流告警时,我们可以从监控画像中看出当前限流的 UA 与路由是哪个,以及当前 UA 与路由抓取的频率,同时还可以在触发告警时观察后端系统的容量,吞吐量,响应时间是否达到瓶颈,由此为依据我们就可以知道限流值设置是否合理。

通过 key_auth,acl 和 filelog 实现 kong 集群数据节点和控制节点的分离。

kong 分为 proxy 配置默认监听 8000 端口,用于接收客户端流量。admin 配置默认监听 8001 用于管理 kong 的配置项。

  1. 部署上,我们将 Kong 分为 proxy 节点集群和 admin 节点,proxy 节点只用来接收来自客户端的数据,admin 节点用于修改 Kong 的配置(路由规则,Service 规则,插件规则等)。

  2. 只有 Kong admin 节点用于做 Kong 规则配置,设置 admin 监听范围为 127.0.0.1 的 8001 接口,缩小 admin 功能的访问范围,只有本机可以访问。

  3. 非本机访问的请求只能通过 kong proxy 转发到 kong admin 的本地端口,通过 kong 的 proxy 代理使我们可以对这部分请求附加插件功能来做身份验证。

  4. OPS(好大夫内部的 DEVOPS 平台)调用和其他脚本调用需要加上特殊的 header 头标识用于做角色区分,通过 key_auth 设置角色,并通过 acl 设置黑白名单,来限制访问,最后通过 filelog 记录操作日志。

灰度发布插件

好大夫的容器化正在如火如荼的进行中,所以线上的金丝雀发布需求,理所当然的就由 Kong 来接管了。目前灰度插件支持两个维度的灰度需求:

  1. 根据固定 ip 或者 ip 段进行灰度;

  2. 根据指定 cookie 进行灰度;

这样我们就可以根据业务需求,将部分流量(如:北京地区 10% 的非登录用户)引入指定集群进行灰度测试了。

遇到的问题
nginx filecache 缓存替换的问题

之前,我们的前端缓存使用的是 nginx 自带的 nginx_proxy_cache 模块实现的,是磁盘类型的缓存,按现在的规模单台缓存大概在 200G 左右。在对接 Kong 的过程中,我们调研过两个方案:

  1. Kong 自带的 proxy_cache 插件。这个插件实现的是内存级别的缓存,主要的问题是当 Kong 节点重启时,缓存会被重置,数据需要重新缓存,缓存相当于被穿透,会带来一定的风险。

  2. 我们尝试通过自定义 Kong 插件 +nginx_proxy_cache 模块来实现与原先逻辑一致的文件缓存,但是遇到一个无法解决的问题:nginx 的 purge_cache_valid 参数不支持变量形式,这个参数是用来设置缓存时间的,无法以变量形式实现,也就意味着缓存只能设置一个通用时间,业务场景会因此受限。

所以,我们的前端缓存处理,目前还是放在 nginx 这一层了。

4 写在最后

本文主要对 API 网关的基本概念,以及 Kong 在好大夫落地的实践做了一些介绍。我们正在继续研究如何使用 Kong 来解决 filecache 的问题,以完全替换前端 Nginx,欢迎有相关经验或者问题的朋友给我们留言,大家一起学习和研究。如有意愿加入好大夫团队,可访问以下链接:

https://mp.weixin.qq.com/s/zi7SQ7UI-2Ro6qAogsSIsQ

作者介绍

尤锦忠:好大夫在线系统开发工程师,负责底层框架的开发和维护,主导接入层网关 Kong,目前在参与公司容器化落地实施。

今日推荐文章

2020年,值得收藏的50多种Kubernetes工具

活动推荐

后疫情时代,我们更需要思考如何将数字的 DNA 植入商业,让其 “内生” 的数字能力,帮助企业赢得竞争优势?在瞬息万变的商业环境中,如何掌握通行世界的前沿技术与产品能力,真正实现技能的精进与价值释放……

SAP 作为全球领先的企业软件供应商, 覆盖全球 43 万企业客户, 帮助客户进行数字化转型,其举办的 SAP TechEd 全球技术大会即将在 2020 年 12 月 15 日在线上举行,会议现场设置了企业集成与敏捷开发、数字化转型与智能 ERP、数据库和数据管理等 8 大专题,帮助企业克服短期内面临的挑战,迅速为企业创造价值。

还等什么,赶快点击阅读原文报名吧!

点个在看少个 bug 👇

分类
未分类

选型必看:Kubernetes 应用程序部署工具应该选哪些?

作者 | Karl Isenberg
策划 | 田晓旭
将应用程序部署到 Kubernetes 比较简单,但要进行大型项目管理实现配置自动化就相对复杂了,本文介绍了 Kubernetes 应用程序生命周期管理的各个阶段可能会使用的一些工具(主流非主流的都有),而且通过标注各项目背后的投资大佬,给大家提供一种选择的决策依据。

将应用程序部署到 Kubernetes 非常简单,只需要用 yaml 或 json 编写一些资源定义并将它们应用到 kubectl 中就可以了,但要实现配置自动化就相对复杂了。

在应用程序部署中,一个比较流行的做法是将持续部署和 GitOps 结合使用:每次对源代码进行更改后,资源都会自动部署。如果想要使用 GitOps 将应用程序部署到 Kubernetes,需要经历以下过程:

  • 容器映像构建, 将源代码和本地依赖关系构建到容器映像中。

  • 资源模板, 为环境定制部署资源的资源模板。

  • 包管理, 将多个资源捆绑到版本发布中,并管理包依赖关系。

  • 持续部署, 通常通过一系列操作和步骤,对环境进行更改。

  • 命令式部署, 以编程方式管理复杂的服务生命周期,并减少手动或简单的脚本化步骤。

  • 自动缩放, 根据资源使用情况和消耗情况,自动缩放来管理应用程序的响应和资源分配。

在本文中,我介绍了 Kubernetes 应用程序生命周期管理的各个阶段可能会使用的一些工具(主流非主流的都有)。由于很难客观地判断工具的流行性和成熟度, 因此我对这些工具进行了注释,说明了哪些大型公司对这些项目进行了投资,供你参考判断。不过请记住,大公司对一个项目通常可能会做多个竞争性投资,因此,仅仅因为项目拥有一位知名的投资者,并不能得出它可以长期生存和发展的结论。

希望此列表可以在你寻找应用程序部署问题解决方案时提供一些帮助。

1 容器镜像构建
  • Moby /buildkit (Docker) ——用于将源代码转换为构建工件的工具包。

  • kaniko(Google)—— 在容器或 Kubernetes 集群中从 Dockerfile 构建容器映像的工具。

  • img(Jess Frazelle) ——一个独立的,没有守护进程,非特权模式的 Dockerfile 和 OCI 兼容的容器映像构建器。

  • buildah (IBM/Red Hat)——用于构建开放式容器计划 (OCI) 容器映像的工具。

  • Source-To-Image(IBM/Red Hat)——用于从源构建工件并注入容器映像的工具。

  • Tanzu Build Service/kpack /pack (VMware/Pivotal) ——使用 Cloud Native Buildpacks 构建应用程序的 CLI 和服务。

  • Carvel /kbld (VMware/Pivotal)——用于构建映像并将其推入开发和部署工作流的服务。

  • Google Cloud Buildpacks(Google)——为运行在谷歌云的容器平台而设计的构建器和构建包。

  • Makisu (Uber) ——快速而灵活的 Docker 镜像构建工具,可以在 Mesos 和 Kubernetes 等非特权的容器环境中工作。

2 资源模板
  • Helm(Microsoft, Google) ——Kubernetes 包管理器。

  • Kustomize(Google, Apple)——用于定制原始的、无模板的 YAML 文件的 CLI,使原始的 YAML 保持原样并保持可用。

  • Carvel /ytt (VMware/Pivotal)——基于 YAML 结构的 YAML 模板工具。

  • jsonnet/go-jsonnet(Google) ——JSON 模板语言。

  • gomplate(Dave Henderson) ——用于 golang 模板渲染的 CLI,支持本地和远程数据源。

  • Mustache (Github) ——与框架无关的 JSON 模板引擎。

3 包管理
  • Helm(Microsoft, Google) ——一个 Kubernetes 包管理器。

  • Cloud Native Application Bundles (CNAB)/Porter/Duffle(Microsoft/Deis, Docker)——这是一个用于管理云无关的分布式应用程序的包格式规范、打包器和安装程序。

4 持续部署
  • Spinnaker(Netflix, Google) ——多云持续交付平台,用于快速高质量迭代发布软件变更。

  • Terraform Kubernetes Provider (Hashicorp) ——一个 Terraform 插件,支持 Kubernetes 资源的完整生命周期管理。

  • Concourse (VMware/Pivotal)——一个基于容器的连续事务处理程序,用 Go 和 Elm 编写。

  • JenkinsX(CloudBees)—— 用于 Kubernetes 的自动化 CI / CD,提供使用 Tekton、Knative、Lighthouse、Skaffold 和 Helm 的 pull 请求预览环境

  • Argo CD(Intuit)—— 用于 Kubernetes 的高效 GitOps 持续交付工具。

  • Tekton/Tekton Pipelines(Google) ——一个 Kubernetes 控制器, 提供 CI / CD 样式的管道资源。

  • Cloud Build(Google)——在谷歌云平台基础设施上执行构建的服务。

  • Skaffold(Google)——促进 Kubernetes 应用程序持续开发的 CLI。

  • Azure DevOps/Azure Pipelines(Microsoft) ——一种云服务,它可以自动构建和测试项目的代码,并将其提供给其他用户。

  • Brigade(Microsoft) —— Kubernetes 的基于事件的脚本。

  • Habitat/habitat-operator(Chef) ——Kubernetes 控制器,在 Kubernetes 上运行和管理 Habitat 服务。

  • gitkube(Hasura) ——使用 git push 在 Kubernetes 上构建和部署 Docker 镜像的工具。

5 命令式部署
  • Kubebuilder(CNCF, Google, Apple, IBM/Red Hat) ——用于使用 CRD 构建 Kubernetes API(以及控制器和操作符) 的 SDK。

  • Operator Framework/Operator SDK(IBM/Red Hat/CoreOS) ——用于构建 Kubernetes 应用程序操作符的 SDK。

  • KUDO(D2IQ) ——使用声明式方法构建生产级 Kubernetes 操作符的框架。

  • Pulumi(Pulumi)——可以作为代码 SDK 的基础设施,用于在各种云上创建和部署使用容器、无服务器功能、托管服务和基础架构的云软件。

  • Carvel/kapp/kapp-controller(VMware/Pivotal)——CLI 和 Kubernetes 控制器,用于安装应用程序 CRD 所描述的配置 (helm 图表, ytt 模板,yaml 文件)。

  • Isopod(Cruise)——在没有 YAML 的情况下,用于 Kubernetes 资源配置的表达性 DSL 和框架。

6 自动缩放
  • Horizontal Pod Autoscaler(built-in)—— Kubernetes 控制器,它根据配置的指标自动伸缩复制控制器、部署、复制集或有状态集中的 Pods 数量。

  • Vertical Pod Autoscaler(Google)——一组 Kubernetes 组件,自动调整运行在 Kubernetes 集群中的 pods 请求的 CPU 和内存数量。

  • Addon Resizer(Google) ——垂直 Pod 自动调用器的简化版本,它根据 Kubernetes 集群中的节点数量修改部署的资源请求。

  • KEDA(Microsoft)——一个基于 kubernet 的事件驱动的自动缩放组件。

  • Watermark Pod Autoscaler Controller(DataDog) ——扩展了 Horizontal Pod Autoscaler (HPA) 的自定义控制器。

  • Pangolin(Damian Peckett)—— 针对 Kubernetes 的一个增强的 Horizontal Pod Autoscaler,它基于 Prometheus 指标来扩展部署,使用各种高度可配置的控制策略。

  • Predictive Horizontal Pod Autoscaler(IBM) —— 自定义 Pod Autoscaler,类似于 Horizontal Pod Autoscaler,但是添加了预测元素。

  • Horizontal Pod Autoscaler Operator(Banzai Cloud)——Kubernetes 控制器,它监视部署或状态集,并基于 autoscale 注释自动创建 Horizontal Pod Autoscaler 资源。

7 写在最后

正如 DevOps 倡导者宣扬的那样:这与工具无关,而与观念有关。没有一个工具能给你带来让你兴奋的全生命周期端到端管理体验,因为每种工具都有他们自己的工具组合,通过与脚本和集成代码配合完成工作。

你可以找到能够很好地完成一件事情的工具,易于替换和扩展,也可以选择为你提供最大性价比的工具,让你更容易对项目进行管理,集成成本也更低,同时还拥有较好的端到端用户体验。以上的选择都没有什么错。

权衡这些因素后,你还需要看看这些项目背后的大佬,它是哪家公司投资的、项目的流行度如何?那些拥有大型公司或者有着多样化投资者的主流工具更具有持续成长性。不然,你选择后,项目不更新或者被抛弃了,那你只能花自己的时间和精力来维护这些工具了。

原文链接

https://medium.com/@KarlKFI/compendium-of-kubernetes-application-deployment-tools-80a828c91e8f

今日推荐文章

微服务中台技术解析之全链路分布式追踪系统实践

点个在看少个 bug 👇

分类
未分类

代码不止 | 2020 Google 开发者大会亮点回顾


2020 谷歌开发者大会圆满结束!

11月16 至 21 日,连续 6 天的线上科技盛会,

 晒出了众多让人眼前一亮的技术干货。


回顾全部大会精彩

扫描下方二维码进入官网日程页

👇🏻👇🏻👇🏻




接下来,让我们一起回顾大会的各个亮点吧!

14+ 产品线,50+ 精彩技术演讲,70+ 技术专家,6天技术演讲满满干货,快pick你最感兴趣的主题进行回顾!


点击图片回顾当日全部演讲



技术干货满满、大神观点集结,如果你错过了讨论,快来扫码进入大会知乎专题页,回顾大神观点吧!


23个城市的 GDG 社区正在同步举办 DevFest 2020 活动,100+ 演讲嘉宾带来了多个产品领域的技术分享。精彩活动还在进行中,点击寻找离你最近的 DevFest 开发者社区活动吧!

3位 “谷歌代码探索官” 带大家探索生活中的谷歌技术应用,近距离感受技术魅力。

科技美学

Android

此次 Android 11 主打

以人为本、控制、以及隐私安全

硬核的半佛仙人

Web,Google Assistant,,游戏和移动应用

从技术实力,到全球化,到数字营销,到账户体系,谷歌全部都有丰富的经验

极客湾Geekerwan

ARCore,Wear OS

体验了 Google 的 ARCore 和 Wear OS,确实明显感觉到了技术的进步,这些进步都离不开众多开发者的共同努力

我们携手中央美术学院的邬建安教授,运用 TensorFlow Facemesh 和 Posenet 模型,对互动者实现开源动态捕捉,带来了别具一格的 “心面孔” 艺术作品。



“ Google 面馆 ” 创新互动体验,基于 TensorFlow.js 中的 PoseNet 来实现动态捕捉,吸引了众多开发者“尝鲜”,也借此激发开发者的创造力。现在点击了解如何修炼成为 “拉面大师” !



艺术家钟愫君通过 Google 机器学习平台 TensorFlow 上的ML 模型对机器人进行训练,探索全新创作方法。了解更多艺术家与机器人如何演绎艺术创作。


今年开发者群体的多元、平等和包容贯穿大会始终。Google 女性开发者职业发展座谈会#ImRemarkable 互动周受到广泛关注,共同见证 ”她梦想“ 的启程。



通过语音访问、实时字幕等辅助功能,我们鼓励开发者实现无障碍开发,为更多人带来科技的便利。



以创新产品和贴心支持,谷歌将继续携手中国开发者一同代码不止, 创新不止


意犹未尽,想了解更多详情?

别忘了去官网日程页回顾大会精彩!


另外也希望大家花几分钟时间填写问卷,帮助我们进一步深入了解大家对开发者大会的期待和评价。


获奖名单公布


从 11 月 13 日和 11 月 15 日推文留言中,

我们随机抽选了积极参与互动的 6 位 “锦鲤”

送出 “谷歌观会大礼包” ,名单如下:

ttt,藏鋒斂穎,某地瓜

咚,Gh Zhang,邓松Sheldon

记得尽快回复你们的联系方式和邮寄地址,

我们会尽快安排奖品的寄出。


没被大奖砸中,也能拥有快乐,

#Google开发者大会# 转发至朋友圈,

邀好友一同回顾 “代码不止” 带来的创新体验吧!



分类
未分类

与10倍开发者共事两年,我学到了不一样的东西

作者 | Jeffrey Bakker
译者 | 核子可乐
策划 | Tina
与 10 倍开发者共事,足以改变自己的职业生涯。

最近,我在网上看到不少关于 10 倍开发者的讨论。有些人想要成为这样的人,也有些人想远离这样的人。但在此之前,我们可能先要弄清楚这样一个问题:10 倍开发者真的存在、只是传说,或者仅仅是人们由于相对认知而感受到的概念?

在得出结论之前,我想先给大家讲讲自己的经历。

1 与 10 倍开发者共事

大约十年之前,公司的软件开发总监雇佣了一名三级软件工程师,我们都叫他 Gary。大概在同一时期,我们还雇用了一位名叫 Mitch 的二级软件工程师。最初几个月里,Gary 非常安静,总是一个人待着,努力解决一个个纯技术性的问题。当时我们的任务,是为实时 3D 机械训练软件制作空气等流体的流动动画。公司里的每个人都一直希望实现这个效果,但由于种种挑战,始终未能达成。而 Gary,成为帮助我们冲击难关的英雄。

在他准备把功能提交给 QA 进行审查时,整个功能的观感至少比我想象中还要好,性能也超出预期,并拥有数千项单元测试断言作为支持。相比之下,我们的主体代码库根本就没经受过这么全面的测试。不用说了,各级管理人员都对这项睽违已久的功能感到非常满意。

我们的代码中有很多庞大,而且复杂得让人害怕的部分。

不久之后,Gary 又组织了一次工程展示。展示内容主要集中在架构层面,即围绕对象生命周期、依赖倒置、ad-hoc 生命周期 / 明确限定范围的对象、某些分配反模式的危害、有碍单元测试覆盖的代码耦合,以及这些因素与很多内部工程问题之间的关联等等。这次展示让与会者们感到困惑,甚至感到颇为尴尬。毕竟这一切赤裸裸的批评,指向的正是那些最早加入公司、并一路构建起知识产权体系的老员工。

我们的技术债务问题确实严重,但……也没有那么严重。虽然不会影响到生产力,但我们的代码中确实有很多庞大、而且复杂得让人害怕的部分。Gary 要做的正是揭露出这一切。但我们压力很大,因为我们每个人都是他提出的问题中的一部分。

他对现代软件设计的理解领先我们好几年。

这个人的特点是,他永远是对的。不只是在争论当中,也包括在各种判断当中,他更像是个全知全能的神。虽然我一直以先弄清事实再发言的好习惯著称,但我也得承认,在整个共事期间我一共只揪出过他一到两次不太准确的表达。和这样的人共事压力很大,因为同事们总会发现一些自己本该了解、但却一无所知的重要知识。考虑到他们往往与 Gary 有着同样的职称和头衔,这就更让人感到无地自容。

人性总有阴暗面,大家不喜欢那些特别聪明的人。特别是在对方提出的真知灼见既正确、又缺乏善意时,就更是让人不爽。所以同事们的普遍共识是,这家伙是个刻薄鬼。我个人并不觉得他是故意要让人难堪,但 Gary 在让人难堪这事上真的很有天赋。与此同时,他对现代软件设计的理解领先我们好几年,而这些心得还得在我们公司逐步实践,也许他觉得身边的同事真的让他很失望。

公平地讲,我们沿用陈旧技术与方法是有原因的,而且也靠这些旧办法开发出了强大的产品。任何公司都可能存在类似的问题。

Gary 强悍的技术实力加上对于敏捷流程的坚定拥护,最终挤走了雇用他的老领导,并由他自己上位。同事们震惊了一段时间,但很快就发现 Gary 主管带来了一系列令人兴奋的新变化。公司调整了自身产品各类,Mitch、我和另一位新任软件开发测试工程师(SDET)并纳入新团队中,尝试公司之前从未做过的工作。

根据交流感受,Gary 一直以为我是二级软件工程师。但在发现我实际上只是一级时,他相当愤怒,并很快去找公司高层理论。几周之后,我就升职了。同样的,Mitch 虽然只是二级软件工程师,但他却拥有不逊于三级工程师的知识与技能。但没办法,他只能等……不知道在等什么,总之需要一段时间才能得到与自己水平相符的职称。

有时候,Mitch 与 Gary 形影不离。我记得我们曾经花无数个小时在办公室里对未来新产品的架构设计组织头脑风暴与思维实验。到这个时候,我才意识到这两位的水平高到不知道哪里去了。有很长一段时间,他们两个人似乎开始用一种独特的语言交流。虽然他们之前从来没有协作过,但他们都认为公司内部缺少现代编程的基本概念。刚开始,人们不喜欢这两个人在那里说东说西;但事实证明,在他们碰头之后,两个人的编码效率确实高、质量也是真的稳定。

我这个人比较擅长处理技术上的困难任务,Mitch 特别聪明,而 Gary 则拥有最强的编码质量。更让人稀奇的是,虽然 Gary 总是在全体大会和管理层会议中占用很长的时间,包括设计并记录新的标准流程、为各个开发者提供帮助与指导,但我到现在也不太确定他究竟是怎么在短时间内为公司带来这么显著的生产力提升的。总之在他的带领下,整个团队都不需要加班了,包括他自己。

让所有开发者拥有共同的价值观,是建立和谐团队与强大代码库的关键。

尽管我已经有了几年的编程经验,但在 Gary 团队中度过的两年,绝对为我后续的高级开发者头衔奠定了良好的基础。他帮助我改掉了不少多年来养成的习惯——就是那种特别普遍,但并没什么用处,有时候甚至令人讨厌的习惯。相反,我们开始建立起更有前瞻性的视角,并积极使用先进工具与更高效的解决办法。而我从他身上学到的最重要一点,在于让所有开发者拥有共同的价值观,是建立和谐团队与强大代码库的关键。

我们开发出的应用程序几乎没有缺陷,性能非常好、易于扩展,而且能够在之后的项目中重复使用。从各个方面来看,这都是我在入职以来见证到的最令人振奋的技术成功。

如果这样的状况都不能给公司敲响警钟,那管理层就太失败了。

如果各位读者朋友也是那种重视工作、热爱工作的人,应该也曾被企业内的政治问题折磨得发狂。我怀疑 Gary 也是因为这个才决定离职,因为当时他并没有跳槽的打算。Mitch 在之后不到一年也选择离开,同样没有什么跳槽计划。两位最具才华的员工选择裸辞,这绝对是个强烈的信号。如果这样的状况都不能给公司敲响警钟,那管理层就太失败了——或者说,他们已经陷入了更大的问题当中。

Gary 给我的临别忠告是,“你需要多多表达自己。”回顾我们一起奋斗的那段时间,Gary 和 Mitch 都特别善于表达自己,他们有时候甚至不给我说话的余地。但只要把话筒交给我,我说出来的就一定会是有意义的东西。在他们的引导下,我意识到这确实非常重要。

我必须快速成长,帮助填补他们离去后留下的空白。虽然我的工作绩效同样非常出色,但最终我也离开了这家公司。我在这里度过了一段黄金岁月,也感激这家公司帮助我开启了职业生涯。但离别终有时,大家没必要总是强绑在一起。

几年之后,我仍然在把自己从 Gary 身上学到的价值观带到其他岗位上,也努力让自己成为一个善于表达的人。事实证明,这种价值观确实让我在其他公司里也获得了尊重与广阔的发展空间。

2 要点汇总

不知道大家在这个故事里有什么心得,下面我来谈谈自己的切身感受……

我们很难量化什么才是真正的 10 倍程序员,但这个问题其实没那么重要

真正重要的,是帮助你身边的人获得提升。

有些人可能会争论某个同事到底是不是真正的 10 倍程序员。这样的 10 倍到底是在跟谁比?10 倍又具体体现在哪些方面?

不少朋友都有过在一半的要求时间内完成了 4 倍工作量的经历,在项目中实现了更高的单元测试覆盖率以及更出色的代码质量,总体产出可以达到其他初级开发者的 10 倍以上等等。有时候,与具有一定经验的同行竞争时,您可能也凭借着更少的技术债务或者更强的特定领域专业知识达成了类似的优势。

但这一切终究会被慢慢抹平,大家会凭借类似的从业经验、使用相同的工具、基于同一套代码库、以相同的理念 / 流程 / 设计模式处理同样的技术债务。在这样的前提下,开发者之间的效率仍有区别,但恐怕绝不可能有 10 倍那么夸张。

问题的关键并不在于比其他人更强,而是帮助你身边的人获得提升。出色的开发者没有理由用自己的优势来打击其他同事,最重要的是为他人提供指导、发现阻碍生产力进步的因素、解决问题并防止其再次发生。这样,我们就能拥有一支真正有战斗力的队伍,而不只是围绕着一位开发明星原地打转。

成为专家,还是培养自己的专业性

自满实际是在沉默当中寻找安全感。

我们不该因为某人出于长久以来的习惯、使用得到广泛证明的标准与既定技术,并由此以毫无追求的安全方法完成功能实现就对其横加指责。结合自己的经历,Gary 当初眼中的我们就像是这样一群业余爱好者。他不太注意自己的态度,只是他希望整个团队成长为软件开发专家的心情完全可以理解。

但请千万不要忘记,其他人也是人,人总是有着种种缺陷。Gary 也是这样,他在第 100 次看到同样的错误时肯定要发脾气;只是这样的错误对其他人来讲属于“正常现象”。失去耐心的同时,你也失去了对同事们应有的尊重,这本身就是对专业性的践踏。

软件领域的专业性像是一条微妙的线,我们不能随时越界,但在看到需要纠正的系统性问题时也不应视而不见。在此期间,你可能会引发混乱、可能会树敌,甚至威胁到自己的这只饭碗……但自满实际上是在沉默中寻找安全感。

如果希望改变,请在社交层面找到完美的平衡点。要用心挑选提出建议的契机,更要用心挑选提出建议时的用语。

重视实践、技术与理念

如果能够做到,这一切将改变你的职业生涯。

这些东西并不能保证把工作效率提升 10 倍。但我可以保证,只要培养起这样的能力,您会对软件开发拥有更加深刻的理解。

  • 严格遵循 SOLID 设计原则

  • 使用 MVC 模式进一步分离关注点

  • 命令查询职责分离

  • 通过实时代码覆盖工具完成单元测试覆盖

  • 使用行为驱动型开发发现需求细节,同时实现 UI 测试自动化

  • 明确定义并强制实施“已确认的定义”

  • 代码质量与分支策略,借此保证源代码控制系统拥有良好的清洁度与性能

  • 拥抱敏捷理念,但不必被动接受 SCRUM 中强调的一切流程

在职业生涯中亲身实践这些目标并不容易,毕竟每个人都已经在成长过程中积累起了自己的一套工作方式。但如果能够做到,这一切将改变你的职业生涯。

10 倍程序员的背后,可能代表着 10 倍错误

这类开发者的根本问题,在于他们的顶头上司。

公司里还有一位与众不同的开发者,我们叫他 James。从某种意义上说,他在公司已经拥有相当丰富的资历,非常擅长处理一部分编程任务。但他不愿意为自己的错误负责,经理多次批评还是无济于事。

最要命的是,其他人的大部分工作都处于 James 团队开发成果的下游。所以如果他弄错了,每个人都能感觉到;而如果别人弄错了,对他几乎没有影响。这就是上下游依赖关系的基本特征,要求上游一方必须拥有强大的责任心。

那么,为什么会陷入这么糟糕的状况呢?因为这位牛仔不相信单元测试,觉得这纯粹是在“浪费时间”,但其他人需要为他的武断买单。此外,他会反复把有问题的代码(包括无法编译或者存在严重阻塞问题的代码)添加到其他人正在使用的分支中,搞得公司内部民怨沸腾。

这类开发者的根本问题,在于他们的顶头上司。这帮管理者没有建立良好的实践,甚至把这种独行侠式的坏习惯视为理所当然。

3 写在最后

我觉得这个世界上的 10 倍开发者也分好几种,有自私型的、有乐于助人型的、有平易近人型的,也有令人生畏型的。如果大家有天分能够加入 10 倍开发者阵营,希望各位能认真选择自己想成为哪一种类型。

原文链接:

https://levelup.gitconnected.com/top-lessons-learned-from-working-with-a-10x-developer-51de12383e25


阔别已久的 QCon 大会回来啦!对高可用架构、微服务架构、云原生架构、数据中台架构比较关注的技术人,可以关注 12 月 20 日在上海举办的 QCon 软件开发大会,邀请了字节跳动、携程、阿里、腾讯等公司的技术专家来分享这两年积累的经验。

目前大会门票 9 折抢购中,限时立减 680 元!优惠活动截至 12 月 04 日。查看议程可扫描下图二维码或点击【阅读原文】!大会咨询:17310043226(同微信)


点个在看少个 bug 👇

分类
未分类

世界,您好!

欢迎使用WordPress。这是您的第一篇文章。编辑或删除它,然后开始写作吧!