├── LICENSE ├── Makefile ├── README.md ├── arts ├── basic-workflow.sketch ├── build-workflow.sketch ├── future-stacks.sketch └── primard.sketch ├── build ├── author.html ├── head.html ├── metadata.xml ├── share.html ├── stats.html └── title.txt ├── chapters ├── 00-prelude.md ├── p1-0.md ├── p1-1-keys.md ├── p1-2-new-framework.md ├── p1-3-builder.md ├── p1-4-architecture.md ├── p1-5-automation.md ├── p1-6-pattern.md ├── p2-0.md ├── p2-1-growth.md ├── p2-3-next-jquery.md ├── p2-3-soft-skill.md ├── p3-0.md ├── p3-1-depth.md ├── p3-2-future.md ├── p3-3-turn-in.md └── p3-4-turn-out.md ├── css └── vendor.css ├── ebook.md ├── epub.css ├── images ├── PhantomCSS.png ├── basic-workflow.png ├── build-workflow.png ├── eks-example.jpg ├── front-end-workflow-presentation.jpg ├── future-stacks.png ├── gartner-hype-cycle.png ├── refe.png ├── tech-decide.png └── webpack-react-process.png ├── img ├── cover.jpg └── favicon.ico ├── index.html ├── listings-setup.tex ├── log └── coral.log ├── material ├── Hybrid-Automation-Testing-Scenario.jpg ├── agile_pyramid2.jpg ├── chaplin-lifecycle.png ├── crossbrowser.png └── test-serv-copy.png ├── style.css └── template └── template.tex /LICENSE: -------------------------------------------------------------------------------- 1 | The MIT License (MIT) 2 | 3 | Copyright (c) 2015 Fengda Huang 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | 23 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | include_dir=build 2 | source=chapters/*.md 3 | title='前端进阶指南' 4 | filename='ebook' 5 | 6 | 7 | all: html epub rtf pdf mobi 8 | 9 | markdown: 10 | awk 'FNR==1{print ""}{print}' $(source) > $(filename).md 11 | sed -i 's@](../images@](images@g' $(filename).md 12 | 13 | html: markdown 14 | pandoc -s $(filename).md -t html5 -o index.html -c style.css \ 15 | --include-in-header $(include_dir)/head.html \ 16 | --include-before-body $(include_dir)/author.html \ 17 | --include-before-body $(include_dir)/share.html \ 18 | --include-after-body $(include_dir)/stats.html \ 19 | --title-prefix $(title) \ 20 | --normalize \ 21 | --smart \ 22 | --toc 23 | 24 | epub: markdown 25 | pandoc -s $(filename).md --normalize --smart -t epub -o $(filename).epub \ 26 | --epub-metadata $(include_dir)/metadata.xml \ 27 | --epub-stylesheet epub.css \ 28 | --epub-cover-image img/cover.jpg \ 29 | --title-prefix $(title) \ 30 | --normalize \ 31 | --smart \ 32 | --toc 33 | 34 | rtf: markdown 35 | pandoc -s $(filename).md -o $(filename).rtf \ 36 | --title-prefix $(title) \ 37 | --normalize \ 38 | --smart 39 | 40 | pdf: markdown 41 | # OS X: http://www.tug.org/mactex/ 42 | # Then find its path: find /usr/ -name "pdflatex" 43 | # Then symlink it: ln -s /path/to/pdflatex /usr/local/bin 44 | pandoc -s $(filename).md -o $(filename).pdf \ 45 | --title-prefix $(title) \ 46 | --listings -H listings-setup.tex \ 47 | --template=template/template.tex \ 48 | --normalize \ 49 | --smart \ 50 | --toc \ 51 | --latex-engine=`which xelatex` 52 | 53 | mobi: epub 54 | # Symlink bin: ln -s /path/to/kindlegen /usr/local/bin 55 | kindlegen $(filename).epub -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 前端进阶指南 2 | === 3 | 4 | > 《[我的职业是前端工程师](https://github.com/phodal/fe)》姐妹篇《前端进阶指南》 5 | 6 | 2017 年 1 月份,看完村上春树的新书《我的职业是一个小说家》,我便萌发了写一个《[我的职业是前端工程师](https://github.com/phodal/fe)》系列文章的想法——以个人视角来看前端领域的各种技术。整个系列的文章大概有 15 篇左右,从我是如何成为一个前端工程师,到各种前端框架的知识。 7 | 8 | **在完成《[我的职业是前端工程师](https://github.com/phodal/fe)》后,我便想写一个前端进阶指南,可是期间发生了一些事情,便放弃了这个想法~。现在,这本电子书就这么未完待续** 9 | 10 | 关注我的微信公众号(扫描下面的二维码或搜索 Phodal). 11 | 12 |  13 | 14 | 目录 15 | --- 16 | * [前端进阶指南](#前端进阶指南) 17 | * [什么是前端](#什么是前端) 18 | * [本书内容](#本书内容) 19 | * [硬技能篇](#硬技能篇) 20 | * [前端知识要点](#前端知识要点) 21 | * [前端应用的生命周期](#前端应用的生命周期) 22 | * [入门](#入门) 23 | * [中级篇](#中级篇) 24 | * [高级篇](#高级篇) 25 | * [工程化](#工程化) 26 | * [兼容性](#兼容性) 27 | * [前端特定](#前端特定) 28 | * [软件工程](#软件工程) 29 | * [调试](#调试) 30 | * [测试](#测试) 31 | * [性能与优化](#性能与优化) 32 | * [设计](#设计) 33 | * [SEO](#seo) 34 | * [快速学习新的框架](#快速学习新的框架) 35 | * [快速学习是基本能力](#快速学习是基本能力) 36 | * [如何学习新框架:守-破-离](#如何学习新框架守-破-离) 37 | * [守:应用业务知识](#守应用业务知识) 38 | * [破:学习框架核心](#破学习框架核心) 39 | * [离:探索更多可能性](#离探索更多可能性) 40 | * [小结](#小结) 41 | * [选择合适的前端框架](#选择合适的前端框架) 42 | * [Angular,一站式提高生产力](#angular一站式提高生产力) 43 | * [React,组件化提高复用](#react组件化提高复用) 44 | * [Vue.js,简单也是提高效率](#vue.js简单也是提高效率) 45 | * [构建系统:资深分界线](#构建系统资深分界线) 46 | * [为什么构建很重要](#为什么构建很重要) 47 | * [构建工具](#构建工具) 48 | * [构建流程](#构建流程) 49 | * [构建示例](#构建示例) 50 | * [自动刷新](#自动刷新) 51 | * [转译](#转译) 52 | * [预处理](#预处理) 53 | * [什么是前端的架构能力](#什么是前端的架构能力) 54 | * [“标准”的 SPA 构架实践](#标准的-spa-构架实践) 55 | * [前后端分离](#前后端分离) 56 | * [无状态 API](#无状态-api) 57 | * [workflow](#workflow) 58 | * [前后端分离的工作方式](#前后端分离的工作方式) 59 | * [风格指南:StyleGuide](#风格指南styleguide) 60 | * [演进](#演进) 61 | * [最佳实践:框架](#最佳实践框架) 62 | * [jQuery + TinyMCE](#jquery-tinymce) 63 | * [jQuery + Vue](#jquery-vue) 64 | * [自动化提高效率](#自动化提高效率) 65 | * [自动化测试加快上线流程](#自动化测试加快上线流程) 66 | * [测试](#测试-1) 67 | * [ui 测试](#ui-测试) 68 | * [截屏测试,](#截屏测试) 69 | * [自动构建](#自动构建) 70 | * [自动化部署](#自动化部署) 71 | * [持续集成](#持续集成) 72 | * [前端应用的架构与设计模式](#前端应用的架构与设计模式) 73 | * [散弹式架构 -> jQuery](#散弹式架构---jquery) 74 | * [分层结构 MV*](#分层结构-mv) 75 | * [处理数据 pipe and filter](#处理数据-pipe-and-filter) 76 | * [数据显示 观察者模式](#数据显示-观察者模式) 77 | * [数据通讯](#数据通讯) 78 | * [消息通讯](#消息通讯) 79 | * [数据通讯:shared repository](#数据通讯shared-repository) 80 | * [数据通讯:local storage](#数据通讯local-storage) 81 | * [软技能篇](#软技能篇) 82 | * [在做业务的过程中提升技术](#在做业务的过程中提升技术) 83 | * [测试](#测试-2) 84 | * [代码可读性](#代码可读性) 85 | * [有意图的提升](#有意图的提升) 86 | * [持续学习:走出下一个『jQuery』](#持续学习走出下一个jquery) 87 | * [jQuery 已经落后了?下一个 jQuery 已经出现了](#jquery-已经落后了下一个-jquery-已经出现了) 88 | * [持续学习](#持续学习) 89 | * [掌握思想](#掌握思想) 90 | * [后端技能](#后端技能) 91 | * [软技能](#软技能) 92 | * [知识管理](#知识管理) 93 | * [Debug: 发现问题](#debug-发现问题) 94 | * [扩展篇](#扩展篇) 95 | * [前端知识体系的广度与深度](#前端知识体系的广度与深度) 96 | * [前端与后台的对比](#前端与后台的对比) 97 | * [用户体验设计](#用户体验设计) 98 | * [前端的广度](#前端的广度) 99 | * [前端的趋势](#前端的趋势) 100 | * [微服务与微前端](#微服务与微前端) 101 | * [BFF](#bff) 102 | * [状态管理](#状态管理) 103 | * [跨平台](#跨平台) 104 | * [UI 生成](#ui-生成) 105 | * [转型前端指南](#转型前端指南) 106 | * [改变](#改变) 107 | * [后台转前端的挑战](#后台转前端的挑战) 108 | * [其他编程领域转前端](#其他编程领域转前端) 109 | * [其他行业转前端](#其他行业转前端) 110 | * [劝退](#劝退) 111 | * [立意已决](#立意已决) 112 | * [前端跨行指南](#前端跨行指南) 113 | * [移动开发:混合开发](#移动开发混合开发) 114 | * [桌面应用](#桌面应用) 115 | * [VR](#vr) 116 | * [硬件](#硬件) 117 | * [其它?](#其它) 118 | 119 | LICENSE 120 | --- 121 | 122 | [](https://www.phodal.com/) [](https://www.phodal.com/) 123 | 124 | 125 | © 2017 [Phodal Huang](https://www.phodal.com). This code is distributed under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License. See `LICENSE` in this directory. 126 | 127 | [待我代码编成,娶你为妻可好](http://www.xuntayizhan.com/blog/ji-ke-ai-qing-zhi-er-shi-dai-wo-dai-ma-bian-cheng-qu-ni-wei-qi-ke-hao-wan/) 128 | -------------------------------------------------------------------------------- /arts/basic-workflow.sketch: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/fed/2ef56a5a9431c5144b1017e9fd962e3b8ba3ac32/arts/basic-workflow.sketch -------------------------------------------------------------------------------- /arts/build-workflow.sketch: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/fed/2ef56a5a9431c5144b1017e9fd962e3b8ba3ac32/arts/build-workflow.sketch -------------------------------------------------------------------------------- /arts/future-stacks.sketch: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/fed/2ef56a5a9431c5144b1017e9fd962e3b8ba3ac32/arts/future-stacks.sketch -------------------------------------------------------------------------------- /arts/primard.sketch: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/phodal/fed/2ef56a5a9431c5144b1017e9fd962e3b8ba3ac32/arts/primard.sketch -------------------------------------------------------------------------------- /build/author.html: -------------------------------------------------------------------------------- 1 |
2 |
Phodal
4 | -------------------------------------------------------------------------------- /build/head.html: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /build/metadata.xml: -------------------------------------------------------------------------------- 1 |17 |
Phodal
19 | 20 |作为一本前端进阶的书,没有理由去强调一下什么是前端?可是,当你说前端的时候,我也说前端的时候,我们说的是同一个前端吗?
155 |我理解下的前端,指广泛意义上的前端。又可以称为『客户端』,泛指:与用户做交互的应用。如桌面浏览器上的浏览器、图形用户界面,移动设备上的应用程序、浏览器,又或者是各种智能、联网设备的交互都可以归属于前端。
156 |因而,在这种意义上来说,前端要做的不仅仅是 Web,还可以是混合应用,原生应用等等。
157 |这就意味着:
158 |这种时候,前端指的是,我们使用 样式(类CSS) + 类JavaScript + 模板(HTML、XML等 编写的应用。
165 |如果那些用 JavaScript 编写的应用,也划分到前端的范畴,那么:
166 |在这里,我们将前端定义为 类CSS + 类 JavaScript + 模板。因为没有图形应用的应用,难以直观的与用户进行交互,做不了『客户端』应用。在这一定义下,这一类型的应用有,桌面应用、桌面网页、移动网页、移动应用等等,现在发展的有 VR 技术等等。
171 |罗列一下,一些必要的知识点
175 |希望读者都是知道的,以便于
176 |作为一个领域,它拥有相当多的知识点。
177 |如果读者已经知道了这些,那么可以跳过这一章的内容。
178 |
在我理解下的基础知识,就是我们可以写一些基本的样式,并能对页面的元素进行操作。举例来说,就是我们用Spring和JSP写了一个博客,然后我们可以用jQuery来对页面进行一些简单的操作,并可以调用一些API。因此,我们需要基本的HTML / CSS知识。只是要写好CSS并不是一件简单的事,这需要很多实战经验。随后,我们还需要有JavaScript的经验,要不怎么做前端呢?
184 |同时,我们还需要对DOM有一些基础的了解,才能做一些基本的操作,如修改颜色等等。在这种情况下,最简单的方案就是使用jQuery这样的工具。不过,如果可以自己操作DOM是再好不过的了。
185 |中级篇就更有意思了,现在我们就需要对页面进行更复杂的操作。Ajax和JSON这两个技能是必须的,当我们要动态的改变页面的元素时,我们就需要从远程获取最新的数据结果。并且我们也需要提交表单到服务器,RESTful就是必须要学会的技能。未来我们还需要Fetch API,ReactiveX这些技能。
187 |除此我们还需要掌握好HTML的语义化,像DIV / CSS这也会必须会的技能,我们应该还会使用模板引擎和SCSS / SASS。而这个层面来说,我们开始使用Node.js来完成前端的构建等等的一系列动作,这时候必须学会使用命令行这类工具。并且,在这时候我们已经开始构建单页面应用了。
188 |JavaScript是一门易上手的语言,也充满了相当多的糟粕的用法。几年前人们使用CoffeeScript编成成JavaScript来编写更好的前端代码,现在人们有了ES6、TypeScript和WebPack来做这些事。尽管现在浏览器支持不完善,但是他们是未来。同样的还有某些CSS3的特性,其对于某些浏览器来说也是不支持的。而这些都是基于语言本来说的,要写好代码,我们还需要掌握面向对象编程、函数式编程、MVC / MVVM / MV*这些概念。作为一合格的工程师,我们还需要把握好安全性(如跨域),做好 授权(如HTTP Basic、JWT等等)。
190 |这个标题好像是放错了,这部分的内容主要都是自动构建的内容。首先,我们需要有基本的构建工具,无论你是使用gulp、grunt,还是只使用npm,这都不重要。重要的是,你可以自动化的完成构建的工具,编译、静态代码分析(JSLint、CSS Lint、TSLint)、对代码质量进行分析(如Code Climate,可以帮你检测出代码中的Bad Smell)、运行代码中的测试,并生成测试覆盖率的报告等等。这一切都需要你有一个自动构建的工作流。
192 |虽然我们离兼容IE6的时代已越来越远了,但是我们仍然有相当多的兼容性工作要做。基本的兼容性测试就是跨浏览器的测试,即Chrome,IE,Firefox,Safari等等。除此还有在不同的操作系统上对同一浏览器的测试,某些情况下可能表现不一致。如不同操作系统的字体大小,可能会导致一些细微的问题。而随着移动设备的流行,我们还需要考虑下不同Android版本下的浏览器内核的表现不致,有时候还要一下不成器的Windows Phone。除此,还有同一个浏览器的不同版本问题,常见于IE。。
194 |除了正常的编码之外,前端还有一些比较有意思的东西,如CSS3和JavaScript动画。使用Web字体,可惜这个不太适合汉字使用。还有Icon字体,毕竟这种字体是矢量的。不过Icon字体还有一些问题,如浏览器对其的抗锯齿优化,还有一个痛是你得准备四种不同类型的字体文件。因此,产生了一种东西SVG Sprite,在以前这就是CSS Sprite,只是CSS Sprite不能缩放。最后,我们还需要掌握一些基本的图形和图表框架的使用。
196 |这一点上和大部分语言的项目一样,我们需要使用版本管理软件,如git、svn,又或者是一些内部的工具。总之你肯定要有一个,而不是 2016.07.31.zip这种文件。然后,你还需要一些依赖管理工具,对于那些使用Webpack、Browserify来将代码编写成前端代码的项目来说,npm还是挺好用的。不过就个人来说,对于传统的项目来说我总觉得bower有些难用。我们还需要模块化我们的源码文件,才能使其他人更容易开始项目。
198 |作为一个工程师来说,调试是必备的技能。大部分浏览器都自带有调试工具,他们都不错——如果你使用过的话。在调试的过程中,直接用Console就可以输出值、计算值等等。如果你的项目在构建的过程中有一些问题,你就需要debugger这一行代码了。在一些调用远程API的项目里,我们还需要一些更复杂的工具,即抓包工具。在调试移动设备时,像Wireshark、Charles这一类的工具,就可以让我们看到是否有一些异常的请求。当然在这个时候,还有一个不错的工具就是像Chrome自带的远程设备调试。对于移动网站来说,还要有Responsive视图。
200 |我遇到的很多前端工程师都是不写测试的,于是我便把它单独地抽了出现。对于一个前端项目来说,正常情况下,我们要有单元测试、功能测试,还有要一些UI测试来验证页面间是否可以跳转。对于依赖于第三方服务的应用来说,还要有一个Mock的服务来方便我们测试。如果是前后端分离的项目,我们还需要有集成测试。
202 |要对Web应用进行性能优化,可能不是一件容易的事,有时候我们还知道哪些地方可以优化。这时候人们就可以使用Yahoo的YSlow,或者我最喜欢的Google PageSpeed来检测页面的一些问题,如有没有开启GZip、有没有压缩、合并、Minify JS代码等等。我们还应该借助于NetWork这一类的工具,查看页面加载时,一些比较漫的资源文件,并对其进行优化。在一些情况下,我们还需要借助如Chrome的Timline、Profiel等工具来查看可以优化的地方。
204 |前端工程师还需要具备基本的UI技能。多数情况下拿到的只是一张图,如果是一个完整的页面,我们就需要快速分割页面布局。而依赖于不同的页面布局,如响应式、网格、FlexBox布局也会有不同的设计。而有些时候,我们就需要自己规划,制作一个基本的线框图(Wireframe)等等。
206 |如果以搜索引擎作为流量来源,我们还需要考虑页面的内容,除非你用的是竞争排名。像Sitemap可能就不是我们考虑的内容,而我们还要考虑很多点。首先,我们需要保证页面的内容是对于搜索引擎是可见的,并且对应的页面还要有基本的Title、Description和Keyword。然后在一些关键的字体,如栏目标题等等可以用H2之类的大字的地方就不要放过。同时在页面设计的过程中,我们还需要考虑一些内部链接的建设。它即可以提供页面的可见度,又可以提高排名。最后,如果你是面向的是Google等支持结构化数据的搜索引擎,你还需要考虑一下MicroData / MicroFormat这一类东西。
208 |今天很流行的 Web 框架,半年以后,可能就会在市场上被『淘汰』——技术选型的时候,不被开发人员推荐;又或者它已经推出了全新的版本,使用了全新的 API,我们便需要更新现有应用。
210 |前端框架丰富多彩的今天,快速学习新的框架是每个前端程序员的必备技能。
211 |后端程序员,开始一个新的 Web 项目时:
213 |而只使用 JavaScript 的前端程序员,开始一个前端项目时。你有几成的把握,能判断他/她出会使用哪个框架?
219 |后端程序员在有限的时间内,只会使用固定的技术栈,固定的框架。对于大部分的公司来说,使用相同的后台语言,是一个更好的选择——即可以减少带成本,又可以沉淀下技术积累。
220 |而前端则不一样,不同的项目都有各自的需求,因此采用使用不同的技术栈。简单的,可以直接使用原生的 JavaScript 完成,又或者是使用 jQuery 完成开发。稍微复杂一点的项目,采用容易上手的 Vue.js 是一个不错的选择。更复杂的项目,便可以使用 Angular,可以方便后台程序员转到前端。
221 |因此,工作一定年限的程序员,都使用过不同的框架。可是,不同的程序员上手新框架的速度,总会存在一定的差异。
222 |那么,怎样才能快速上手一个新的框架呢?
223 |学习新的前端框架,要么该框架很火——即热闹驱动开发(Hype Driven Development,HDD),要么你们将采用该框架。在采用新框架的动机里,有一种是:技术演进。使用新的技术、框架,来替换现有的框架。旧的框架在某些地方上,存在着明显的缺陷。
224 |这种情形下,业务知识本身是不变的,只是要由框架本身来应对业务的变化。因此,使用新的技术来替换旧有的框架,就相当的容易——重写,我们甚至可以直接复制、粘贴,大量原有的代码。只是,仅仅做到重写业务逻辑是不够的。我们还要掌握新的框架的核心,并探索更多的可能性。
225 |我在学校的时候,看到一个关于编程语言的学习建议:学习三种以上的编程语言,并且它们最好是三种不同类型的语言。如面向过程的编程语言 C 、脚本语言 JavaScript、Python,面向对象的编程语言 Java、再加上个近年来火热的函数式编程语言,到底也就差不多了。当我们学习了一门语言,再上手一门相似风格的语言,也是相当轻松地一件事。当我们学习了不同类型的几种语言,未来就可以轻松地绝大多数的语言。
227 |相似的,学习使用 Web 框架也是如此的。现在,对于我而来,使用一个『新框架的姿势』是:
228 |它与我在公司接受培训的时候,学习到的『守破离』观点相似。在保留原来业务的情况下,一步步向前演进。
235 |在现有的业务上,使用新的框架是一件容易的事。拿上一份框架的说明书、一份需求文档、一个搜索引擎,就可以很容易地复制出一个产品。唯一的门槛是,你需要会读懂这些内容。这有点像新的知识阶级,只是门槛不再是识字与否,而在于是否能懂编程的知识。
237 |正如维基百科上,对于『守』的介绍一样:
238 |239 |241 |最初阶段须遵从老师教诲,认真练习基础,达到熟练的境界。
240 |
新手期的我们,拿到一个新的框架,要一下子对它了运用自如,是一件很难的事。我们只能在一个又一个的练习中,尝试去掌握框架的知识。如,原先我们使用的是 Backbone + jQuery 完成的前端应用,现在要切换到 Vue.js。我们要做的便是尝试使用 Vue.js,并不断地练习一些相关的用法。而在熟练之后,我们也会练习我们的基本套路,如在上文中说到的『新框架的姿势』。
242 |而如果不考虑练习本身的时间因素,便只剩下的一个问题是:如何找到一个合适的练习项目。然而,这样的项目在 GitHub 上有很多。可是即使它能满足我们的需求,我们有时候也不知道怎么练习?
243 |我想问题的关键在于:我们手上没有一个已经成型的业务系统。因此,我建议大家可以从创建一个博客开始做起,先使用现有的技术,再使用新的技术,慢慢的一点点往上添加内容。如我的博客,最早是基于 Django + Bootstrap,慢慢的我添加了一些新的东西:
244 |尽管越来越多的功能,有一些已经不再维护、关闭了。可是,它让我有机会去练习一些新的技术,掌握一些技术背后的思想,得到一些框架相关的结论。而不是每次与别人讨论时,说:xx 说 xx 框架有这样的问题,而是我试过这个框架,它有这样的问题。
252 |254 |256 |基础熟练后,试着突破原有规范让自己得到更高层次的进化。
255 |
转换技术栈,本身没有什么技术含量,但是能帮助稳固知识。当我们已经熟悉使用这个框架完成业务时,便可以细入相关思想。
257 |了解这个框架的能力,生成一份与框架有关的索引,也可以用脑图的形势来整理这些内容。
258 |如:
259 |
举例,如 Angular + TypeScript,还有其他更多的可能性
263 |同时,我们还应该理解框架背后的原理。不一定深入,但是觉得去探究。如:
264 |这些都在我的知乎专栏上《我的职业是前端工程师》有深入的介绍,有时候的读者建议多阅读相关的内容。
269 |271 |273 |在更高层次得到新的认识并总结,自创新招数另辟出新境界。
272 |
在那之上,创造出一些新的框架。
274 |如 Redux,最早是运行的 React.js 之上。Angular 2 出来了后,有了 xx。小程序出来后,有了 xx。
275 |同理于此,当出现微信小程序的一两个星期内,我写了几篇原理相关的文章,并介绍了如何创建一个属于自己的小程序应用框架 WINV。又或者是我在对 Virtual Dom 有一定的了解后,便深入 Virtual Dom 的代码,写了一个基于 Virtual Dom 的测试辅助框架 Luffa。
276 |而这些,只有我们理解他们的原理之后,我们才可能做到这样的事。
277 |寻找心流
279 |这些方法适用于大部分的人,但是不一定适合你。你只需要寻找到适合你的路,然后学习。
280 |在《全栈应用开发:精益实践》一书中,我曾提到过影响技术选型的几个因素:
282 |
锤子定律:寻找更大视野
286 |年轻的时候,学会了 A 框架,总觉得 Z 网站用 A 框架来实现会更好,一定不会像今天这样经常崩溃、出Bug。**时间一长,有时候就会发现,Z 网站使用 A 不合适,他们的问题并不是框架的问题,而是运维的问题。
287 |在《咨询的奥秘》一书中,提到一个有意思的定律“锤子定律”(又称为工具定律)——圣诞节收到一把锤子的孩子,会发现所有东西都需要敲打。 出现这种情况的主要原因是,开发者对一个熟悉的工具过度的依赖。
288 |认真观察,就会发现这个现象随处可见。当一个新手程序员学会了某个最新的框架,通常来说这个框架有着更多的优点,这个时候最容易出现的想法是:替换现有的框架。可是,现有的框架并没有什么大的问题。并且凭估不充分时,新的框架则存在更多的风险。
289 |并且,对于某个熟悉工具的过度依赖,特别容易影响到技术决策——看不到更多的可能性。这时候,我们就需要头脑风暴。但是这种情况下,头脑风暴很难帮助解决问题。在这个时候,拥有更多项目、框架经验的人,可能会做出更好的选择。
290 |与 Backbone 同一时代诞生的 Angular 便是一个大而全的 MVC 框架。在这个框架里,它提供了我们所需要的各种功能,如模块管理、双向绑定等等。它涵盖了开发中的各个层面,并且层与层之间都经过了精心调适。
292 |我们所需要做的便是遵循其设计思想,来一步步完善我们的应用。Angular.js 的创建理念是:即声明式编程应该用于构建用户界面以及编写软件构件,而命令式编程非常适合来表示业务逻辑。
293 |我开始使用 Angular.js 的原因是,我使用 Ionic 来创建混合应用。出于对制作移动应用的好奇,我创建了一个又一个的移动应用,也在这时学会了 Angular.js。对于我而言,选择合适的技术栈,远远比选择流行的技术栈要重要得多,这也是我喜欢使用 Ionic 的原因。当我们在制作一个应用,它对性能要求不是很高的时候,那么我们应该选择开发速度更快的技术栈。
294 |对于复杂的前端应用来说,基于 Angular.js 应用的运行效率,仍然有大量地改进空间。在应用运行的过程中,需要不断地操作 DOM,会造成明显的卡顿。对于 WebView 性能较差或早期的移动设备来说,这就是一个致命伤。
295 |幸运的是在 2016 年底,Angular 团队推出了 Angular 2,它使用 Zone.js 实现变化的自动检测、
296 |而迟来的 Angular 2 则受奥斯本效应1的影响,逼得相当多的开发者们开始转向其它的框架。
297 |从 Backbone 和 Angular.js 的性能问题上来看,我们会发现 DOM 是单页面应用急需改善的问题——主要是DOM 的操作非常慢。而在单页面应用中,我们又需要处理大量的 DOM,性能就更是问题了。于是,采用 Virtual DOM 的 React 的诞生,让那些饱受性能苦恼的开发者欢迎。
299 |传统的 DOM 操作是直接在 DOM 上操作的,当需要修改一系列元素中的值时,就会直接对 DOM 进行操作。而采用 Virtual DOM 则会对需要修改的 DOM 进行比较(DIFF),从而只选择需要修改的部分。也因此对于不需要大量修改 DOM 的应用来说,采用 Virtual DOM 并不会有优势。开发者就可以创建出可交互的 UI。
300 |除了编写应用时,不需要对 DOM 进行直接操作,提高了应用的性能。React 还有一个重要思想是组件化,即 UI 中的每个组件都是独立封装的。与此同时,由于这些组件独立于 HTML,使它们不仅仅可以运行在浏览器里,还能作为原生应用的组件来运行。
301 |同时,在 React 中还引入了 JSX 模板,即在 JS 中编写模板,还需要使用 ES 6。令人遗憾的是 React 只是一个 View 层,它是为了优化 DOM 的操作而诞生的。为了完成一个完整的应用,我们还需要路由库、执行单向流库、web API 调用库、测试库、依赖管理库等等,这简直是一场噩梦。因此为了完整搭建出一个完整的 React 项目,我们还需要做大量的额外工作。
302 |大量的人选择 React 还有一个原因是:React Native、React VR 等等,可以让 React 运行在不同的平台之上。我们还能通过 React 轻松编写出原生应用,还有 VR 应用。
303 |在看到 Angular 2 升级以及 React 复杂性的时候,我相信有相当多的开发者转而选择 Vue.js。
304 |引自官网的介绍,Vue.js 是一套构建用户界面的渐进式框架,专注于MVVM 模型的 ViewModel 层。Vue.js 不仅简单、容易上手、配置设施齐全,同时拥有中文文档。
306 |对于使用 Vue.js 的开发者来说,我们仍然可以使用 熟悉的 HTML 和 CSS 来编写代码。并且,Vue.js 也使用了 Virtual DOM、Reactive 及组件化的思想,可以让我们集中精力于编写应用,而不是应用的性能。
307 |对于没有 Angular 和 React 经验的团队,并且规模不大的前端项目来说,Vue.js 是一个非常好的选择。
308 |虽然 Vue.js 的生态与 React 相比虽然差上一截,但是配套设施还是相当齐全的,如 Vuex 、 VueRouter。只是,这些组件配套都由官方来提供、维护,甚至连 awesome-vue 也都是官方项目,总觉得有些奇怪。
309 |除此,Vue.js 中定义了相当多的规矩,这种风格似乎由 jQuery 时代遗留下来的。照着这些规矩来写代码,让人觉得有些不自在。
310 |和 React 相似的是,Vue.js 也有相应的 Native 方案 Weex,仍然值得我们期待。
311 |Yeoman 生成脚手架,并且现在的主流前端框架都提供了相似的工
313 |打包 -> 压缩 -> 上传 -> 解压 -> 替换 -> 重启
314 |重点在于:提高工作效率
315 |过去我们打开编辑器、浏览器、修改代码、刷新页面,如下图所示:
317 |
这个过程仍然没有发生太大的变化,只是很多的步骤都被自动化了:
321 |我们只需要修改代码,诸如 watchman 这样的工具就检测到修改,而 Browsersync 则可以帮助我们自动刷新页面。
322 |取决于你所使用的技术栈
324 |SASS、SCSS 因不同的情况而异
325 |webpack
326 |npm
327 |grunt / gulp
328 |
LiveReload
333 |Bower
334 |concat -> init -> lint -> min -> qunit -> server -> test -> watch
335 |如下是混合应用框架 Ionic 执行 ionic serve 时的启动日志:
[11:43:58] ionic-app-scripts 1.3.4
338 | [11:43:58] watch started ...
339 | [11:43:58] build dev started ...
340 | [11:43:58] clean started ...
341 | [11:43:58] clean finished in 1 ms
342 | [11:43:58] copy started ...
343 | [11:43:58] transpile started ...
344 | [11:44:03] transpile finished in 5.17 s
345 | [11:44:03] preprocess started ...
346 | [11:44:03] deeplinks started ...
347 | [11:44:03] deeplinks finished in 132 ms
348 | [11:44:03] preprocess finished in 132 ms
349 | [11:44:03] webpack started ...
350 | [11:44:03] copy finished in 5.49 s
351 | [11:44:26] webpack finished in 22.94 s
352 | [11:44:26] sass started ...
353 | [11:44:29] sass finished in 3.21 s
354 | [11:44:29] postprocess started ...
355 | [11:44:29] postprocess finished in 85 ms
356 | [11:44:29] lint started ...
357 | [11:44:29] build dev finished in 31.57 s
358 | [11:44:29] watch ready in 31.69 s
359 | 这个过程中,它会完成如下的步骤:
360 |watch -> build dev -> clean -> copy -> transpile -> preprocess (deeplinks) -> webpack (copy) -> sass -> postprocess -> build dev
361 |366 |368 |远离最佳实践,除非你能接受其带来的成本
367 |
当我们谈及『前端的架构』时,我们讨论的是复杂前端应用的架构——如果只是一个 jQuery + Bootstrap 完成的应用,那么它的架构想必是『散弹式』的应用,没有复杂的逻辑可言。
369 |复杂的前端应用,多数是 SPA(单页面应用),这就意味着系统的架构是前后端分离的。可前后端分离并意味着,
371 |实现上,它主要关注点是:API 的设计。API 设计应该由前端开发者来驱动的。后台只提供前端想要的数据,而不是反过来的。后台提供数据,前端从中选择需要的内容。
376 |与之前的构建系统相比,StyleGuide 便是一种无法用工具强制执行的规范。尽管可以采用工具来做类似的事情,但是并非应该强制去做。
383 |当前技术栈,未来技术栈,切换。
389 |使用了 Backbone,性能上出现一些瓶颈。
390 |是不是要重写服务。
391 |后台不能满足一些需求,考虑使用 BFF 吗
392 |选用合适的策略,并保证没有问题。
393 |在这个领域,并不存在最佳的实践。首先的问题是,要找出我们真正想实现的功能,在这之后再去完成下一个步骤。而不是先找行业中最好的实践,再将这些实践应用
395 |jQuery 在简单的前端页面里,仍然是最好的选择。
396 |不久前,我需要一个 UI 框架及前端框架来实现简单的逻辑功能,并且它还应该相当的小。因此,我首先排队了 jQuery + Bootstrap,它们在体积上不太符合我的要求。
399 |提炼出核心技术,
404 |对于大的公司来讲,都会要求拥有自己的核心技术。
405 |在网上,各式各样的前端开发最佳实践层出不穷,
406 |最意味着,在某些方面已经是到了极致。
407 |测试页面的输出结果,保证元素的准确性~
411 |stub: 结果,返回预期的结果。
412 |mock: 行为,预期方法被调用。
413 |React Test Renderer
415 |<Modal
416 | animationType="fade"
417 | hardwareAccelerated={false}
418 | onRequestClose={[Function]}
419 | transparent={true}
420 | visible={false}
421 | >
422 | <View>
423 | <View
424 | style={
425 | Object {
426 | "alignItems": "center",
427 | "backgroundColor": "rgba(0,0,0,.1)",
428 | "height": 1334,
429 | "justifyContent": "center",
430 | }
431 | }
432 | >
433 | ...
434 | 对于那些 UI 改动较小的系统来说,这
436 |而我们知道页面截图尽管可以作为版本管理的一部分,但是一个不可比对的结果
437 |而诸如,react-test-render, Virtual Dom 测试
438 |那么,对于普通的 HTML 结构的
439 |
在之前的构建系统一节里,我们讲了 xx。剩下要做的就是生成打包好的源码
444 |Gulp、Grunt
445 |只需要一些 持续集成 的基础,如 Jenkins
447 |项目达到一定的程度,jQuery 便有些难以管理,我们不知道哪个地方还操作了 DOM。修改了 A 处的 selector,可能会影响 B 处的 selector。
451 |这样的修改方式称为『散弹式架构』,它来自于 散弹式修改(shotgun surgery,出处《重构:改善既有代码的设计》),
452 |在使用 Backbone 的过程中,如果你采用了继承 View 的方式,你也会遇到这种遇到问题。
453 |典型的 SPA 应该会具有的模式,如 Angular,Vue.js
455 |fetch、ajax、RxJS 从 API 处获取到数据
457 |这个时候的数据首先会被转换为 JSON,再过滤到需要的字段,再对字段进行特殊的处理,如 HtmlEncoded,最后再 Render 到元素上。
458 |当我们从服务器
459 |双向绑定,即观察者模式,又可以称为发布订阅模式(Publish/Subscribe)
461 |除了常规的数据获取,还有在不同的框架间传输数据,如 React Native 和 WebView 的 postMessage,Cordova 的 WebView 与原生插件间
463 |其他消息通讯
466 |??? black board
468 |471 |473 |“三个月经验,重复了五年”
472 |
476 |478 |与性能相比,可读性更加重要——绝大多数的软件,并不是写完就结束周期了。当然,倒掉的创业公司的软件除外。
477 |
在一家大的公司里,不同的人总会有不同的运气:
480 |运气好的人遇上一个好的项目,升职加薪,从此就走上了人生的巅峰。 运气差的人摊上一个差的项目,升不了职,少加了薪,并且还获得不了技术成长。 我刚毕业那会儿,所在团队的主要工作是,维护一个『又老又旧』的系统。比起写业务代码更不幸的是,我们的主要工作是修 Bug,bug,buG, bUg。
481 |那一年多里,尽管都是维护旧系统和少量的新需求,我们还是在飞速的成长~~。而来源主要是:
482 |当你在有限的条件下,还能做出一定的成绩,到底还是相当有成就感的。
488 |如果你觉得你的项目技术栈老旧,那么你一定在脑子里使用了 N 种技术栈,对他们进行重构了。并且当你有一些时间可以分配到上面,如下班前的一个小时时间,又或者黑客马拉松等等。那么,你一定会开始去做这样的事。
489 |与上面的技术活动相比,这是一个对于业务(我的意思是,对于公司来说)更有价值,并且更容易说服别人的方式。
490 |不,仍然没有,
496 |jQuery 的最大问题在于,简单如果上手,如 Vue 有可能便会流行,然后成为下一个 jQuery
497 |预测未来,不,我不可能。
499 |对于,大公司或者内部系统的开发者来说,由于框架能满足应用的开发,因此很容易长期采用一个框架。当然,这本身并不是问题,你有了一份的工作,一个稳定的。可是,你可能会失去学习的勇气与能力。
500 |阅读后端代码的能力
510 |原本打算写一些时间管理,及
512 |篇幅所限
513 |将输入的知识变为输出
515 |以输出的方式来输入。
516 |编程时,我们大部分时候都是在解决问题,即求解已知的问题。
518 |除此,我们还需要花费很多的时间在 Debug 上,即如何去发现问题所在。
519 |最后,如果仍然不能解决问题,那么就找个人、地方提问吧。
520 |后台对于深度要求高,而前端对于广度要求高。
524 |前端:用户喜爱的产品
528 |基础 HTML + JS + CSS
529 |广度 -> 用户体验、浏览器差异 -> 知识碎片
530 |jQuery + Backbone + xxx
531 |后台:高并发高可用
532 |纠结于 事务一致 锁
533 |Spring + Mybatis + Flyway
534 |数据库 + ORM + MVC
535 |论技术上的深度,自然是后台更深
536 |论用户体验上,自然是前端更深 两种很难衡量
537 |常见问题:Ops 运维 -> 环境问题
538 |对于前端来说,广度 First -> 深度。熟悉框架的相似之处,并且完成任务。
539 |对于后端来说,选定语言,基本上就已经选好一切了,Java -> Spring,Scala -> Play,Ruby -> Rails
540 |在中大型规模的公司里,会有建议使用的后台语言,他们也主要使用一个后台语言。因为它已经可以很稳定地运行
543 |除非,旧的语言在应用上存在一些缺陷。或者,正在尝试使用新的技术。
544 |而对于前端来说,如果不能选择使用自己的轮子,那么就会是一片混乱。他们会使用不同的框架,不同的团队都有不同的业务场景。
545 |
551 |553 |对于后台采用微服务架构来说,在一个不同的组成部分中,使用不同的技术栈是一种不错的体验;而对于一个前端团队来说,在同一个系统的使用不同的技术栈就不是一种不错的体验。
552 |
可以使用 Web 存储技术,如 LocalStorage 来转移状态。又或者是诸如 Redux 的方式
554 |Redux
557 |Angular 可以移动应用和桌面Web应用,可是它并没有像 React 有那么广泛的用途。
559 |React、React VR、React Native
560 |过去有 DreamWeaver 这样的软件,现在也有一些强大的 UI 工具,可以直接将设计转化为代码。
562 |职业转型,放弃你现在的工作、相关行业经验,进入一个“新的环境”。这就意味着,当你想转到前端时,你需要面临一系列的挑战。你的老板并不会关心你的过程是怎样的,只要你能达到当前的能力要求,并有能力适应未来的变化即可。
564 |565 |567 |跳槽穷半年,转行穷三年。
566 |
在过去的两三年里,随着前端领域的火热,市场上有越来越多的、不同行业的人加入了前端大军。人们出于不同的目的,选择上了前端开发。
568 |有的是,大学里喜欢上前端这个行业,在找工作的时候,便选择了相应的岗位;有的是,不喜欢传统的编译型语言,如电子信息工程;有的是,大学上的专业找不到合适的工作,诸如数学等,并且有些专业与编程相比,拥有同等的逻辑能力要求;有的是,看前端行业很赚钱,便报了个培训班,来到了这个行业。
569 |前端这个职业吧,入门快,上手也简单。简单的网页吧,拉上几个初学者便也能完成。可一旦遇上复杂的前端应用,就会暴露出各种各样的问题。于是,那些原先由非编程领域转行过来的人,便容易招至不满。
570 |究其原因吧,是因为能力上达不到要求。我们到是可以看看,有多少人会转向人工智能,下一个行业热点。
571 |一点点慢慢改变,时间长,成本高,但是痛苦小
573 |主要问题:
574 |change -> 改变 -> 痛苦
579 |编程世界,比现实世界简单,有严格的对错。
586 |如果你是一个没有编程经验的新手,那么你应该去报一个培训班。他可以在短期内帮你提高技术,但是与之相对应的,会带来一些问题。培训机构出来的学员,都存在一定的简历造假。由于数量众多,质量上参差不齐,导致人们普遍对培训机构出来的学员,存在一定的能力怀疑。说到底,你只能把培训机构当成一个入门,它距离你找到一份工作,还有相当大差距。
587 |但是,你是真心的喜欢编程这个职业吗?
588 |我见过一些后来者,他们在开始的时候问一些愚蠢的问题,慢慢的他们意识到这些问题,都是自己搜索就能解决的。他们会加入一些小组,来提高自己。建立一些信心,并去回答一些别人的问题。
589 |Angular 2 -> 是一个不错的选择
591 |唯一遗憾的是,它不使用 XML 来配置
596 |Node.js 应用也是一个不错的选择
597 |移动端到 React Native,再到 React
599 |编程并不是一件容易的事,如果你有业余兴趣便还好,如果没有的话,就算了。
602 |主要原因:它并不是一个赚钱的行业,你是在时间换金钱。。
603 |不妨考虑,投资,或者产生一个千万级的 idea,再找个风投
604 |万一,你又一次选错行了呢?
605 |首先,打开浏览器、下载 IDE、然后写一行 HTML 试一试
607 |简单的入门书,如 Head First HTML
608 |找一个小的项目
609 |外包公司 -> 门槛低 -> 相对比较多的成功案例
617 |寻找合适的工作 -> 起步类型
618 |查看相应类型的工作,看看工作介绍
619 |事实上,按照『技术成熟曲线』理论,前端正在进入低谷期。而人工智能才是,现在,乃至未来一段时间的 IT 高薪领域。
620 |
如果你真的喜欢前端,那么:Just do it!
624 |如果你爱请深爱~。
625 |JavaScript 应用领域
627 |挑战:要学会新的领域的知识,以及其对应的语言知识。如开发混合应用时,在 iOS 方面,你需要有些许 Objective-C 或者 Swift 的开发能力,在 Android 方面,你还需要些许的 Java 经验。
628 |颇受欢迎的个人电脑厂商奥斯本,其公司的创新式便携电脑还没有上市,就宣布他们要推出的更高档的机器,而又迟迟无法交货,消费者闻风纷纷停止下单订购现有机种,最后导致奥斯本因收入枯竭而宣布破产。↩