写点什么

都是工程师,为啥别人那么优秀?面向未来的跨界开发技术 (上)

  • 2019-10-29
  • 本文字数:3480 字

    阅读完需:约 11 分钟

都是工程师,为啥别人那么优秀?面向未来的跨界开发技术(上)

本文是我在“重庆前端交流会(渝 FE )”上的演讲,整理分享出来,希望能对更多人有帮助,以及激起更大范围的讨论。本文并不是预先准备的演讲稿,而是后续根据 PPT 图片来复盘,所以内容跟现场表达可能会有些许差别。 感谢主办方的安排和组织,感谢热情的现场观众,以下是正文:


大家好,感谢渝 FE 组委会的组织,感谢各位付费来到现场,今天我给大家分享自己在面向未来的全栈开发方面的话题。


“面向未来的跨界开发技术”是一个非常庞大的话题,为了能够稍微具体一点来讨论,我想分解为两部分来讲。


首先是“面向未来”。何谓面向未来,如何面相对来?


保罗·格雷厄姆是一个我很崇拜的程序员、产品经理、作家和投资人。


他在《黑客与画家》中说过,“100 年后的编程语言……拥有最小最简洁核心”,我认为与其说这是“预言”,不如说这是他的一个“理想”。



另一个行业大牛松本行弘(Ruby 之父)读到《100 年后的编程语言》的时候,有不同的看法。


在《松本行弘的软件世界》中,他认为 100 年后的编程语言,存在无限种可能性,技术上是无法预测的(可能语音对话或者脑波输入?)


预测 20 年后的编程语言倒是可以试一试。松本行弘认为合理的预测方法是纵观过去 20 年编程语言的进化规律,然后将各语言的起伏线条延伸,就应该是 20 年后的编程语言。


根据这条线的延伸,松本行弘的预判是:编程语言要解决的问题将从“如何做”变成“做什么”,即完成一个任务需要的指令会更加简洁。



我更倾向于松本行弘老师的观点。我从 PYPL 上找到了下图,图中显示了十几年来一些编程语言的“有名程度”的变化值。


有一些基业长青的编程语言,比如 Java、C++;也有一些近几年才从无到有异军突起的编程语言,比如 Python、Ruby、Objective-C、Swift 等。



稍微分析一下,我发现新的语言兴起主要来自两个方面原因:


行业趋势从桌面到移动的转移,Swift 和 Objective-C 是这一种。


技术趋势从 how 到 what 的转移,简单的说就是更容易完成一个需求。这一趋势就不只由语言本身决定,还由该语言配套的框架决定。


比如 Ruby 的 RoR 框架就大大提升了 Ruby 在 Web 开发者中的竞争力,因为 Rails 内置了一些最佳实践,甚至直接可用的项目架构,让 web 开发更容易。


而 JavaScript 在 Node 端的发展也是由于 Express 的易用。当然到了后期 Node 的开发者更多了,会有更多竞争者加入,原本的框架可能会被更易用的框架来代替。



因此我开始调查一些框架的使用趋势,来验证这一判断。


先介绍一个我个人调研趋势的方法,就是在 Google Trends 中输入需要调查的技术关键词 + tutorial。这个方法样能反映英语世界中的开发者对特定技术的学习热情,也就能相对客观地反映出未来趋势。


以 JavaScript 为例,我们能发现 jQuery 已经不可避免地走下坡趋势,原因就是从 2014 年开始,直接操作 DOM 的模式已经被更易用的双向绑定和模板类库(Angular、React、Vue)取代。也就是说从“怎么改变页面的行为和样式”变成“改变数据,而让页面的行为和样式自动变化”。



除了框架的使用之外,我还专门调查了前端构建工具的趋势。


前端构建已经是现代 web 开发必不可少的环节。因为 HTTP2 还没有完全普及(有服务器的原因也有浏览器的原因),所以我们要把模块化的 JavaScript 和 CSS 模块混淆、打包以及 MD5 化,以减少 HTTP 请求数量并控制缓存。因为用户的浏览器的版本号不统一,所以我们需要把 ES2015、ES2016、ES2017 等新功能转译成大部分浏览器都支持的最小子集。这些工作都需要用前端构建工具来完成。


从前端构建工具的趋势来看,grunt 是先烈,但是日渐式微被 gulp 赶超,原因一是基于文件 IO 的流程比基于 stream 的流程慢很多,二是因为 grunt 的基于配置的方式比 gulp 的基于“正常 JavaScript 代码”的方式更固化,风格上不讨人喜欢。



