程序是写给人看的，而不是写给电脑看的。
- DRY：Don’t repeat yourself
- 开闭原则
- 最小惊讶原则
我是 justjavac，可以来问我任何问题！
，感谢，学到不少
justjavac
#75
我们常说：程序 = 算法 + 数据结构。
这是 Niklaus Wirth 的名言，除此之外他还有另一个幽默名言：
软件变慢的速度永远快过硬件变快的速度。
一个误区。
很多后端开发者都觉得前端简单，根本不需要用到数据结构和算法。其实反观那些后端程序员，每天也就是 crud 操作，用到什么算法了呢。对数据排序，直接 order by，然后数据库引擎就已经排好了。。。。。
其实，很多人误以为数据结构就是链表、队列、二叉树、红黑树、…… 而算法就是排序、查找、KMP、迪杰斯特拉、……
鉴于这是 React 社区，我们就用 React + Redux 举例吧，在 Redux 的 Store 中，我们保存了应用的状态，那么这些信息如何存储呢，也就是这些数据以什么数据结构存储呢。
是扁平化形式，还是树状形式，还是其它形式。对于每种存储形式，都有各自的优缺点，有些结构查找很快，但是存储慢。而有些结构则相反。对于扁平化数据来说，关联查询的复杂度很高，很慢，那怎么解决呢，可以为数据增加索引，以空间换时间，使得查找可以达到 O(1)。
在性能优化的时候，我们需要对比变化前后的 state 和 props，如何高效快速的比较就要用到算法的知识。
在学习算法时，我最感兴趣的就是 KMP 算法。这是一个字符串匹配问题，通过 KMP 算法把复杂度从 O(m*n) 优化到了 O(m+n)。
让我们回过头来看看 React。
React 使用虚拟 DOM，本质上就是特殊格式的对象。当状态变化时，React 需要比较变化前后的虚拟 DOM 树，这就需要对 DOM 树进行 Diff 算法操作。即给定任意 2 个树，找到最少的转换步骤。我们都知道 2 个树的 Diff 算法复杂度时 O(n^3)，但是 React 中 DOM 树的 Diff 算法的复杂度时 O(n)。是不是很震惊！！！
到底是怎么做到的呢？
其实很简单，那就是场景。我们学到的那些算法都是通用算法，而我们在工作中也很容易写出比那些算法更好的算法来，因为我们的程序是运行在特定的场景（数据格式）下的。
比如 React 中 Dom 树的比较：
同层比较。
随着单页应用（SPA）的兴起，算法和数据结构在前端也越来越重要。
1 Like
justjavac
#76
首先做一名程序员，其次是前端程序员。
我说这句话的针对点是，有很多从切图而来的前端程序员，其实很多老一辈程序员都是从切图仔过来的，还有一部分没有 cs 基础。
最近几年也是前端飞速发者的几年。大概是赶上了 html5 的快车，再加之 es6 的发布，已经 nodejs 的流行。而前端开发也很之前大不相同了。
我们以前实在开发 web page，而现在我们开发的是 web app。两者有什么不同呢？前者的用途是“看”（浏览），而后者的用途是“用”。
所以前端对开发者的要求越来越高了，前端开发再也不是之前的那种“做做轮播图，做做点击特效”那么简单了。所以我说：“首先做一名程序员，其次是前端程序员”。因为以前根本不把前端当作程序员看待。以前他们称 JavaScript 为 “Java脚本”，就好比那些网管会写一些批处理，会写一些shell，但是我们并不认为他们是程序员一样，以前后端程序员也觉得在页面上写几行“Java 脚本”算什么程序员啊。现在，那些只会在页面上写点 js 特效的也一样不能称之为程序员。
看看《C语言本与末》吧，非常不错的。
非语言相关的《代码大全》，很多程序员都谎称自己看过，其实都没看完过，我也只是看过其中的某些章节。
看书至于，多多动手
justjavac
#77
痛点啊。
其实我 css 也不太好。这也是大部分前端开发者的通病。很多人提到过编程圈的鄙视链，一般前端程序员都在最底层，但是写 JavaScript 看不起写 css。他们觉得 JavaScript 是一门语言，而 css 。。。。(｡･∀･)ﾉﾞ
至于 css 为什么这么难学，推荐你看看黄玄hux在知乎的这个回答：为什么 CSS 这么难学？
justjavac
#78
学了不会用。
如果我在此给你讲庄子和惠施的故事就太哲学了。
问题显然不在于 vue，因为你即使学了 react 也一样难以实际应用。
那我只能弱弱的猜一下，原因可能出在了 目的上。我猜你学习 vue，可能是因为大家都在学习前端框架，所以你学完 JavaScript 后就想学一个框架，然后就选择了 vue。你的目的是学会 vue，而不是使用 vue。
首先你要明白为什么使用框架？（不就不问为什么学框架了，很多人会说为了找工作
）
一个框架的产生是为了解决之前的问题，为了预防将来可能出现的问题。在之前的开发模式中，开发者遇到过很多问题，很多开发者也总结了各种经验和最佳实践，这些经验和最佳实践导致了某个解决方案的出现，而这个解决方案对应的产出物就是框架，就是 jQuery，就是 vue，就是 react，就是 angular。。。。
对于学 react 的开发者，我推荐的第一篇文章就是：“Learning React Without Using React” 这篇文章构建了一个任务列表的app（todolist），但是文章上来就是使用的 jQuery，然后分析代码中的问题，一步一步的重构，最终重构的代码是一个类似 React 的东西。为什么我觉得这篇文章非常好呢，因为他教给开发者的是 React 框架的理念，思想，模式。反观其它 React 教程，只是教了一些 React 的 API 而已。
刚才我以 “lean vue without vue”为关键词，没有搜到相关的文章。
如果你不知道如何实际应用，不妨你也做个 todolist，然后再和 https://github.com/tastejs/todomvc/tree/gh-pages/examples/vue 对比一下，看看差距，慢慢进步。
justjavac
#79
还真没有。
我也一直再关注，但是很遗憾没有。
我经常去的就是
还有就是 chrome 的 bug 列表 https://bugs.chromium.org/p/chromium/issues/list
2 Likes
justjavac
#82
你应该不是指“才明白 JavaScript 为什么这么设计”吧，应该是“才明白 框架/系统/库 为什么这么设计”的。
我觉得对于开发系统来说，最重要的一个环节是“重构”，也是最能提升水平的环节。
重构 + Code Review。
justjavac
#83
都是泪啊。
所有的前端部门都缺一个"首席 webpack 配置工程师"。
其实不仅仅是前端，每个工程化的工程都很复杂。我家曾买了一个面包机，把面、鸡蛋、水等按一定比例放到里面，按下开关，只需要等 4 个小时就可以迟到香喷喷的面包了。很简单，很方便。
如果我想开一个面包店，那么买多买几个面包机肯定是不行的，因为这个面包机效率太低，家用还可以，但是无法商用。
工程化也类似，以前的前端很简单，几个 jQuery 插件就可以搞得，无非是页面的几个特性而已。我称此时的 web 开发为“手工业”阶段。
随着前端承载了越来越多的东西，很大部分业务逻辑也放到了前端来处理，此时的 web 变得多元化，而且复杂化。此时已经不再是 “web 作坊”的模式了，一两个人已经无法完成项目的开发了，那么很多问题也就随之而来：如何多人协作？如果合理分工？任务如何分解，成果如何合并？如何保证每个人的质量，如何保证整体质量？如何保证进度？……
对于 JavaScript 来说，最重要的一个方面就是模块化和组件化。在 es6 之前，多人开发同一个系统时，只能依赖规范文档，包含文件名规范、变量名规范、路径规范、class/id 规范、…… 否则最后的集成就是灾难。
而 webpack 的产生解决了很多问题，“一切皆模块”的理念也很符合 JavaScript 开发的困境。当我们说一个工具强大时，往往还有一个副作用就是复杂。
很多人有这种感觉，一旦 webpack 配置好之后就不敢再动了，生怕出什么问题。我一直也有这种感觉，认为 webpack 只前端工程化最失败的一个工具之一，知道我开发 React Native 的时候安装了 Android Studio 和 Gradle，突然发现 webpack 并没有那么不堪。
webpack 只是一个通用解决方案，一般公司项目都会自己开发一些脚本来简化整个流程。对于大多数项目脚手架来说，都是“一条命令就可以编译”了。比如 react-native，一条命令就可以便宜了。
新版 webpack 也开始“约定由于配置”了，但是整体来讲，还是有些复杂。
所以解决方案就是“自己的项目脚手架”。不仅仅是为了简单，其实 webpack 只是前端工程化的打包环节。工程化还包含很多，比如：自动化测试、自动化部署、持续集成、分支管理……每个环节都需要自己的脚本和流程。
1 Like
justjavac
#85
首先看看别人怎么写的，借鉴，但是不 copy。
我说的看不仅仅是代码，还有目录结构，编码规约，测试用例等等。
当你真正开发维护一个项目的时候就会发现，编码所占的比重远远没有你想象中的那么大。
然后你会明白，你到底是“写程序”，开始“做项目”。
此时此刻，应该将一个鸡汤故事(请自觉绕路，忽略下一段内容)：
在一个建筑工地，有三个人同时在那里搬砖。别人问，你在干什么？其中一人说，我在搬砖；第二个人说，我在修一堵墙；第三个人说，我在建一座大厦。十年后，第一个人还在搬砖，第二个人成了包工头，第三个人成了企业家。
鸡汤有毒，正文继续
对于程序员来说，很多人都在搬砖，“我们不生产代码，我们只是搜索引擎的搬运工”。对于搬砖型程序员来说，只看到眼前的代码。
而对于某些程序员来说，虽然是写代码，但是关注的是这个模块，这个组件，这个项目。
我一直教导很多初学者，不要写“拼凑型程序”，你的程序不是拼凑出来的，而是规划出来的。有很多程序员拿到需求后，就开始编码，想到哪儿编到哪儿。其实正确的方式是拿到需求先思考，先想想如何实现，在哪开始写代码之前，其实你脑子里面已经有大概的代码提纲了，你的思路要清晰，这样写出来的程序才清晰。
说句时候，在我这么多年的工作生涯中，曾经也换了多次工作，但是没有写过一份简历。
虽然如此，但是我看过几百份简历了，我简单说说我筛简历的感受吧。
有三种简历我会直接筛掉：
- 和同龄人或者同级别人比，毫无亮点的简历，直接筛掉
- 流水账式的简历，直接筛掉
- 工作经历造假的简历，直接筛掉
写简历就如实写，扬长避短就行。
对比一下：
简历一：
xxxx 年，参与 xxx 项目，使用 react、es6、webpack，主要工作任务是性能优化，重写了很多 React 组件，降低了页面加载延迟，在此次项目中学到了很多浏览器知识和 http 知识。
简历二：
xxx 年，参与 xxxx 项目，负责前端性能优化，使页面首屏加载时间从 3s+ 降低到了 1s 以内，基于基准测试对 React 组件做了常规优化，使整体内存占用率降低了 30%，组件性能提升 20%。
简历中，无关的废话不要多写，突出重点和自己的强项。第一个简历给人的感觉，仅仅使项目的一个参与者。而第二个简历给人的感觉是项目的突出贡献者。有理有据，数据说话。
对于第一份简历，面试时也只能问问“前端性能优化的手段有哪些？”
对于第二个，则可以问问前端优化方式的细节。
而且，第一份不一定有面试的机会。。。。
justjavac
#86
如果在公司学不到，那么就业余时间学学。
如果没有业余时间，那还是换一家公司比较好。
绝大多数开发者都是在维护老系统，绝大多数开发者都在写业务代码。但是，并不是新框架才是新技术，对于你不懂的东西，都是新技术/技能。
写业务代码一样可以提升，除非你业务很重很赶，那就没有办法了，毕竟质量和速度是成反比的。如果项目不紧，可以重新审查自己的业务代码，如何才能使代码更优雅，如何才能使每个模块更优雅，……
写 clear code 对于新人来说也是“新技术/新技能”。之前 shit 一样的代码被你写的更利于维护了，那么你也是在进步。之前高耦合的代码被你写的更加灵活了，这也是进步。
学习 rxjs 后，并不是使用了你有用。你学了它的思想，在你目前的业务里面一样可以写出类似的代码，而且你会发现你的代码质量变得比以前更好了。
高级程序员炫耀代码，低级程序员炫耀工具
2 Likes
justjavac
#87
我的学习方法就是多读书，多交流（不限于线上和线下）
我每天早上 5:30 起床看书，除了技术书籍外还有很多其它书籍。然后就是多交流多分享。
多写多做。
我们都不是计算机科学家，我们只是编程语言的使用者，学编程还得多编码。
我的建议就是：别用框架。
但是不要误解，不是让你放弃这个框架。其实当我们一旦使用了框架，就再也回不去了。如果你学了某个 mvc 框架，比如 react，你不知道如何提升自己了，那就放空自己，下一个项目别用 react，而用 jQuery，或者连 jQuery 都不用，写一个程序。
不是让你真回到之前的 jQuery 式的开发模式，而是使用 “jQuery + React思想” 开发一个程序，这样你才能真正的深入了解这个框架。
只有这样，你才能称之为”你控制了这个框架，而不是框架控制你“。
1 Like
justjavac
#88
年龄从来不是问题。
做科研的转编程，应该难度不大。前几天还有一个厨师转编程的向我咨询如何做职业规划的问题。
提到“性趣”，我多说几句“直白”的话，不过，不是为了打击你。
很多人喜欢开车，但是如果他当上了公交车司机、出租车司机……他还会对开车有“兴趣”吗，养家糊口而已。
编程也一样，很多人从小热爱电脑，热爱编程，但是一旦称为了职业，编程就是一份工作而已。如果一帆风顺，那么会一直“有兴趣”。但是难免会有挫折。
有个故事我在线下分享时讲了很多遍了，今天在 React 中文社区再讲一遍。
很所有故事都类似，这个故事的主人公也是“我的一个朋友”。
我的一个曾经的同事，有天他告诉我说，他的一个小学同学开了一个早点铺，每月转一万多甚至更多。他也想回家去试试。
他说，他对编程没有天赋，数学基础太差，还是做点小买卖比较适合他。
我告诉他，其实做小买卖很辛苦的，你只看到了他们赚钱，没有看到他们多累，每天都得凌晨三四点钟起床。……
他说：我能吃苦。
我：…… 如果你能每天早上三四点起来编程，你也早就可以独当一面了。你既然不能三四点起床编程，你就能三四点起床做早点吗？那些三四点起床做早点的是为了养家糊口，而你无忧无虑根本没有动力。
。。。~~。。。
后来他还是回家了。
等我在此联系他时已经半年过去了，他去了南方的一个城市。我和他寒暄了几句。他回家确实做了个小买卖，但是赔了很多钱，不得已又回到了一线城市继续编程。
如果你对科研工作毫无兴趣，那么其实 IT 也很枯燥。所以，当你想转行时，一定要考虑清楚了。考虑最坏的情况：如果你对 IT 不敢兴趣了，怎么办?是继续以 it 养家糊口，还是重回科研？
justjavac
#89
我两年换了不止两个工作。
既然不适合，那就别勉强自己。
确实大部分 hr 对频繁跳槽，或多或少会“在意”的。如果 hr 因为跳槽而否定一个人，那么这种公司不去也罢。
但是一般 hr 都会看看简历描述，自己甄别一下，如果跳槽是为了”逃避"，或者是一时冲动，或者是没有完美理由，那么这种跳槽可能确实会导致简历被筛掉。但是如果跳槽是为了“进步”，是对自己未来发展目标而做出的理性决策，那么那种跳槽反而称为了一个加分项啊。
～
justjavac
#91
把重复的工作交给程序去做，比如业务很相似，功能很相似、文件结构很相似，那么你可以考虑写个自动化脚本来做这些，或者写个脚手架，甚至可以和主管沟通，开发一个基础平台（或者在现有平台上开发一个子模块），用来配置这些重复的工作。
如果公司性质是外包，那么我的建议是换个平台。
对于程序员来讲，最重要的就是技术和时间。我们的时间在一天天减少，技术在一天天增加，我们就是在用时间换技术。当我们的时间减少了，但是技术却没有增加，那么我们就是在虚度时间。