看到这段话,真的觉得现在的读者要求比较高

最近看到这样一段文字,然后掘金的运营还发了一个沸点,看了心理觉得真不是滋味呀。 图片具体内容如下: 如果你在阅读文章的过程中,觉得有不同意的,请憋住,把文章看完再说。 现在的作者写个文章太难了呀。 写个文章还要被喷写得不好,写得不够有深度要被说没有干货; 写得有深度的又有人说看不懂,这怪作者吗? 咋不怪读者要求太多,自己看不适合自己的水平的文章,自己知道的东西就觉得人人都知道,却不知道在中国随便一个你觉得理所当然的小知识点,或者说常识,都会有至少 1 亿人不知道。 很多人在评论里说现在很多面试文章,或者 list 文章没啥质量,然后获赞很多,然后自己辛辛苦苦的写的干货没人点赞,在这个社会不是很正常么,想想马云工作的强度和在工地里工作的工人相比,工人不努力吗,难道不是辛辛苦苦吗?但是赚钱的差距就是这么大,这个社会就是这么现实,归根到底工人所做的工作价值太少了,为什么有些干货价值少,请继续阅读。 ##面试题和 list 文章 VS “所谓的干货” 说说为什么面试题和 list 文章,面试题和 list 解决了什么问题? 为什么会有这么多人习惯给这些文章点赞,我觉得最主要的一个原因是缓解了读者的焦虑,第二个原因是仅仅是为了收藏。 缓解了读者的焦虑 对于面试,肯定是永恒的话题,总想着换个好公司,涨工资,但是自己又太菜,想着有没有什么捷径,想了想,刷面经吧,刷了就等于会了,会了就等于能进大公司了。这种心理就跟买课一样,买了就觉得会了,然后生怕错过什么技术,买了一大堆,结果每个课程就只看了前面的开篇就没下文了,你能说这些卖课的不对吗?是你自己不看,能怪别人么? 然后说道别人发面试题,就想分享给大家,毕竟面试题往往都是对于前端开发来说比较重要的东西,是可以给你不仅是面经方面的东西,而且对于刚入坑前端的来说,不知道应该学啥,什么东西重要,什么东西应该先学什么的一个方向。 收藏 list 愿意点赞的往往是想收藏,然后可能是设计的原因,不管是哪个平台都一样,把点赞这个功能做得特别的容易,而收藏就要繁琐或者说不那么让用户想去点。 然后给大家一个建议,收藏这功能真的比点赞好用,可以对文章进行分类,自己可以梳理你的知识体系,然后建好分类,然后再分类收藏文章,这比起你点赞了,然后后面想去看的时候发现太乱了,又不好找,就给你不看文章找了个借口,导致点赞了一大堆,最终有收获的并不多。 我觉得在收藏这方便来说,个人觉得思否做得比掘金好(思否小姐姐是不是要给我广告费了)。 所谓的干货 干货这个词我的理解就是有价值,如果这篇文章对你有价值,那么就是干货,没有价值,你可能就会觉得是水文。 注意,我这里说的是对你有价值,才算是干货。因为一篇简单的文章,对于新手来说有价值,那么他觉得这篇文章就是干货,对于一个老手来说,几年前都会的东西,那么他可能就会觉得是水文。 所以,上面说到什么「浅谈」、「说说」都是没有干货的理论,根本是个人主观臆断,这些文章对于刚入门的同学来说,可能是带来了非常大的帮助。 注意,绝大部分人是知识的搬运工,传播者,而不是创造者,官网文档上有的东西,如果能用一种一部分人觉得通俗易懂的方式写出来也是有价值的,官方文章是普适的,但并不一定是最好的教程,而一些作者就是知识的传播者,可以理解为老师,把一些枯燥,正统的知识,通过一种针对特定人群的方式传达出来,然后学生能理解,那么就是一个好老师,好作者。这就跟你学牛顿三大定律不是去看他发布的论文一样。 总结 所以我觉得现在这样的面试题和 list 文章,并没有什么问题,有问题的是读者对于『点赞』可能理解得不够深刻以及没有正确的认识面试和 list 文章的价值。然后就是没有绝对的干货,一篇文章对于不同水平的人所得到的的价值是不一样的,当然我也更喜欢稀缺资源的文章,这样能给整个社区带来更大的价值。 声明下,我基本上是不写面试题和 list 文章的,所以我并不是为了自己写了这种文章而强词夺理。 给掘金说的 再给掘金提一点建议把,想让作者给你们带来更好的内容,这确实是双赢的局面。 你们对于用户的非常的关心,这是应该的, 但是,是不是应该给作者一些关心呢? 比如,对于评论的控制功能,对于投诉的功能,我看到有些作者写个文章被喷得很惨,心里真的很为她们难过,但是作为作者,一个删除评论的功能都没有,或者说不允许评论。 一些负面的评论真的会给作者带来很大影响,其实作为作者非常的希望大家友善的提出自己的建议,当有人说一些恶意伤人的话,有时候会影响到他上班工作的心情,甚至退出掘金平台,我已经看到过好几个优秀的作者,由于受不了掘金用户的评论,然后退出了掘金。 或者说除了赞,有一个踩的功能也挺好的,这样读者知道这篇文章写得不够好,然后自己会去改进,而不是一些「键盘侠」进行语言暴力。 作者和读者是一个双向的关系,维持双方的利益才是正确之道,不是作者把文章写的好就能改善整个社区的,反思的不仅仅是作者,用户也应该反省一下。 我见过最好的社区就是 Emacs 的社区,社区文章质量很高,社区里面基本上不会出现「娱乐化」,也没看到过「键盘侠」,也许是 Emcas 太难学了,导致过滤了很多不符合 Emcas 社区理念的人吧,所以 Emcas 社区不管是作者,还是仅仅是个社区的读者,都有非常高的素质,以至于社区环境很好。再次强调,不是作者写得好,社区就能搞得好的,好的作者也可能被读者被迫离开社区。 由于我做公众号,也在掘金写文章,所以和很多的作者进行交流过,非常多的作者会以给读者带来了帮助而激发自己写更好、更多的文章,我觉得用户给到作者的不是意见而应该是建议。这样双方处于和谐、和平的状态,才更有利于社区的发展。 我的看法 说说这位掘金用户说的东西,我相信你的初心是让社区变得更好,您说的也没有毛病,我也很赞同。 不过您是站在道德的制高点去要求作者,要有深度,要有独立思考能力,要有干货等等要求,但是您又没有给作者钱,他并没有义务按照每个人的要求来写文章。 这不就是白嫖要求还多的表现么。难道您说的这些要求,难道写文章的作者不知道吗,别人也许只想写下来做个笔记,好心随便分享给大家看一下。 这就跟朋友请你到他家吃饭,亲手做菜给你吃,然后你嫌弃这个咸了,那个淡了,这个不好吃,那个卖相太丑了,白吃白喝还要色香味俱全。 在掘金这个平台上,除了小册,没人有责任和义务把文章写得要满足所有的读者。如果小册写得不好,那确实应该要求作者改改,毕竟你花了钱,你就是『爸爸』,你就是顾客,顾客是上帝。 所以,我觉得现在社区不仅要控制文章的质量,还要控制社员的质量,比如像之前创建小号来喷京东小姐姐刘小夕,以及小生方勤的,这种文章就不应该出现在首页,这样会给作者带来了巨大的创伤。