而 webpack 兴起是因为 JavaScript 模块化编程这一趋势。webpack 和 Browserify 差不多是做一样的事情,就是把一个一个的 JavaScript 模块打包成一个文件(这一过程称为 bundle),然后在浏览器环境中使用。其实在服务器端的 JavaScript 模块也可以打包,不过没有太大必要。本来 JavaScript 原生不支持模块,所以就有了第三方规范(CommonJS 之类的),后来 ES6 新增了模块功能(就叫 ES6 Module),所以各种各样的模块要在一起协作就是要解决的一个问题。Webpack 和 Browserify 就是解决这一问题的。



我想,可以得出一个结论是,无论是编程语言,还是配套的框架,和对应脚手架,都长期处于变化之中。有一些框架和脚手架能够顺应一时潮流和风格,也许能暂时拔得头筹,但很容易就会被后起之秀(vue、webpack)超越,这样的迭代变化在未来也不会停止。


所以,唯一能面向未来的知识只有“又快又好地学习”的能力。



说到学习,我收到一个读者邮件。这个读者硕士毕业之后找了一份 C++的工作,但是产品方面不太喜欢,希望转行做 Python Web 开发。


我认为这个读者焦虑的主要原因在于两点:


从 C++ 到 python 转型学习的时间其实还比较短,远远不到 10000 小时。技能还不是很熟练,这时看到一些招聘要求出现大量不理解的词,就觉得理想与现实的差异太大。


学习过程比较独立,没有从做中学。



我说一下我理解的“编程”,可以分解为三点:智力、知识和经验。



具体如下:



具体到“编程”这门手艺而言,这三者都不可能单独去提升。也就是说不可能只提升经验,而不去学习;也不可能只是学习,而不去动手提升经验。


好的学习方法是循环式地,学习一些新的知识,然后边做边学(learn by doing),在这过程中再加入一些思考,提升智力。



对于有一些工作经验的程序开发者来说,可能已经进入这个循环中,遇到了一些瓶颈,这时候可以对照上图来看,现在卡在了什么地方。


对于初学者,或者从新开始学习一个技术栈的有经验者,就需要有一个学习路径。也就是“地图”,以及“我在哪里”。下图是一个学习 React-Native 的蓝图示例:



开启循环之后,就采用下面模式来循环。



我在 2010 年读到 Outliers(局外人)的时候,学习到了一个终身受用的概念,就是 10000 小时定律。


这个定律大家都听过,好像很简单嘛,一句话就概括了一本书。


其实不是的,这本书里有很多发人深省的内容。比如讲了比尔盖茨和乔布斯都是同一年代出生,周围的环境和他们自己的兴趣给了他们练习 10000 小时的机会,才会有机会成为微软和苹果的创始人。


10000 小时也不是重复重复再重复,而是要持续在 learning zone 去练习。不是在 comfort zone 枯燥地重复已经会了的事情,更不是在 panic zone 去恐慌。



我就这样跟这位读者说明了我的观点:


放松焦虑心情,工作才一年多,要成为 python web 开发的大师需要 10000 小时;


要找到一个 python 工作不需要 10000 小时,基本上 1000 小时可能就够了,但是要边学边用才有效;


开始用,而不是一直学。我看到你 fork 的 awsome-python,里面的工具很多,不要一昧追逐,可以看一些好的项目,自己去搭建博客、爬虫、CMS 等;


持续提交你的 github 代码,看到项目的功能越来越多,也能减少焦虑;


每天 2 小时也有点少,最好能增加到 4 小时。


过了一天,这位读者竟然给我送了一张亚马逊礼品卡表示感谢。所以我把这个故事分享给大家,也希望大家有所收获。



再讲一个我亲身经历的例子。


我为了保持对算法和数据结构的“感觉”,偶尔会在 LeetCode 上找一些题目来做,特别是网站现在支持 JavaScript 了,就更加方便。


有一天我看到这样一个题目。



大家先不要看我的答案,来想一想这个题目怎么解。。…我的第一次解法很直白,每次需要计算 i 到 j 之间的和的时候,就循环计算一次。心算了一下,感觉应该没有问题,就提交了。



然而,系统提示计算超时!


我看了一下超时的测试案例,是一个超长数组。更重要的是,系统对这个对象进行了多次求 sumRange 运算,导致超时。



唔……所以怎样才能不要运行那么多循环呢?各位开动脑筋想一想。。。


