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

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

September 9, 2019 · 1 min · 70 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 · 桃翁

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

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

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

中肯的看待 996

最近 996.ICU 太火了。我本来不太想蹭这个热点,因为我的观念与很多人可能不相同,所以担心被骂,最近有读者问我为啥最近没有更新,最近我在准备晋升的事儿,所以也没怎么准备技术上的内容,但是对于 996 这件事儿上,我最近还是有很多想法,跟大家交流下吧! 后面我会将最近晋升的一些心得总结出来跟大家交流一下,毕竟涨工资呀,所以希望对大家有帮助。 一、反对 996 的本质原因 为什么要反对 996,说到底,就是钱给的不够。 这句话可能说到了心坎里去,咱们来理一理这个逻辑。 如果,发工资不按照一个月一个月发,不按照一天一天的算,而是按照小时、或者分钟、甚至秒来算,你会不会愿意每天多工作一阵子。 加入你现在工资每个月 10000,那么每天的日薪差不多是 480 左右,一天八小时,时薪就是 60。你每多工作一小时就可以多得 60 块,如果你不是三和大神(不知道三和大神的搜索一下,不然你可能不太好理解)的话,你大概率不会只工作 8 个小时。 所以,我觉得说到底,反对的就是企业搞 996,加班不给加班工资导致的问题。 对于头条,阿里这样的企业,虽然知道他们加班很严重,但是工资高呀,所以很多人拼了命的想去。 今天我在小道消息里看到这样一个观点,加班的时候不愿意加,看到别人拿年终奖拿得多又羡慕;自己体会这句话吧。 二、我的一些观点 讨论完了本质,我再说一下我的一些观点。 **首先声明,我是极力反对 996 的。**但是对于现在很多人的行为不是太赞同,所以写出来跟大家讨论下。 1. 不喜欢就走 在这场革命(说得似乎有点严重了)中,不少人想到终于有机会吐槽自己的公司了,垃圾公司,压迫员工,还搞 996。 对于这种行为我的观点是既然觉得在公司干得不爽,为何不走呢? 心里可能想着:我也想走呀,但是没其他公司要我咋办。 这种想法我感觉是一种弱者的态度,即表现出了自己弱,然后又抱怨现状。这种行为就像这样一群人,整天自己不努力,然后抱怨世界不公平,为什么我的爸爸不是王健林;为什么同一个老师教的,他的成绩那么好;为什么同一个班的,他的工作那么高;为什么一起进公司的,他为什么涨工资。 如果你有能力,不喜欢这个公司的制度,不能忍受 996,选择离开就行了呗。 所以,提升自己,让自己变得更强,不喜欢就走。 2. 其实我们已经很幸运了 作为程序员的我们,其实已经很幸运了,还有假期,还有双休,已经很不错了。有很多行业,根本没有休息,一年可能就只有过年的那几天会放,没错,我爸爸的职业就是这样,建筑工人,他们没有周末,没有节假日。 另外你在外面看到的环卫工人,外面开早餐店,饭店的,有过双休吗? 我说这点其实主要是想表达,我们应该少点抱怨,我们还是不错了,咱们让自己变得更强,多为社会做点有价值的事儿,让更多的人拥有双休,拥有节假日。这肯定不是取去革命能解决的事儿,不是去抵制资本家能干的事儿。 3. 多花时间来提升自己的工作效率 说实话,大部分人工作时间的三分之一都没有为公司产生价值。 这三分之一的时间你可能会早上用来刷下咨询,各大群水一下,看看各大新闻网站等待。也许还会去抽抽烟,跟同事聊聊天,以及有一些时间你无法专心工作等。 当然,不可能有人做到每天都百分之百的投入,但是投入的比例就是人与人之间的差距,这是一个影响效率的地方。 众所周知,在公司级别比你高的,经验比你丰富的,代码敲得比你快,完成任务比你好,这肯定嘛,别人工资拿得也高,所以干活也多。反过来也成立,活干得多,工资拿得高。你给公司创造的价值越大,那么你就应该拿更多的工资,后面我将晋升也会说到这个。 所以我们已经想办法提高自己的工作效率,在一定的事件内干更多的活,那么你就需要提高自己的能力,这样你就能在规定的事件内完成任务,当然就不需要加班了。 可能有人说,公司就是给你的任务是无论怎么做都做不完的,那么这种公司对于资源不合理安排,你可以选择第一点,不喜欢,咱就走。 三、这件事情我思考了哪些? 我在跟我周围讨论相关话题的时候,我感觉我思考的问题跟他们不同。比如: 为什么这个仓库,或者说这个网站会传播得这么快?在最开始的几十,几百颗 star 是怎么来的?为什么同样类似的项目,godie996(方应杭的项目,地址是:https://godie996.com)没有火起来呢?当时我们讨论了两个原因:一个是各大群的宣传,另一个是 996.ICU 界面做得好看。另外的原因供大家思考,欢迎在评论区给出你的答案。 为什么那么多人不满意自己的公司,而不选择离开呢? 为什么会这么多公司会搞 996 呢? 同样是互联网公司,为什么国外的大厂不搞 996 呢? 等等很多问题我觉得才是我们应该去思考的地方,我们只有去思源,才能从根本上解决问题,从表面现象去解决问题很多时候会走很多弯路。 对于这个我举个例子,古代的铁匠都知道百炼成钢,把铁红了,然后拿出来锤,然后又拿进去烧,反复几次,就会发现做出来的铁具很硬,但是不知道为什么,其实就是因为铁里面融入了炭。所以近现代的就直接在熔铁的过程中加入炭,就不需要反复锤炼了。...

April 3, 2019 · 1 min · 72 words · 桃翁

为什么现在面试都是面试造火箭

文章首发于个人网站:前端桃园 很多人总是抱怨面试官问一些平时不常用的知识点,比如算法呀,网络(TCP)等等,也就是大家常说的:面试造火箭,工作拧螺丝。 但是有没有想过为什么整个前端圈,或者绝大部分面试,不仅是前端,各种职位都是这样呢?难道就没人来解决这个问题吗? 我觉得,事实上,这是一种合理的行为,并不是因为存在即合理,而是本来就应该这样,接下来我以两个方面阐述我的观点。 一、 考验对专业知识的掌握的扎实程度 在张鑫旭的十问十答里的一个问题是,「前端开发基础扎实的标准是什么?」 这里面他对「扎实」的解释我觉得很适合来答这个问题。 「扎」其实可以理解为深度,你可以想象一个用一根针,扎你的皮肤,对一个点的压力,可以让你痛不欲生。 那么如何理解知识的深度呢? 我还是拿前端面试来举例,比如考一个快速排序,很多人就觉得这有什么好考的嘛,平时又用不到,引擎底层已经写好了 sort 方法,什么数量级用什么排序底层也已经实现好了,没必要考了呀。 但是其实面试官并不是想考你快排的代码是如何写的,说实话,花个十分钟,最多半小时,一个快排的代码你肯定可以记住。但是其实考察快排的真正原因可能不仅仅是考察代码,而是考察它的思想,分而治之(分治法),划分算法的运用。 另外可能会再问你,它的时间复杂度是多少,如何计算等这些问题,这些问题也不是来考你这一个算法的计算,而是通过这一个算法来看你知道怎么算时间复杂度不?以此来引导你为什么快速排序快,为什么同样是分治法的归并排序没有这么快。等等相关的算法方面的知识。 面试官所考察的问题只是各种底层思想的一个运用,通过这个实例应用来考察对底层思想的理解程度。所以很多时候大厂的面试总是从浅入深的问问题,直到把你问到不知道为止。 再谈谈「实」,实则可以理解为满,考察知识的广度。 想象一下什么样的情况你才会说一个东西实,给你一晚装满的米饭,并且还压一压,再放进去一些米饭,直到压不下去了为止,这个时候你会说满满的一晚米饭,很实在。 所以对「实」的理解就可以理解为满,全。 如何来体现你对知识的广度呢,也就是实。 比如可以考察一些你平时不常用的,但是你也许会用到的知识点。比如一些简单的算法和数据结构,链表呀,网络里面的 tcp/ip 协议族呀,函数式编程呀等等,一些 html5 的特性(比如 web-compoennt)等等。 你可能在平时编程中没用到,或者大多数前端工程师平时不会用到,但是这些是基本功是需要知道的,比如 React 源码中就用到一些简单的数据结构,链表(Fiber 树就是用链表的结构存的,是一个单链表,以及里面还有循环列表的增删改查),如果不知道树可以用链表存,如何对链表进行操作,那么可能你看源码就很成问题。里面还有一些位运算等,位运算平时也不常用吧,但是 fb 的工程师就用它来解决实际问题。 再比如 web-component,这已经是 w3c 提出的一个前端组件化的标准了,我国也有大佬用 web-component 实现了一些库,比如腾讯出的 OMI。 地址: https://github.com/Tencent/omi 所以狼叔在 「2019 大前端技术趋势深度解读」里提到可能他是下一代框架的标准。 我们前端变化得快,新东西也多,如何不跟上时代,多了解(主要了解,不是每个新东西都要去深究,因为你没那么多时间,大多数时间还是要用在平时用得到的地方)一些新东西。跟不上时代,也行就会慢慢的被淘汰,所以现在前端招聘基本上都会需要你会一门框架,不管是 React 、Vue、Angular,这些都是趋势,数据驱动,不再是以前拿起 jQuery 就是干了。 小节 在工作中常用的知识点,那些是最重要的,那么大家都会这些,**如果你不知道点,别人不知道的东西,这些东西比别人掌握得更深一点,面试官为什么要你?**也许你还是个双非(非982、211)。 我觉得在任何领域都适合一个定律,就是「T」字形发展,先把专业搞深一点,然后往两边扩展。 二、醉翁之意不在题 另外面试官也许会考你一些软技能,考你的不仅仅是面试题完成了那么简单。这点注意,越简单的题越不简单(好好理解这句话)。 我拿我自己的经历来举例,之前做小米的笔试题(是那种把题目发给你,两天内做好了发给他)的时候,有一道题是:求最大公约数的题目。 很多人看到这道题觉得很简单嘛,几行代码就搞定了,当时跟我一起做笔试题的几位竞争者也是,他们就写了一个算法。 而我当时想到,我觉得面试官在检查这道题的时候如果看代码还是有点麻烦,所以我就写了一个界面,界面上提供了可以点击的数字,还有输入框,还有几个计算按钮,一个结果框,用户可以通过点击数字,或者在输入框里输入数字进行计算最大公约数,还做了一些错误提示等。 这相当于做了一个应用,一个可以给用户使用的应用,所以最后因为这道题,我被录取了。 我被录取的原因,这些都是进去之后,老大告诉我的,当时很惊讶,竟然是因为这个。 所以之后我就越来越注重用户体验,多一些思考,让别人用自己做的东西的时候更舒服,更方便。 我期望的面试官 声明:我没当过面试官,所以以上内容大多是我思考(猜测)的,也可以用说用一种合理的解释,来解释了现在这种现象。 我期望的面试官是这样的,或者说如果我以后当了面试官我会怎么做。 作为面试官不是把面试者考倒,而是尽量挖掘面试者擅长的地方,然后去打破砂锅问到底的看对擅长的地方研究有多深,考察深度。 在考察的时候先考察广度,再考察深度,从广度的问题中提取擅长的点,然后再问下去。 一些小提示 一般面试官不会因为你某道题没答出来就否定你的。 面试官不喜欢简历上写的啥都会,一问每个知识点都掌握得很浅。 对于平时常用的框架,至少要知道核心原理。 这些是之前我们组面试官在讨论的时候提到的,希望能给大家帮助。...

March 17, 2019 · 1 min · 71 words · 桃翁