September 9, 2019 · 1 min · 70 words · 桃翁

新手学习 React 迷惑的点

网上各种言论说 React 上手比 Vue 难,可能难就难不能深刻理解 JSX,或者对 ES6 的一些特性理解得不够深刻,导致觉得有些点难以理解,然后说 React 比较难上手,还反人类啥的,所以我打算写两篇文章来讲新手学习 React 的时候容易迷惑的点写出来,如果你还以其他的对于学习 React 很迷惑的点,可以在留言区里给我留言。 为什么要引入 React 在写 React 的时候,你可能会写类似这样的代码: import React from 'react' function A() { // ...other code return <h1>前端桃园</h1> } 你肯定疑惑过,下面的代码都没有用到 React,为什么要引入 React 呢? 如果你把 import React from ‘react’ 删掉,还会报下面这样的错误: 那么究竟是哪里用到了这个 React,导致我们引入 React 会报错呢,不懂这个原因,那么就是 JSX 没有搞得太明白。 你可以讲上面的代码(忽略导入语句)放到在线 babel 里进行转化一下,发现 babel 会把上面的代码转化成: function A() { // ...other code return React.createElement("h1", null, "前端桃园"); } 因为从本质上讲,JSX 只是为 React.createElement(component, props, ...children) 函数提供的语法糖。...

September 5, 2019 · 5 min · 1019 words · 桃翁

高级程序员与初级程序员差别在哪里?

之前在公众号里有个读者给我留言: 请教个问题,公司高职级和初中级,都是写业务代码,那么高职级的价值在哪里呢? 由于公众号回复留言的限制,当时我就简单的回复了如下的几个点: 初级多在写代码,高级多在设计代码; 初级多在解决一个问题,高级多在解决一类问题; 初级多在考虑技术问题,高级还要参与业务上的需求; 初级工程师只管接需求,导致自己忙不过来,高级工程师会砍需求, 用自己得经验告诉产品这个需求不需要,告诉设计师这个交互没必要; 初级工程师可能做完一个项目就完了,高级工程师可能会封装几个组件,整理一个脚手架出来。 还有很多很多,初级工程师和高级工程师差距不仅仅是代码质量上,而且其他能力上,解决问题的能力,抽象问题的能力! 今天有时间,想详细的跟大家谈谈我所遇到的、见到的厉害的程序员,同样是写业务代码,为什么会比初级程序员拿的工资高? 初级多在写代码,高级多在设计代码 一般人可能拿到需求,就开始写代码了,写着写着由于页面功能越来越多,感觉代码越来越复杂,自己都会觉得难以维护了。 我拿我自己举个例子,之前有一次我写完一个页面之后,然后给另外一个同事(可以理解为高级程序员)让他帮我 Review 代码,看到我的代码之后就觉得这个写得不对呀,怎么会这么去设计呢? 然后他给我理了下整个页面应该如何去设计,一个页面分为哪些块,有哪些事件,每个事件应该 dispatch 哪些 action,然后整个模块有哪些数据放在 store 里,哪些模块放在 state 里,当时反正听他理完之后,感觉自己写的代码真的很垃圾,然后花了两天时间把上周写的代码重写了一边。 注意,这里是重写,不是重构,重构是对软件内部结构的一种调转,目的是不改变软件可观察行为的前提下,提高其可理解性,降低其修改成本。那么如果保证不改变软件可观察行为呢?就需要写测试用例,保证测试用例能跑通的情况下进行重新构造代码才是重构的第一步,没有测试用例的重构就是耍流氓。 那么如何提高设计代码的能力呢? 我觉得有一个方法对于提高设计代码的能力非常有帮助,那就是采用 TDD(测试驱动开发)。 TDD 的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。 –来源百度百科 为什么 TDD 会提高设计代码的能力呢?可以看到 TDD 的原理是要在写代码之前就要写测试用例,在写测试用例的时候你必然得去思考你的每个函数,每个模块,每个组件应该如何去设计才能使得易于测试,往往易于测试的代码都比较好维护。 这就可以达到在写代码之前先去设计代码,然后才写代码,也就是先思考,后行动。 我只是说 TDD 可以提高设计代码的能力,并没有说我就特别提倡 TDD,说 TDD 很麻烦,难以实施的人就不要跟我讨论了。 初级多在考虑技术问题,高级还要思考业务上的需求 我们要知道,技术是为业务服务的,没有业务谈技术的好坏都是瞎扯淡! 常常可以看到很多实习生,或者刚来的应届生会吐槽以前的老代码用的框架老,用的技术旧,然后就去改成新的,自己觉得牛逼的,然后没有多个环境测试,发上线就挂了,这种例子很多很多,别说我们公司,就连我们组都出现过好几次这样的情况了。 这种就是只考虑技术问题的,而没有去考虑为什么以前前人要这么写,前人没有用这些东西,难道仅仅是因为那个时候没有新东西,或者说认为前人比你差。 很可能就是他们考虑到了业务上的需求,比如要兼容 IE、或者比如考虑到了有很多用户用 iOS,Safari 不支持 webp ,或者比如考虑到很多用户是低端机,性能不好,不能用一些新特性等等问题。 对于老板来说,他根本不管你用什么新技术,新特性,也许你用了新特性确实让代码更简洁了,但是,但是,但是,发到线上挂了,那么你写的东西就是垃圾,连最基础的稳定性都保证不了,更别说流畅性,高并发。 初级工程师只管接需求,高级工程师会砍需求 经常看到很多初级工程师就是,不管产品、运营甚至后端提出一些需求,他也很友好,只要是需求,他都接,然后整天忙忙碌碌,还经常加班,但是实际上,很多需求做了没有什么价值,也许还有些是重复工作,还把自己搞得很辛苦,这种情况真的很多很多。 然后还有一种情况是有一个产品需求来了,然后 balabala 一顿需求讨论之后,产品给出一个期限,初级工程师满打满算,可能能完成,然后就说能行,结果要么对自己能力估算错误,要么很多突发情况,然后不能按时上线。 而高级工程师基本上不会出现不能按时上线的情况,我思考了几点原因: 会给自己留 buffer,来避免突发情况导致时间的耽搁。 在需求分析的时候会思考每个需求是否有必要,如果有些需求觉得没必要,会和产品讨论,拿出充分的理由将需求砍掉。如果都有必要,然后时间又不太够,会去和产品谈是否能使交互简单一下,一期先出个什么样子,下一期再做完整一点。 对需求的评估以及自己能力的评估更准确。 这里我想要表达,不是所有的需求都是有必要的,不要每个需求都去接。 那么如果来判断一个需求是否应该接呢? 我觉得主要是去思考他背后的价值,为什么要做这个东西,做了能达到什么样的效果,如果产品说不出来价值,或者说产生的价值与你花费的时间不匹配,那么这个需求就是有待商讨的。 初级多在解决一个问题,高级多在解决一类问题 很多初级工程师可能昨晚一个项目就完了,还觉得很 OK 呀,然后也把在项目中的问题一个一个的解决了,按时按量的完成了任务。...

August 15, 2019 · 1 min · 164 words · 桃翁

Deep In React 之详谈 React 16 Diff 策略(二)

文章首发于个人博客 这是我 Deep In React 系列的第二篇文章,如果还没有读过的强烈建议你先读第一篇:详谈 React Fiber 架构(1)。 前言 我相信在看这篇文章的读者一般都已经了解过 React 16 以前的 Diff 算法了,这个算法也算是 React 跨时代或者说最有影响力的一点了,使 React 在保持了可维护性的基础上性能大大的提高,但 Diff 过程不仅不是免费的,而且对性能影响很大,有时候更新页面的时候往往 Diff 所花的时间 js 运行时间比 Rendering 和 Painting 花费更多的时间,所以我一直传达的观念是 React 或者说框架的意义是为了提高代码的可维护性,而不是为了提高性能的,现在所做的提升性能的操作,只是在可维护性的基础上对性能的优化。具体可以参考我公众号以前发的这两篇文章: 别再说虚拟 DOM 快了,要被打脸的 深入理解虚拟 DOM,它真的不快 如果你对标题不满意,请把文章看完,至少也得把文章最后的结论好好看下 在上一篇将 React Fiber 架构中,已经说到过,React 现在将整体的数据结构从树改为了链表结构。所以相应的 Diff 算法也得改变,以为以前的 Diff 算法就是基于树的。 老的 Diff 算法提出了三个策略来保证整体界面构建的性能,具体是: Web UI 中 DOM 节点跨层级的移动操作特别少,可以忽略不计。 拥有相同类的两个组件将会生成相似的树形结构,拥有不同类的两个组件将会生成不同的树形结构。 对于同一层级的一组子节点,它们可以通过唯一 id 进行区分。 基于以上三个前提策略,React 分别对 tree diff、component diff 以及 element diff 进行算法优化。 具体老的算法可以见这篇文章:React 源码剖析系列 - 不可思议的 react diff...

July 30, 2019 · 6 min · 1235 words · 桃翁

针对华为事件,我思考了四点

本来我是不喜欢追热点的,不过今天有个群友在群里发了这样一段话。 结果被我怼了: 后面的我就不截图了,反正我提倡的是,随时我们能做的是好好的提升自己,只有提升自己才是最重要的。 有些人同意我的看法,有些人不同意我的看法,这都不是我今天说的重点,只是这个导火线引发的我的一些思考。 不要让别人的文章限制了你的思维 这是我后来跟那个在群里发文章的那个老哥说的话,但是他也没有回我,这都不重要,重要的是我想表达的观点。 不要让网上的文章限制了你的思维。现在网上很多自媒体都是无脑夸华为牛逼,世界第一,美国傻逼,你转发他的文章代表你就是爱国的。你的这些感受都是作者想看到的,都是作者设计好的,你可以去看现在线上的一些写作课程,理论上都会有一些技巧是如何调动读者的情绪,引发共鸣等。 我不是说这种技巧不对,反而我觉得他写得很棒,他做到了他想要的结果。这样的小编很棒,我也希望我能写出这样的文章,双十万加(阅读量和点赞超十万)。 而是作为新时代的读者,我们不仅应该有爱国情怀,更应该有自己的想法,不要局限于作者的思路,应该以更大的视角,更全的视角去看待问题。 在《少数人走的路》里面就提到一条,思考是需要整体的,一旦你整体的去思考这个问题,就会产生矛盾,有了矛盾,才会使我们更深刻的去思考问题。 所以我们不要无脑的觉得转个文章,留个言这就是爱国,真正的爱国是什么:知道自己的技术不足,好好的搞技术,知道自己能力差,好好的提升能力。这才是支持国家,为国家做贡献了。 **穷者独善其身,达者兼济天下。**我们连独善其身都没做到,就有一股兼济天下的冲动。我还是之前在我看 996 那篇文章中提到的,一般人我们能做的就是好好的提升自己,等你有能力了,有钱了,给贫穷山区盖个小学,给慈善基金捐点钱这就是算开始兼济天下了。 另外一个群友发表了一个观点,我觉得还是有点用吧。 连马云这种等级的人都觉得自己的事儿忙不过来,何况一般人呢? 最后,如果想有更大的视角去看待华为,可以看看这些文字,视角不同,也许会改变你现在的想法: 任正非回应美国封杀:不要煽动民族情绪,不能狭隘认为爱华为就用华为手机 重磅!任正非最新万字访谈,回应关于华为的一切 | 深网 真的,老爷子的这番采访我特别的佩服,建议每个人看个一两遍。 不要总想着自己能得到什么,而是你能给公司(其他人)带来什么好处 这点我是在任老爷子采访里面这段话突然想到的。 可以看到,华为之所以这么牛逼,不是靠每天员工们 965 ,上班划划水,喊喊口号就能这么牛逼的,都是加班加出来的,一般人有他们辛苦吗?虽然别人公司顶着那么好看的光环,都是员工们努力、奋斗,用汗水换的。 很多人就是,又想公司强,又想工资高,又不想加班。当你站在公司外的角度的时候,又希望公司强,能抵制一切风险,工资高。但是作为员工,又不喜欢加班来使公司更强,总希望做受益者而不愿意去做点事情。 我们在与别人合作的时候也是这样,在去和别人合作的时候,请教别人问题的时候,别人能有什么好处呢?没有好处为什么要帮你呢?他又不是你的父母,无条件帮你解决一切能解决的事儿。 合作都是一个双赢的事儿,不要总想着占便宜,占便宜的事儿百分之百干不久的。 很多人在问问题的时候也是有问题的,本来群主有个技术交流群,不在群里问,非得去私聊群主(我已经听到很多群主抱怨过这个问题了),不知道是因为觉得群里问效率低,怕浪费时间,还是觉得自己问的问题蠢,怕被别人嘲笑。其实这都是不太好的一种做法,不然群主创建交流群来干啥呢?不就是想大家一起交流,别啥事儿都问他么。 如果你是觉得问问题怕浪费时间,那别人回答问题就不花费时间吗?如果你确实着急,那你二话不说,红包先上,肯定有效。别上去就是:“在吗;有空吗”,这会体现一个人不会用微信聊天。 我在一个星球里看到这样一段话: 和别人交流时,先搞清楚一个问题,这是交流还是请教,如果要谈的话题,你已经掌握了 90%的知识,这个叫交流;如果不到 90%,这个叫请教。无论哪种,都会花费别人时间。所以无论是否对你有帮助,都应该首先发红包。 我在之前的文章也说过,发红包不是因为回答的人差你这点红包,而是这是一种礼仪,知道你是麻烦了别人,表示一点心意。 不要想着总能说服别人 有这么一个故事:孔子的有一个弟子有一天跟一个人争论,争论啥呢?一年是三季还是四季的问题,然后这个弟子说服不了那个人,然后就带着他找孔子,弟子把事情说清楚了之后,孔子最后说的是一年只有三季。后来弟子就很疑惑,一年不是有四季吗,为什么你要跟他说三季?孔子就说,他一年只有三季了,你还跟他争论什么。 我当时在群里说了这么一段话,然后就有一个小伙伴不同意我的观点。 后面想了想,我也没跟他争辩,有可能我是错的,也有可能我是对的,我想了下,我没办法说服他,我就没有回复他。 我没有说这个小伙伴就是孔子故事里面那个三季的人,而是想表达当一个人所掌握的知识跟你差太远的时候,你没办法去说服他,他也没办法说服你,这个时候自己持有自己的观点就好,慢慢的,时间长了,学到的知识多了,见识广了,就能判断对与错了。 不要轻易相信别人的结论 吴军老师在得到课程《硅谷来信》里说过:科学是用来怀疑的,而不是用来信仰的。科学看重的是方法和过程,而不是结果。另外,科学的结论也未必等于正确的结论。 你可能会说,不是说不要轻易相信别人的结论,为啥你就觉得吴军老师说的这个话就是对的呢,岂不是和你说的互相矛盾吗? 我相信吴军老师说的结论,是因为他在课中所分析的逻辑,举的例子令我信服。所以我才相信他的结论。具体逻辑可以看《硅谷来信》的第 36 封信|科学的结论未必是正确的。 所以,我上面说的结论,也都有可能是错的,就连科学家得出的结论都有可能是错的。那我们应该怎么办呢? 我们在看有观点的文章的时候,应该注重得出观点的逻辑是否正确,而不是直接去判断观点。观点这种东西人人都能说,我说明天股票会涨,他说会跌。但是,说出一个合理的解释,这就不是每个人都能做到的。作为一个合格的读者,我们应该有自己的思想,自己的判断逻辑,而不是一味的去接收观点。 然后随便我们扯到学技术吧,我们在学习框架的时候,所有的大牛都会推荐你去学习框架、库的原理,而不仅仅是 api。原理就是上面说道的底层逻辑,而 api 只是最终的一个结果。

May 23, 2019 · 1 min · 54 words · 桃翁