重点是题目中的“提示”部分。…于是我想到这个优化后的方案:在初始化对象时就计算出一个 sumToNumber 的数组,表示“从 0 到 n 的和”,这样要计算 sumRange(i, j)的时候,就只需要 sumToNumber[j] - sumToNumber[i-1]就好了,最后再处理一下边际情况。


因为假设数组不会变化,所以无需更新数组内容。


完美通过测试!



通过这个题目,我对时间复杂度和空间复杂度的印象又加深了,这是单纯看算法书不能提升的。


以上,就是我在学习编程、打磨手艺方面的经验。


作者介绍:


余果——腾讯社交用户体验设计部高级 UI 工程师,前端开发组负责人,UI 开发通道评委,腾讯云特邀布道师,《Web 全栈工程师的自我修养》作者。


本文转载自公众号云加社区(ID:QcloudCommunity)。


原文链接:


https://mp.weixin.qq.com/s/d9OGp2KUcnkuAdlb5zhhJQ


2019-10-29 13:37676

评论

发布
暂无评论
发现更多内容

TiDB x 安能物流丨打造一栈式物流数据平台

TiDB 社区干货传送门

战略引领 注重实绩 形成闭环——中国交建绩效管理创新与数智化实践

用友BIP

绩效管理

用友战略签约广联达,共同使能建筑行业企业高质量发展

用友BIP

建筑行业

使用 GitHub Action 自动更新 Sealos 集群的应用镜像

米开朗基杨

云原生 #go

负载均衡详解

天翼云开发者社区

负载均衡 服务器

云网络对等连接产品的高可用保证

天翼云开发者社区

网络 对等连接

校源行丨开放原子开源基金会赴北京信息科技大学走访交流

开放原子开源基金会

MySQL的index merge(索引合并)导致数据库死锁分析与解决方案 | 京东云技术团队

京东科技开发者

MySQL 数据库 索引 企业号10月PK榜

从原理到实战,详解XXE攻击

华为云开发者联盟

安全 后端 华为云 华为云开发者联盟

火山引擎DataTester:跨境电商网站,如何快速实施AB测试 ?

字节跳动数据平台

大数据 A/B 测试 对比实验 数字化增长 企业号10月PK榜

出版行业企业如何快速实现数智化转型?

用友BIP

Fast by BIP 出版行业

Flink测试利器之DataGen初探 | 京东云技术团队

京东科技开发者

大数据 测试 flink sql 执行过程 企业号10月PK榜 DataGen

软件测试/测试开发丨Python闭包与装饰器 学习笔记

测试人

Python 程序员 软件测试 自动化测试 测试开发

如何强制SQL走性能更优的hash join

华为云开发者联盟

数据库 sql 后端 华为云 华为云开发者联盟

户外裸眼3D屏幕合适用什么规格

Dylan

3D LED显示屏 户外LED显示屏 led显示屏厂家

FinClip小程序技术,加速国产化应用新进程

FinClip

开放原子开源基金会联合主办的2023 CCF中国开源大会即将开幕

开放原子开源基金会

开源 CCF

可制造性拓展篇│HDI(盲、埋孔)板压合问题

华秋电子

HDI

【华秋商城】海量现货库存 闪电发货

华秋电子

连接器

使用eBPF加速阿里云服务网格ASM

阿里巴巴云原生

阿里云 云原生 服务网格

EVE-NG初次启动及WEB客户端访问

小魏写代码

当HTAP已成标配,什么才是制胜关键?

MatrixOrigin

分布式数据库 云原生数据库 MatrixOrigin MatrixOne HTAP数据库

数据如何同步到云服务器

天翼云开发者社区

云计算 数据迁移

Trino容错模式深度测评与思考

华为云开发者联盟

大数据 后端 华为云 华为云开发者联盟 交互式分析

淘天集团大模型应用十大挑战命题发布

阿里技术

AI 校招 AIGC 淘天

以效率为导向:用ChatGPT和HttpRunner实现敏捷自动化测试(二) | 京东云技术团队

京东科技开发者

自动化测试 敏捷测试 HttpRunner ChatGPT 企业号10月PK榜

百度飞桨AI4S亮相全国动力学设计与反问题研讨会,助力汽车底盘智能设计

飞桨PaddlePaddle

深度学习 AI for Science

都是工程师,为啥别人那么优秀?面向未来的跨界开发技术(上)_文化 & 方法_余果_InfoQ精选文章