V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  FrankFang128  ›  全部回复第 20 页 / 共 278 页
回复总数  5543
1 ... 16  17  18  19  20  21  22  23  24  25 ... 278  
2021-03-23 17:36:44 +08:00
回复了 Coeus999 创建的主题 酷工作 <杭州>前端 nodejs_金融机构_30-100W 欢迎 full stack
你这跟没说差不多啊,转发的吧?
你要招 Rails 开发可以去 https://ruby-china.org/jobs 发帖
@zhq527725 英语要求口语很流利吗
2021-03-22 02:22:21 +08:00
回复了 FrankFang128 创建的主题 职场话题 面试官叫我手写 Redux(对话教程)
@MrTreasure 我平时也不用 redux,模板代码太多
2021-03-21 17:07:29 +08:00
回复了 FrankFang128 创建的主题 职场话题 面试官叫我手写 Redux(对话教程)
@jatai 那你手写一个 rxjs 怎么样
23333
我建议楼主切回 Rails,不要用 Node.js ,哈哈哈
2021-03-20 23:12:35 +08:00
回复了 FrankFang128 创建的主题 分享创造 写给前端工程师看的函数式编程对话(系列文章)
@cyrbuzz 唉,你白看了 :(
2021-03-19 17:07:17 +08:00
回复了 FrankFang128 创建的主题 分享发现 写给前端工程师看的函数式编程对话(连载)
2021-03-18 12:26:09 +08:00
回复了 FrankFang128 创建的主题 分享创造 写给前端工程师看的函数式编程对话(系列文章)
换个地方连载 https://v2ex.com/t/762762
2021-03-18 11:11:18 +08:00
回复了 FrankFang128 创建的主题 分享创造 写给前端工程师看的函数式编程对话(系列文章)
@huabalance 已更新
2021-03-16 03:22:18 +08:00
回复了 FrankFang128 创建的主题 分享创造 写给前端工程师看的函数式编程对话(系列文章)
@jinliming2 后来取消了这个提案
2021-03-14 18:58:15 +08:00
回复了 FrankFang128 创建的主题 分享创造 写给前端工程师看的函数式编程对话(系列文章)
@Livid 能把一楼删掉吗?
2021-03-14 13:33:01 +08:00
回复了 FrankFang128 创建的主题 分享创造 写给前端工程师看的函数式编程对话(系列文章)
大家请忽略 1 楼,1 楼内容是我发错了。
2021-03-14 13:30:20 +08:00
回复了 FrankFang128 创建的主题 分享创造 写给前端工程师看的函数式编程对话(系列文章)
方:我跟你举个例子,你应该知道 ++i 比 i++ 的性能要好很多吧?

学生:哦?为什么?

方:原因不重要,你可以看看[这篇文章]( https://www.omegaxyz.com/2017/05/20/aboutippandppi/),也可以不看。假设你已经知道 ++i 比 i++ 性能要好很多,请问,你在写 for 循环时,写 i++ 还是写 ++i 。

学生:我以前一直写 i++,听你这么一说,我是不是应该写 ++i

方:不用,因为编译器帮你优化了,编译器一旦发现 for 循环的第三个语句是 i++,会自动优化为 ++i,所以不需要程序员自己记住这么多规则,网上这种乱七八糟的优化技巧太多了,你能记住几个

学生:编译器这么智能!

方:你也不想想,写编译器的那帮人比写 JS 的人智商高多少。

学生:也是

方:甚至有的时候,你为了提高性能而采用的怪异写法,会降低程序的性能,因为它得不到编译器的优化。编译器一般会优化常见的写法。

学生:原来是这样

方:所以程序员应该尽量写符合社区习惯的代码,只在性能瓶颈处手动优化性能。但是由于 JS 和 Java 这帮人常年的「教育」,像你这样的新人已经都认为应该尽量不用「递归」,所以 JS 和 Java 的编译器没有必要花时间优化小众写法,优化之后反而会造成安全和 debug 相关的问题。

学生:那说递归「开销大」和「浪费内存」是不是也是类似的误区。

方:是的,如果某个语言特性被程序员用得多,编译器就会想尽办法让它变快。现在,你可以放弃你对递归的偏见了吗?

学生:可以,那我是不是还得放弃 JS 和 Java 的编译器?

方:是的,这两门语言的社区文化与函数式不太兼容,而且主流版本的编译器是不支持这些优化的,也许未来的版本有。

学生:那我再多嘴问一句,「递归」没有缺点吗?

方:也有,以后会讲,但是瑕不掩瑜,利大于弊。

学生:好,我先记下来,虽然还没有完全被说服。

方:我们是从哪聊到这的?哦,是从「你没法第一时间给出递归的写法」聊到这的。那么我给你出第二题,写一个将字符串反转的函数,不能违反「数据不可变」的约定哦。

学生:递归写法我会



reverse = (string) => {
if(string.length <= 1){return string}
let last = string[string.length-1]
let head = string.substr(0, string.length - 1)
return last + reverse(head) // 把最后一个字符移到前面,然后递归
}



方:写得还挺快

学生:丢下偏见之后果然写得快很多,不过还是觉得效率会慢、内存会浪费

方:过几天你就习惯了,我也会教你怎么优化。再来一个,快速排序

学生:简单



/*1*/ quickSort = (array) => {
/*2*/ if(array.length <= 1) {return array}
/*3*/ let [pivot, ...rest] = array
/*4*/ let small = rest.filter(i => i<=pivot)
/*5*/ let big = rest.filter(i => i>pivot)
/*6*/ return [...quickSort(small), pivot, ...quickSort(big) ]
/*7*/ }



学生:这个快排写得是真的爽,但我还是担心浪费内存,第 3 、4 、5 、6 行全是内存复制

方:哼,那是因为 JS 和 Java 的数据可变,所以不能直接复用数据啊。如果数据是不可变的,`let [pivot, ...rest] = array` 可以直接复用内存啊,rest 和 array 复用同一片内存问题不大

学生:好像是这么回事,那 rest.filter(i => i<=pivot) 呢

方:这个内存很难优化。但是你要知道,你用函数式写只用 5 行代码,用指令式写可能要 20 行代码,函数式追求的是逻辑上的简洁,先让逻辑变美,然后等遇到性能瓶颈了再上优化

学生:好吧

方:等下,你怎么好像对「数据不可变」还是没有完全接受啊,总想着改原来的内存?

学生:才第一天嘛,过几天我才能适应

方:好吧,今天就先到这里,明天继续。
2021-03-12 16:24:55 +08:00
回复了 FrankFang128 创建的主题 分享发现 掌握源码阅读的技巧 - Webpack 篇
2020-12-09 01:04:30 +08:00
回复了 pcell 创建的主题 React 为什么 react 函数返回新内容后页面还残留有旧内容?
2020-09-24 04:21:33 +08:00
回复了 Livid 创建的主题 Podcast 请教一个关于录音的技术问题
1. 借助手机的降噪功能,使用手机 Womic app 可以做到
2. 借助 OBS 的 VST 插件的降噪功能,效果还行
3. 买高级麦克风
1 ... 16  17  18  19  20  21  22  23  24  25 ... 278  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   4690 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 138ms · UTC 10:01 · PVG 18:01 · LAX 02:01 · JFK 05:01
Developed with CodeLauncher
♥ Do have faith in what you're doing.