blog
blog copied to clipboard
fouber
没事写写文章，喜欢的话请点star，想订阅点watch，千万别fork！
一个程序员的成长之路
# 一个程序员的成长之路 [FDCon2018](https://fdcon.topgeek.org/)大会上的演讲整理 ``` 主题：主会场 - 一个程序员的成长之路 时间：2018年5月19日 10:40 地点：中国 上海 演讲嘉宾：张云龙-全民直播-CTO ```  大家好，我是云龙，从2016年3月份开始，我参与到全民直播这个创业项目中，这两年一直在上海。关于我自己的成长历程，一直都很想找个时间跟前端的开发者们分享一下。通过剖析别人，也可以总结自己。我很害怕把这个主题讲的跟成功学一样，其实CTO这个职位现在多少有点“烂大街”，不算是什么成功，仅供参考。 我是2010年毕业的，刚毕业即加入百度，当年我毕业的时候同一批入职的人后来成立一个微信群，那个群在8年后的今天，我们还会一起扯皮闲聊，分享彼此的际遇。我发现它可以作为参考——8年前一群有着相同能力，相同起点的人，在8年之间因为做出不同的选择，最后达成了不同的人生。有的创业，有的在大公司做高管，有的炒比特币财富自由。参考他们的选择会让你有一些感悟: “如果当初我选择了那样，我现在会怎么样”。我现在经历了职业生涯8年的时间，也想把自己的经历作为一个案例，分享给大家。 在讲之前，先问一下在座的同学工作3年以下的举手。。。。emmm，剩下的都是三年以上的咯？我看了一下，比例差不多一半一半。 我面试过许多前端工程师，发现大家在工作了3-4年的时候会遇到一个迷茫期，我问他们你们接下来想做什么，大多数人回答说想做一个开源项目，并且推广开来，成为前端“网红”，更长远的职业发展规划往往考虑的很少。 今天，我希望把自己的工作经历完全拆解开呈现在大家面前，作为一个案例解答有关职业发展的困扰。  第一章: 程序员的中年危机。 我今年33岁，虽然有技术傍身，但是难免会有一些焦虑，这种焦虑来自对自己的能力质疑。在大公司的那些年，背靠大平台，做出的成绩80%是平台赋予我的，它有健全的体系，有优秀的同事，有完善的职级制度，还有优厚的薪资待遇。你在这样舒适的环境下做那么一小块事情，如果有一天你发现你这20%可以被替代的时候，这家公司会怎么思考？你有很多股票，开很高的工资，对于公司来说，你的成本很高，在新人的推动下，你会产生一种可被替代的压力，我大概在28岁，29岁技术水平还在上升期的时候就有这种焦虑。  在大公司那些年，我感觉自己还像一个没毕业的学生，始终没有脱离“学生气”，无论说话做事都有这种感觉。其次技术的更新迭代速度特别快，尤其是前端领域，你会发现很少有能真正沉淀下来的东西。第三个焦虑点就是关于企业如何对待35岁以上员工，我当时在百度的时候团队有一个非常厉害的工程师，他在2010年技术职级很高，但技术思维还停留在上一个时代，随着技术的发展，渐渐不能指引团队进步，那个过程比较艰难，对我触动很大。最后一点，就是随着年龄的增长，选择的成本会越来越高，你会有家庭，即便公司觉得你没有价值，你也不能走了，走不动了。这些触动了我，开始要去思考。  我们做技术，尤其是前端，很多时候我们做出的产品，看到的都是UI设计，交互设计 ，产品设计，即便我们做的产品非常成功，成功点在哪儿？可能是UI设计得漂亮，也可能是推荐算法精确，而前端的产出给产品带来了什么？还有前端技术深要深到什么程度？做久了技术就必须要转型管理吗？这些问题我当年没有答案，我可以坚持不懈得写页面，但是这个事情做5年，6年，10年不还是一样吗？现在我能做什么？未来我想做什么？ ...
大公司里怎样开发和部署前端代码？
> 本文搬运自我在知乎上 [同名问题](http://www.zhihu.com/question/20790576/answer/32602154) 中的答案。 这是一个非常有趣的 `非主流前端领域`，这个领域要探索的是如何用工程手段解决前端开发和部署优化的综合问题，入行到现在一直在学习和实践中。 在我的印象中，facebook是这个领域的鼻祖，有兴趣、有梯子的同学可以去看看facebook的页面源代码，体会一下什么叫工程化。 接下来，我想从原理展开讲述，多图，较长，希望能有耐心看完。 ---  让我们返璞归真，从原始的前端开发讲起。上图是一个“可爱”的index.html页面和它的样式文件a.css，用文本编辑器写代码，无需编译，本地预览，确认OK，丢到服务器，等待用户访问。前端就是这么简单，好好玩啊，门槛好低啊，分分钟学会有木有！  然后我们访问页面，看到效果，再查看一下网络请求，200！不错，太™完美了！那么，研发完成。。。。了么？ 等等，这还没完呢！对于大公司来说，那些变态的访问量和性能指标，将会让前端一点也不“好玩”。 看看那个a.css的请求吧，如果每次用户访问页面都要加载，是不是很影响性能，很浪费带宽啊，我们希望最好这样：  利用304，让浏览器使用本地缓存。但，这样也就够了吗？不成！304叫协商缓存，这玩意还是要和服务器通信一次，我们的优化级别是变态级，所以必须彻底灭掉这个请求，变成这样：  强制浏览器使用本地缓存（cache-control/expires），不要和服务器通信。好了，请求方面的优化已经达到变态级别，那问题来了：你都不让浏览器发资源请求了，这缓存咋更新？ 很好，相信有人想到了办法：**通过更新页面中引用的资源路径，让浏览器主动放弃缓存，加载新资源**。好像这样：  下次上线，把链接地址改成新的版本，就更新资源了不是。OK，问题解决了么？！当然没有！大公司的变态又来了，思考这种情况：  页面引用了3个css，而某次上线只改了其中的a.css，如果所有链接都更新版本，就会导致b.css，c.css的缓存也失效，那岂不是又有浪费了？！ 重新开启变态模式，我们不难发现，要解决这种问题，必须让url的修改与文件内容关联，也就是说，只有文件内容变化，才会导致相应url的变更，从而实现文件级别的精确缓存控制。 什么东西与文件内容相关呢？我们会很自然的联想到利用 [数据摘要算法](http://baike.baidu.com/view/10961371.htm) 对文件求摘要信息，摘要信息与文件内容一一对应，就有了一种可以精确到单个文件粒度的缓存控制依据了。好了，我们把url改成带摘要信息的：  这回再有文件修改，就只更新那个文件对应的url了，想到这里貌似很完美了。你觉得这就够了么？大公司告诉你：图样图森破！...
前端开发体系建设日记
# 前端开发体系建设日记 上周写了一篇 [文章](https://github.com/fouber/blog/issues/1) 介绍前端集成解决方案的基本理论，很多同学看过之后大呼不过瘾。 > 干货 ~~fuck things~~ 在哪里！ 本打算继续完善理论链，形成前端工程的知识结构。但鉴于如今的快餐文化，po主决定还是先写一篇实战介绍，让大家看到前端工程体系能为团队带来哪些好处，调起大家的胃口再说。 > ps: 写完才发现这篇文章真的非常非常长，涵盖了前端开发中的很多方面，希望大家能有耐心看完，相信一定会有所斩获。。。 ## 2014年02月12日 - 晴 新到松鼠团队的第二天，小伙伴 [@nino](https://github.com/ninozhang) 找到我说 > nino: 视频项目打算重新梳理一下，希望能引入新的技术体系，解决现有的一些问题。 po主不禁暗喜，好机会，这是我专业啊，蓝翔技校-前端集成解决方案学院-自动化系-打包学专业的文凭不是白给的，于是自信满满的对nino说，有什么需求尽管提！ > nino: 我的需求并不多，就这么几条~~ 1. 模块化开发。最好能像写nodejs一样写js，很舒服。css最好也能来个模块化管理！...
前端工程——基础篇
> 喂喂喂，那个切图的，把页面写好就发给研发工程师套模板吧。 你好，切图仔。 不知道你的团队如何定义前端开发，据我所知，时至今日仍然有很多团队会把前端开发归类为产品或者设计岗位，虽然身份之争多少有些无谓，但我对这种偏见还是心存芥蒂，酝酿了许久，决定写一个系列的文章，试着从工程的角度系统的介绍一下我对前端，尤其是Web前端的理解。 只要我们还把自己的工作看作为一项软件开发活动，那么我相信读过下面的内容你也一定会有所共鸣。 ## 前端，是一种GUI软件 现如今前端可谓包罗万象，产品形态五花八门，涉猎极广，什么高大上的基础库/框架，拽炫酷的宣传页面，还有屌炸天的小游戏……不过这些一两个文件的小项目并非是前端技术的主要应用场景，更具商业价值的则是复杂的Web应用，它们功能完善，界面繁多，为用户提供了完整的产品体验，可能是新闻聚合网站，可能是在线购物平台，可能是社交网络，可能是金融信贷应用，可能是音乐互动社区，也可能是视频上传与分享平台…… > 从本质上讲，所有Web应用都是一种运行在网页浏览器中的软件，这些软件的图形用户界面（Graphical User Interface，简称GUI）即为前端。 如此复杂的Web应用，动辄几十上百人共同开发维护，其前端界面通常也颇具规模，工程量不亚于一般的传统GUI软件：  尽管Web应用的复杂程度与日俱增，用户对其前端界面也提出了更高的要求，但时至今日仍然没有多少前端开发者会从软件工程的角度去思考前端开发，来助力团队的开发效率，更有甚者还对前端保留着”如玩具般简单“的刻板印象，日复一日，刀耕火种。 历史悠久的前端开发，始终像是放养的野孩子，原始如斯，不免让人慨叹！ ## 前端工程的三个阶段 现在的前端开发倒也并非一无所有，回顾一下曾经经历过或听闻过的项目，为了提升其前端开发效率和运行性能，前端团队的工程建设大致会经历三个阶段： ### 第一阶段：库/框架选型  前端工程建设的第一项任务就是根据项目特征进行技术选型。 基本上现在没有人完全从0开始做网站，哪怕是政府项目用个jquery都很正常吧，React/Angularjs等框架横空出世，解放了不少生产力，合理的技术选型可以为项目节省许多工程量这点毋庸置疑。 ### 第二阶段：简单构建优化  选型之后基本上就可以开始敲码了，不过光解决开发效率还不够，必须要兼顾运行性能。前端工程进行到第二阶段会选型一种构建工具，对代码进行压缩，校验，之后再以页面为单位进行简单的资源合并。 前端开发工程化程度之低，常常出乎我的意料，我之前在百度工作时是没有多少概念的，直到离开大公司的温室，去到业界与更多的团队交流才发现，能做到这个阶段在业界来说已然超出平均水平，属于“具备较高工程化程度”的团队了，查看网上形形色色的网页源代码，能做到最基本的JS/CSS压缩的Web应用都已跨入标准互联网公司行列，不难理解为什么很多前端团队对于前端工程构建的认知还仅停留在“压缩、校验、合并”这种程度。 ###...
云龙大神，您好： 目前我所在的项目遇到了一些工程化方面的问题，想向您咨询一下。 我们的项目是 native 内嵌的页面，每个页面之间并没有太强的逻辑关联，大概就是 native 从某个入口进入某个 H5页面。部分 H5页面是一些纯静态的规则展示，或者少量的使用 vue 的交互。 问题来了：我们使用的一个多页打包工具，将入口文件 global.js 以及抽离公共模块形成的 vendor.js manifest.js 都注入了每个页面（每个页面再有自己的 js 文件）。导致这些静态页面打开时很慢，因为 vendor 等 js 文件的加载和运行花费了挺长的时间。 虽然大部分页面都用到了 vendor manifest 等公共模块；但是部分静态页面(数量大约占10%) 并不需要这些模块，怎么才能对这些静态页面做特殊处理，让它们加载更快呢？ 希望您能提供一些思路，非常感谢。
浅谈前端集成解决方案
> 每个前端团队都在打造自己的前端开发体系，这通常是一个东拼西凑，逐渐磨合的过程，在技术发展日新月异的今天，这样的过程真的是不可抽象和复制的么？本文希望能够通过系统的拆解前端开发体系为大家提供体系设计思路参考。 # 什么是前端集成解决方案 > 前端集成解决方案，英文翻译为 Front-end Integrated Solution，缩写fis，发音[fɪs] 前端集成解决方案并不是一个新词汇，将这个词拆开来看，我们能得到： - 前端：指前端领域，即web研发中常用的浏览器客户端相关技术，比如html、js、css等 - 集成：将一些孤立的事物或元素通过某种方式改变原有的分散状态集中在一起，产生联系，从而构成一个有机整体的过程。[[1](http://baike.baidu.com/link?url=aGjwHq7-F5eplgGcJPKy7-q5x_5j5eJgfSwuM6WDm0NEEuJekRotYn1Au9GmwRem)] - 解决方案：针对某些已经体现出的，或者可以预期的问题，不足，缺陷，需求等等，所提出的一个解决问题的方案，同时能够确保加以有效的执行。[[2](http://baike.baidu.com/view/1038216.htm)] 总结来说，前端集成解决方案就是： > 将前端研发领域中各种分散的技术元素集中在一起，并对常见的前端开发问题、不足、缺陷和需求，所提出的一种解决问题的方案。 # 前端领域有哪些技术元素 前端行业经历了这么长时间的发展，技术元素非常丰富，这里列举出一般web团队需要用到的技术元素： 1. `开发规范`：包括开发、部署的目录规范，编码规范等。不要小瞧规范的威力，可以极大的提升开发效率，真正优秀的规范不会让使用者感到约束，而是能帮助他们快速定位问题，提升效率。 2. `模块化开发`：针对js、css，以功能或业务为单元组织代码。js方面解决独立作用域、依赖管理、api暴露、按需加载与执行、安全合并等问题，css方面解决依赖管理、组件内部样式管理等问题。是提升前端开发效率的重要基础。现在流行的模块化框架有requirejs、seajs等。 3. `组件化开发`：在模块化基础上，以页面小部件(component)为单位将页面小部件的js、css、html代码片段放在一起进行开发、维护，组件单元是资源独立的，组件在系统内可复用。比如头部(header)、尾部(footer)、搜索框(searchbar)、导航(menu)、对话框(dialog)等，甚至一些复杂的组件比如编辑器(editor)等。通常业务会针对组件化的js部分进行必要的封装，解决一些常见的组件渲染、交互问题。 4. `组件仓库`：有了组件化，我们希望将一些非常通用的组件放到一个公共的地方供团队共享，方便新项目复用，这个时候我们就需要引入一个组件仓库的东西，现在流行的组件库有bower、component等。团队发展到一定规模后，组件库的需求会变得非常强烈。...
如何进行前端自动化测试？
> 此文章转自我在 [知乎](http://www.zhihu.com/question/29922082/answer/46141819) 上的同名问答 前端测试是前端工程方面的重要分支，有过一些探索，这里简单分享一下。 首先，还是要强调一点： > 前端是一种特殊的GUI软件 看过我最近一年内做前端工程方面相关分享的人可能有印象，我总是在强调这一点。前端测试也跟这个理论基础有所关联。 在这里，我还想吐槽一下： > API测试方法论在测试GUI时并不能解决所有问题。 与很多前端工程师讨论过前端测试，大家更多的还是盯着API测试方法论。诚然，前端有那么一小部分代码是可以用API测试保证质量的，但前端项目中的绝大多数代码是GUI界面，**前端测试应该向传统GUI测试方法论需求解决方案**：[GUI软件测试_百度百科](http://baike.baidu.com/view/5131653.htm) ，这个百科词条介绍的很不错，大家可以感受一下GUI测试相关概念和方法。它的测试用例、覆盖率统计、测试方法等等都与API测试有着很大的不同。 统一了这个认知之后，我们来讨论一下前端GUI测试的特殊性。根据百科词条上的那些介绍，相信大家都能感觉到GUI测试的成本非常高，而前端这种特殊的GUI软件，具有天生的快速迭代特征，这使得case维护成本也变得非常高，经常跟不上迭代速度。 一个标准的互联网应用产品的前端部分，我粗略估计大概有20%的业务基础代码比较稳定，比如通用组件、通用算法和数据模块等，可以针对这些建立复杂一些的API和GUI测试用例来保证质量。剩下80%的部分不是很稳定，每天都在迭代，针对他们维护case的成本非常高。目前业界中号称做了自动化测试的项目，也大多是在做那稳定的20%。 关于稳定部分的单元测试方法我这里就不赘述了， [@貘吃馍香](http://zhi.hu/j9ta) 的答案给出了很多关键字，有兴趣的去搜索就好了。我想讨论的是针对剩下80%不稳定部分的工程化测试方案。据我了解，前端测试面对这些问题还是很无力的，业内大部分团队还是靠堆人解决。 面对这种现状，我其实也没想到过什么好的方法，基本原则就是： > 以最低的成本建立和维护自动化测试用例。 到目前为止，就想到过两个方案（都不是测试方案，只是回归测试辅助）： ### 1. 不太靠谱的“超级工位”大法。 这个方案可以说根本不是什么技术方案，而是一个办公设施，就是我们准备一个工位，摆上所有我们需要测试的主流设备，然后设备通过某种方式与一台电脑相连接，测试人员坐在工位上，在电脑中输入某个url，就能同步到所有设备中，然后开始逐个的人肉测试。 超级工位大法示意图（应该很多设备的，这里就是随便展示一下而已。。。） 相比现在的前端GUI测试，超级工位已经算是从0到1的飞跃了，虽然没解决什么技术问题，但为测试前的准备工作做好了铺垫。如果把前端测试比作吃屎，超级工位就是为这餐准备了一个好一点的餐桌。。。 ...
前端工程与性能优化
每个参与过开发企业级web应用的前端工程师或许都曾思考过前端性能优化方面的问题。我们有雅虎14条性能优化原则，还有两本很经典的性能优化指导书：《高性能网站建设指南》、《高性能网站建设进阶指南》。经验丰富的工程师对于前端性能优化方法耳濡目染，基本都能一一列举出来。这些性能优化原则大概是在7年前提出的，对于web性能优化至今都有非常重要的指导意义。  然而，对于构建大型web应用的团队来说，要坚持贯彻这些优化原则并不是一件十分容易的事。因为优化原则中很多要求是与工程管理相违背的，比如 `把css放在头部` 和 `把js放在尾部` 这两条原则，我们不能让团队的工程师在写样式和脚本引用的时候都去修改一个相同的页面文件。这样做会严重影响团队成员间并行开发的效率，尤其是在团队有版本管理的情况下，每天要花大量的时间进行代码修改合并，这项成本是难以接受的。因此在前端工程界，总会看到周期性的性能优化工作，辛勤的前端工程师们每到月圆之夜就会倾巢出动根据优化原则做一次性能优化。 > 性能优化是一个工程问题 本文将从一个全新的视角来思考web性能优化与前端工程之间的关系，揭示前端性能优化在前端架构及开发工具设计层面的实现思路。 ## 性能优化原则及分类 po主先假设本文的读者是有前端开发经验的工程师，并对企业级web应用开发及性能优化有一定的思考，因此我不会重复介绍雅虎14条性能优化原则。如果您没有这些前续知识，请移步 [这里](http://developer.yahoo.com/performance/rules.html) 来学习。 首先，我们把雅虎14条优化原则，《高性能网站建设指南》以及《高性能网站建设进阶指南》中提到的优化点做一次梳理，按照优化方向分类，可以得到这样一张表格： | 优化方向 | 优化手段 | | --- | --- | | 请求数量 | 合并脚本和样式表，CSS...
前端工程与模块化框架
本文最先发表在 [DIV.IO](http://div.io) - 高质量前端社区，欢迎大家围观 > 不要再求验证码了，这个blog目前有800+人订阅，求验证没什么的很影响其他订阅者，可以在div.io上申请，定期会有同学发放的。。。 --- 一直酝酿着写一篇关于模块化框架的文章，因为模块化框架是前端工程中的 `最为核心的部分` 。本来又想长篇大论的写一篇完整且严肃的paper，但看了 [@糖饼](https://github.com/aui) 在 [DIV.IO](http://div.io/) 的一篇文章 《[再谈 SeaJS 与 RequireJS 的差异](http://div.io/topic/430)》觉得可以借着这篇继续谈一下，加上最近spm3发布，在seajs的官网上又引来了一场 [口水战](https://github.com/seajs/seajs/issues/454) ，我并不想参与到这场论战中，各有所爱的事情不好评论什么，但我想从工程的角度来阐述一下已知的模块化框架相关的问题，并给出一些新的思路，~~其实也不新啦，都实践了2多年了~~。 > 前端模块化框架肩负着 `模块管理`、`资源加载` 两项重要的功能，这两项功能与工具、性能、业务、部署等工程环节都有着非常紧密的联系。因此，模块化框架的设计应该最高优先级考虑工程需要。 基于 [@糖饼](https://github.com/aui) 的文章 《[再谈 SeaJS...
要实现完整的md5计算，最终必须将task-based的流程转变成one-task形式。此处给出相关说明： 假设我们有三个文件，比如 `foo.coffee`, `foo.scss` 和 `foo.png`，文本文件的内容为： - foo.coffee ``` coffee link = document.createElement 'link' link.src = 'foo.scss' # 此处要引用scss文件 link.rel = 'stylesheet' document.head.appendChild link ``` - foo.scss ``` scss .foo...