前端工程师和 UI 设计师该如何选择？
我的图书馆
前端工程师和 UI 设计师该如何选择？
首先得恭喜你，你对2门有密切关系的技能有了初步的了解。无论是懂前端的设计还是懂设计的前端在任何公司都是很受欢迎的.因为你的本职工作的完成度和速度都讲比一般人好。现在放在你面前的有3条路。1.成为前端工程师。2.ui设计师。3.全栈设计师。成为前端设计师需要掌握的技能：1.1精通html+css+css3，深刻的理解结构与css的配合，并不是会了一点padding，margin，canvan就代表会了。静态界面的能力表现在你代码的复用性，可修改性。例：整站中设计师给出的相同设计手法的模块，你只需要用一个div就搞定。这里需要前端对设计有一定的了解。移动web项目居多。1.2精通js，jq。很多经常使用的判断，逻辑手写就行，速度快而且垃圾代码少。1.3建立自己的js代码库，轮播，滚动，刷新，滑进滑出，弹出窗，摇一摇，动画，摄像头等都是会经常用到的找点轻便的代码自己拔下来，然后做成demo存在自己的电脑里面。1.4深刻理解前台，专题，用户中心，管理系统，移动对c界面，移动专题等不同类型的界面可能你的写法会不一样。有的求快，有的要求复用，有的要求兼容，哪怕是快的写法和兼容的写法也会因为应用环境的关系改变。1.5 懂一点设计，最高程度的去还原设计师的界面，理解为什么他需要移动1px的位置，理解为什么每个行距间距可能都是10px，这样你们会成为知己好友。1.6了解一点后端的基础知识，至少知道他们在你的静态页面中那里需要插入动态数据，有哪些东西可以做成可配置的，有些页面跳转可能导致他们拿不到回值等。这样你会成为后端的好朋友。1.7如果掌握了以上所说的知识，那么就有充足的时间去学习一些应用还不是很广泛的知识。提前挖好自己的井。列：phonegap，appcan它们可以将移动页面变客户端，并提供很多模拟客户端本地效果的js，虽然这种东西不可能代替原生可是某些二级页面或者企业项目可以用这种东西快速完成。ajax，你可以做到一些简单的数据传输。canvas配合的cocos2d，cocos3d（我们中国人的东西）等的动画js，常用于h5游戏，最近我发现企鹅的某些品牌移动web也用的类似的手法。当然还有很多，学习一样的过程中自然就会发现更多其他的。1.8 前端工程师是设计与实现的枢纽，在职业划分中很重要也很专业。项目约复杂对专业性要求越高。是个需要很长很长时间去用心掌握的技能。成为设计师需要掌握的技能：ps：我不知道lz理解的ui设计师和我理解是不是一样的。我自己根据行业来划分。平面设计师，互联网设计师，3d设计师，动画设计师，视频设计师，插画师，游戏场景，游戏人设。因为项目以及职业规划的不同可能掌握多种技能，或许有大神都能掌握并精通吧。最常见的还是2d 平面+互联网+插画。3d 3d+动画+视频 。绘画艺术 插画+场景+人物。的技能组合。我来说说和我工作相关的2d类设计。-----------------------------------------------------------留个坑。1.1 2d类设计应用环境：网站设计，平台设计，专题设计，app设计，h5设计，海报，单页，画册，大轮播，ppt等其中分为2个大类互联网设计和平面设计。从某一大类入行，学到东西会不一样。相对来说平面设计对视觉的发展程度高于互联网设计，互联网设计的应用场景比平面多很多，入门级要求没有那么高.1.2 2大类中视觉呈现最难的是专题和海报。专题类又分游戏和电商比较难。平面类海报以汽车和房产略微高端。1.3 以纯视觉来说平面设计对视觉要求更高一点。平面设计是看的，互联网设计是用的。1.4 选择好最终的方向，以题主的ui设计来看应该是偏互联网设计的，平面设计没有ui的概念。1.5 互联网设计视觉以电商和游戏的专题及h5页面为最。交互以平台类和对c端app为最。重视觉先学好字形，场景，主视觉的搭配后学界面元素的合理排布以及引导用户视觉走向的方法。重交互先入一行了解业务需求，目标客户，与产品沟通的方法，界面的逻辑，易用，复用后学视觉呈现。------------------------------------------------------------留个坑，设计还没说完1.6 做出好的设计方法有千万种。做出不丑的设计倒是有一种方法。就是对技法的磨练。1.7 何为技法，我说一个集结为主题的游戏专题设计过程吧。从策划处拿到需求，设计找策划拿到需求。1.7.1 找策划确认几个环节，主视觉是什么？头图是否会修改成批量广告图？有没有领导说过偏向于那种配色？这波活动目标群体是什么？活动的目的是为了提高注册还是概念宣传？等越细越好。每一句话代表一个页面元素。1.7.2 确认好设计模块。头图，转化按钮，功能区，内容描述区，集结产品区，提交弹出区，底部。1.7.3 根据游戏风格和目标用户订好整体颜色基调最好不超过2种预留一个颜色做辅助色。根据辅助色寻找或手画符合页面和游戏风格辅助元素用于描述区，产品区，提交区。保持风格统一。1.7.3 头图分为三大块，字形，主视觉，场景。字形尽量做到有整体，有变化，有对比，有质感。场景分为前景中景后景为了提高界面的纵深层次与氛围。主视觉可是是字最好是人，如果是人就需要调整人物光源和阴影，如果是战斗类的图片最好选有张力的人物并加点动感的处理手法。选图是很重要的基础技能。1.7.4 功能模块，图形化半写实化处理。列：抽奖用转盘，数字用进度条。在主元素外加点之前手机的细节元素组合成符合本页面的主题。1.7.5 基本这2块做的不错，稿子也就过了，有更多的时间可以继续优化的其他模块，增加和减少元素让页面看的更舒服和易用。1.7.6 上面所说的就是很少一部分的技法，色彩的搭配，对比的使用，界面的排版，明暗的选择等都是技法有一定的标准，学会了基础就更有能力去追求更难更高的。这个时候你已经知道要追求的是什么了。1.8 ps，ai，painter这些工具只不过是你手中的笔。画，画的好不好，最终看的还是人，以及如何选择自己合适的笔。先玩好一个高级软件。我是以ps入门，3年后接触的ai，抓了个高手问清了区别半天也就会了。然后其他2d软件看看就能玩了。1.9 色彩，结构，排版，对比，视觉引导，交互，整体感，选图，统一性这些以及这些的细分都属于技法，是基础，技法掌握的越多越好。2.0 我的个人理解，2d设计是不分平面互联网的，也是不分行业的。基础是一样的，所以能做出的结果是一样的。2.1 会一些手绘，无论是画插画还是2.5d图形，还是高阶的修图，调色都是决定你如何比一般设计师更优秀的关键因素。2.2 设计是一个一生的职业，就算有一天不从事这一行了，可是从设计中学会的思维能帮助我们去解决一些事情。2.3 设计很苦，入门很难，工资也没有研发高。一定要喜欢，不然最好不要选。我不想见到又一个刻苦的手艺人因为生活的压力而放弃。以上二种你都是专业性极高的科目，都需要花上整个青春去学习才能称之为优秀。可是一旦成功，你将变的无可替代，特别是设计。如果你不幸因为工作的关系不能丢下2个技能，那么你将和我一样苦b的选择了第三条路，全栈设计师，你需要花更多的时间去学习很多的东西，无时无刻担心被时代所淘汰。你会产品，没有产品优秀。你会策划，没有策划优秀。你会交互，没有交互优秀。你会视觉，没有设计优秀。你会前端，没有前端优秀。你会ppt，文案，能与所有环节沟通顺畅，能独立做很多事。你身边的人都说你很牛b。可是这一身你将与大师无缘。当你花了很长时间（至少一万个小时吧）去做一样事情，你就会很优秀。路怎么走，想好再走。
TA的最新馆藏
喜欢该文的人也喜欢Java|ui设计|web前端|移动开发等信息资讯平台
美国上市公司亿元级外企IT培训机构
当前位置 :
> Web前端开发与UI设计哪个发展前景好
Web前端开发与UI设计哪个发展前景好
时间： 14:42
来源：web前端培训网
作者：IT培训网
已有：名学员访问该课程
每期开班座位有限.0元试听抢座开始！
请输入正确的验证码
温馨提示 : 请保持手机畅通，咨询老师为您提供专属一对一报名服务。
------分隔线----------------------------
------分隔线----------------------------
全国服务电话：400-017-8985 全国监督及投诉邮箱：
Powered by
(C) IT培训网一站式精准营销服务平台 cnitedu Inc.
备案信息：
Copyright (C) . IT培训网 版权所有专业解读：学UI设计还是WEB前端？
专业解读：学UI设计还是WEB前端？
大家都知道， UI设计和Web前端开发是当前比较火爆的两大互联网热门岗位，随着移动互联的深入发展，目前市场对这两大专业人才的需求有增无减。而对于那些想学IT培训的人来说，也总是会遇到“到底学UI设计好还是WEB前端开发好”这样的疑问。今天，就让北大青鸟来为你解开这个疑问。
首先，什么是有Web前端开发呢？通俗来讲，当你打开某个网站时，往往第一时间被那些炫酷的动态网页设计所吸引。但是，如果没有Web前端工程师，这些图片是不会动的。这样一个动态网页是怎么实现的呢？ 首先，需要UI设计师按照市场部要求进行每张图片制作；然后WEB前端工程师通过技术手段实现滚动效果。通俗点说web前端工程师就是用HTML5、CSS3、JavaScript、jQuery、Ajax等技术把UI设计的页面效果做成网页，结合Bootstrap、AngularJS等最新的JS框架和后台开发工程师搭线，最终实现让大家看到的电商平台上那些动人的精美页面。
那么什么是UI设计呢？所谓UI设计指的是用户界面设计，即user&interface&design，通常包括平面设计，网页设计以及移动界面设计。其中，网页设计和移动设计这一岗位方向，需要学习Web界面设计、PC客户端软件界面设计、HTML5语言、CSS样式表、布局技巧与浏览器兼容等技术。因此从这一点来说，web前端开发与UI设计之间是互通的，也就是说，通过系统UI培训后，你将来有可能会成为一名web前端工程师！
实际上，除了工作岗位不同以外，二者最大的区别就是：WEB前端工程师是要写代码的，而UI设计师重点在设计上。因此，对于广大学员到底学UI设计好还是WEB前端开发好这一疑问，北大青鸟方面建议，学哪一个都不错，但最重要的是看你自己的兴趣所在。然而，对于初学者来说，无论是UI设计好还是WEB前端开发，尽可能通过系统培训多涉猎一些相关知识，这对于将来职场发展会更有帮助，可以在以后职场中更好的相互协作和支持。
因此，一门系统培训课程就显得很重要。如北大青鸟UI设计课程内容上不仅涵盖了美术基础、Photoshop、Dreamweaver、Illustrator、Indesign、网站配色与布局、移动端UI规范等互联网UI设计师所必需具备的技能，还增加了网络营销基本常识、符合SEO标准的网站设计、Landing Page设计优化、电商网站设计、店铺装修设计、用户体验与交互设计、HTML5/CSS3开发标准、Web端及移动端真实商业项目，使学员通过项目的制作，更加全面的了解行业的前沿知识与理念，并能够合理地运用到实际工作和项目的设计制作中。
此外，北大青鸟APTECH副总裁肖睿也在UI设计师课程发布会上指出：“目前UI设计的成果很多是和网站、程序做结合，为了达到更好的融合，需要设计师们了解一些代码。针对这种现状，要求他们不能自己闷头做设计，即使他们写不了代码，但必须要懂得工程师的工作。对于想要跨过UI设计做产品经理的学员来说，因为产品经理需要和团队的UI和代码打交道，懂UI设计方面的知识将会更好促进工作的顺利开展，同时产品经理需要和客户做沟通，在产品越来越重视体验的今天，如果学员有UI设计的基础，对于做原型等各方面的工作将有很大的帮助。”
综合来说，无论是学UI设计好还是WEB前端开发，终极目标都是为了更好的用户体验和交互应用，而随着移动互联网的深度发展，对用户体验的极致追求势必会需要大量的UI设计师和WEB前端开发人员。因此学生需要的做的是了解更多相关知识，尽力的学习好它，让它为你所用，只有这样才会在未来有很好的发展！
编 辑：章芳
公司必须持续不断的、永恒的促进组织血液流动，增强优秀干部..
CCTIME推荐
CCTIME飞象网
CopyRight &
京ICP备号&& 京公网安备号
公司名称： 北京飞象互动文化传媒有限公司
未经书面许可，禁止转载、摘编、复制、镜像详细解析前端工程师和UI设计师如何合作
如果不坚持,何必当初那么努力
帖子154084&缘分币462940 Y&阅读权限255&注册时间&
15:14 
详细解析前端工程师和UI设计师如何合作
有刚毕业的前端同学问，如何与公司里非专业的网页设计师更有效地合作?在实现设计师的设计稿时，如果有自己的一些想法怎么办?是直接什么也不说，直接照着设计稿做，还是提出一些建议交流?今天让两位前端前辈一一帮你解答。
大学毕业一年不到，期间算上实习也近一年半，没有正式地与设计师合作过。近来公司来了一个平面的设计师，第一次尝试网页设计，双方都没有相互合作的经验。网页选择了响应式的设计，对设计师而言比较新颖，不能一开始很好理解。也因为个人的一些想法会与设计师不一致，想问几个问题：
如果非专业的网页设计，如何可以尽快地让双方更有效的合作?
作为一个前端工程师，在实现设计师的设计稿时，如果有自己的一些想法怎么办?是直接什么也不说，直接照着设计稿做;还是提出一些建议交流?
如果是设计师全权负责设计的话，那前端工程师在github、codrops，Dibbble上看到先进优秀的效果，是不是就没有用武之地了?
豪情先就个人认识方面的经验，回答一下你的问题，仅供参考：
1. 如果非专业的网页设计，如何可以尽快地让双方更有效的合作？
要有一个共同的目标的前提下沟通，如果目标不一致，或没有目标，那就没办法沟通。
比如我们有一个宣传活动，这个活动的最终目的就是吸引新用户注册，那我们交流沟通时，完全以这个为目标，与这个偏离太远的直接砍掉，否则加进来。
另外要有第三者中立方存在的情况下沟通，比如技术负责人，项目经理等。要不然责任划分不明确，场面容易失控，意思就是讨论是说的在多，最终得有个人拍板。
2. 作为一个前端工程师，在实现设计师的设计稿时，如果有自己的一些想法怎么办？
是直接什么也不说，直接照着设计稿做;还是提出一些建议交流?
有想法可以跟设计来交流，但我个人的经验，先做好前端本职的事情，一般的经验就是工作不饱和，自己份内的事情没做好就想这想那的。
3. 如果是设计师全权负责设计的话，那前端工程师在github、codrops，Dibbble上看到先进优秀的效果，是不是就没有用武之地了？
技术永远是在找寻发现价值，只是一个工具，不能本末倒置。
然后是分享一点我们积累的知识，仅供参考：
来自于群内周五晚上的一次头脑风暴式的思维碰撞交流活动。
文章版权属于群内发过言的任何一位同学，我只是做了简单的梳理或整理。
一般设计师给前端的只有psd，没有其它多余的东西，连基础的文档都懒得给。前端期望中的设计能给予的除了psd之外，还有设计上游岗位传递下来的东西。比如：产品原型，需求文档，交互文档等等。
一般在真正的代码开发进行之前，前端期望中设计给的东西有：
1. 1份jpg文件: 里边有各个psd的动作分解图，包括页面逻辑，或交互分解。设计师放成这样的目的在于在做设计时方便的拷贝，但对开发人员来说，如果分级过于隐藏就会漏掉某个部分的开发。
2. 1份psd文件: 一份好的psd文件是分层清晰，设计规范的文件。
3. 1份需求文档: 需求文档是对当前开发功能的基础介绍或逻辑详细描述。
4. 1份原型文档: 原型设计文档一般是由产品经理对最初功能设想的一份粗稿，这份稿只是对布局或交互做简单的设计，需要经过设计进行艺术的加工之后，才成为一个可以呈现给用户的完整界面。
当然这些所有的结果，需要经过层层开会审核，征得各个项目组leader的同意之后通过邮件的方式发送给各个成员，最粗笨的办法就是放在局域网的共享地址可以去拿psd文件。
恩，然后所有的中间需求变更、界面变更都要抄送相关人员，免得中间再次沟通，浪费时间。
一般的psd或许是这样的：
其实期望的是这样的：
因为前端要还原页面的时候频繁的去隐藏不同的图层来观察效果或切割图片，设计师是组合不同的图层到一块，而前端恰恰是一个相反的过程。
所以一个好的图层结构会为下游岗位节省很多的时间。那这时候有个问题，做为前端，你为下游岗位提供了多少便利之处呢?
还有公司更详细流程是这样的：
1、需求提出，产品跟产品leader沟通需求
2、产品leader跟开发、测试、ui/ue要人，要排期
3、要来的人大家一起开发，挑战产品经理，跟批斗似的，产品拿着需求文档讲ppt
4、需求回归
5、继续批斗(4、5一直重复)
6、需求ok了，开始ui/ue设计
7、评审ui/ue
8、ui/ue回归
13、有问题回滚。
另外公司的设计是这样的：通常PSD要把交互效果的图层都做好，出JPG的时候，都会把默认状态，交互状态，管理员状态各自出一个，然后弹窗布局出一个，都做得很精细。
这样导致的结果是想犯错都没有机会。
有的公司设计部有自己的规范，首先他们出的图都是很合乎规范的，间距、色值、布局、字体不会很多，因为整个产品多个页面风格要统一一致，所以越花哨是越给自己找麻烦，他们也不会有特别多种不同规格混揉在一起。
比如是这样的：
还有的是跟产品开需求会或项目立会的时候，会先就具体需求的功能点先做可行性方案的讨论，如果开发成本过高的话，通常都会说服需求方用一些替代方案。
又或者是一些高级的功能模块，我们会把项目拆解，分成几期，首先先出核心功能模块，上线之后再做一些高级需求的模块，实现产品的迭代开发。
关于标注规范，推荐：Super Marker 小胡子哥的切图神器。
另外一个观点是从产品的高度来看，设计、前端、后端 应该是一个整体，最终应该结果导向，产出的产品不好，作为开发团队其实都有责任。
还有的情况是，每个项目都会有汇总目录，原型是由需求直接提供的，PSD和JPG在设计的汇总目录里，我们的制作稿又是一个汇总目录，所有环节的童鞋都可以非常直观方便的查看这些文件。
然后跟设计交流的时候的坑有以下几种情况：
1. 有些界面出于时间或员工本身经验素质的问题就是不愿意出psd图，然后口头上通知前端，这样来就可以那样改就可以了，这就是一个坑。
按我们的经验对这种情况做出的建议是：
所有的东西都必须出效果图，并且所有团队成员达成一致，有可执行性。所有的字体，间距，颜色，必须约定统一并且完全标识清楚。
杜绝直接这么说那么干的做法。
要不然最后做出的产品，产品说的是一套，测试测的一套，开发的一套，老板看到的又是一套，返工的可能性很大。我感觉比起这个返工的可能呢，前面多化点把设计稿做好是无可厚非的，而且从整个项目开发周期来看，是节省开发周期的。
2. 有些页面设计师没有考虑到，比如：
有些页面在没有数据的时候设计师没考虑到，或者经验不丰富就没做。
这时候必须要求设计师，给出首页或列表页、内容详细页、用户中心等等没有数据时的效果图，以示团队所有成员知晓，并达到一致。要不然等上线之后，测试数据删除之后真实数据还没有上来之前，
老板心情好要看一下的时候，页面就整体失控。
还有一种情况就是前端自己整的数据没有的提示，从交互形式，文案上都没有规范，导致最后一步测试的时候在返回来重新修改，浪费时间。
3. 数据过多的情况：
另外一种常见的问题是数据过多或者文字内容过长撑开容器，这两种问题再实际做的时候常常会被漏掉，然后等到测试的时候才发现问题提过来。
还有两种情况会遇到：
A. 有些前端在看到设计稿的时候，难免看的不舒服，这时候就从非专业的角度开始提建议，但提的时候又不流行技巧，容易发生冲突。
这时候给出的建议是：
提意见是这样的，除非你干过设计或者了解设计的创作过程，否则从设计的角度最好不要提不同的意见。
可以从交互或功能或体验上给建设性的意见，另外讲的时候是需要技巧的，可以先正面肯定一下他的劳动成果或努力的结果，然后说，我这儿看到几点问题，跟你交流一下，然后布啦布啦，而不是直接上去就说，我感觉这儿怎么怎么的，很主观的，说这样根本没有一个评判的标准或依据。
最后一定要说，根据你的行业经验或自我设计标准，你肯定不会允许这样的现象出现吧，然后你看要不要在重新考虑一下。我就是想到了给你提一下。
强调这个非正式的提法，给自己或对方都留有余地，都有可以退让的空间，皆大欢喜。
B. 要是效果图是客户提供的怎么破？在沟通是有什么经验？
设计的质量如果本身就有问题，比方说就没考虑添加数据以后的情况，或者是其它页面在流程上风格上不统一怎么怎么的，客户又不是很懂，初期非要你按照他的想法来。
这时候就需要站在一个更高的高度来有技巧的处理这个问题。
比如说，你这个页面等上线后，在用户看来2个页面看到的按钮不一样，感觉很外行，从而导致的结果就是下次不在访问，这样用户就会丢失。
你看有没有必要重新考虑一下，最后设计和开发，去年克军在广州的webrebuild 分享了他那个“还原活的设计”的主题，我觉得挺受用的，跟大家分享一下。
还原活的设计地址：还原”活”的设计 · kejun。
来自@Chuckie-Chang 的分享：
每个团队的合作方法不尽相同，我接触过的比较好的合作方式，我就直白口水话方便易懂，仅供参考：如果你是前端，你可以给设计师提以下一些要求：
1.如果想要95%以上还原设计稿，你必须提供给设计师设计时的注意事项，当然如果设计师有前端功底，他的设计会考虑到更多的协作性，通俗点说：比如设计的PSD稿件的图层切图的形状不要太另类，不同的分辨率，元素布局上你能不能敲代码实现，容不容易做出来，不要太自我主义不考虑前端，到时候做出来的东西又返回头改死人，甚至前端出来后一塌糊涂，两败俱伤。
2.你看过的或者项目交互上想要的效果，让设计师分析这种效果拆分后该设计些什么东西?设计量有多少?能不能用图形的方式直观的设计出来?等等
3.自己用铅笔在纸上画的草图，设计中的部分重要细节和你自己的想法要亲自提醒设计师。
4.项目碰头的时间段，如何碰头，使用远程工具?使用QQ?还是直接离开办公椅面对面?还是茶水间?是1天碰头一次?还是设计完某部分碰头一次?发现问题就可以及时修改，避免事倍功半。
5.让设计师准备好详细的设计说明文档，文档可以是直接套用html模板，可以是word，可以是图片或者思维导图，总之要让前端设计师一目了然知道为什么这么设计，这样设计让前端怎么用，怎么配合。
6.如果设计师有前端功底，你还需要让他提供一些他设计时考虑到的插件或者代码(比如设计banner时他想要视差，3D，还是滑动等效果，要用到什么插件，用了什么框架等)，这样能提高前端的质量和效率。
同时，你需要让设计师给你提供：
1.完整的，规范的PSD分层文件，最好是要切图的部分就是一个图层或者 文件夹，使用photoshop的快速切图插件，单独导出图片，快速准确，不建议使用PS默认的切图工具。
2.详细的，规范的设计说明文档，标注文档。
3.对于有前端基础的设计师，需要提供他设计时考虑到的前端效果插件或代码，是否使用前端框架等。
4.适合你们的沟通协作方式。
5.如果是比较有经验的设计师，能给你提供一个demo(可以是视频，或者gif，甚至是用纸和笔画出的交互效果)，能大大提高前端的质量和效率。
最后的最后，前端攻城师和设计师互相提供这些需求和资源的同时：
不要忘记了产品经理或者老板或者你们部门的项目初衷，也要做好和上层的对接。
在过程中试错，在试错中体验，在体验中修改优化，在修改优化中培育协作能力和感情，在协作和感情中喝杯咖啡聊聊天泡泡妹子!
不要怕沟通起来，或者随时跟着进度沟通协作麻烦，其实互相交心，多沟通，大家都能开心的做好前端和设计，可以大幅度减少返修，减少加班，同时还有空一起去喝杯咖啡缓缓神。
你闷着头做前端不去学习或者多了解一下他的设计和他的想法，或者他闷着头做完设计从来不关心代码是啥东西，做完就丟给你，只会两败俱伤，伤感情。
来源：知乎& & 作者：豪情
如果您在做图或者看教程（PHOTOSHOP方面），遇到任何问题请到问题交流区提问，地址：；我们会在第一时间帮助您解决问题，如果在教程后面跟帖，一律不给予解决！~
UID1&精华&积分469134&威望26030 F&回复币50732 B&警告0 次&贡献2117557 &金币2 个&学分0 点&性别男&来自上海&最后登录&
当前时区 GMT+8, 现在时间是我的职业是前端工程师 - 知乎专栏
{"debug":false,"apiRoot":"","paySDK":"/api/js","wechatConfigAPI":"/api/wechat/jssdkconfig","name":"production","instance":"column","tokens":{"X-XSRF-TOKEN":null,"X-UDID":null,"Authorization":"oauth c3cef7c66aa9e6a1e3160e20"}}
{"database":{"Post":{"":{"title":"最流行的编程语言JavaScript能做什么？","author":"phodal","content":"首先很遗憾的一点是，“PHP虽然是最好的语言”，但是它不是最流行的语言。对不起的还有刚刚在4月TIOBE编程语言排行榜上榜的各个语言：你们都很棒，但是你们都担当不了这个大任。开始之前，我先说一下我常用的三个语言：Java、JavaScript、Python。Java，让我学到了很多架构层级的知识，这一点可以参考我之前写的架构相关文档。虽然我一点儿也不喜欢这个语言，但是它真的很棒。Python，它真的足够简单，以至于我喜欢拿它学习各种理论知识，如推荐系统、贝叶斯定理、自然语言处理等等。JavaScript，看下文。数据可视化在过去我阅读的一些书籍里面，主要是以Processing作为可视化的语言——它起始于2001年，它最初是面向美术工作者和设计者创建的，后来变成了全面的设计和原型工具，可以用于创建复杂数据可视化领域。Processing被带入了到Web领域产生了Processing.js，还出现了D3.js当然还有Plotly、Leaflet、Sigma JS等等的工具。移动端应用： Cordova接着就是PhoneGap（今天的Cordova），将WebView带向了移动应用，也将JavaScript带向了移动应用。使用Cordova，可以让我们一次开发多平台发布。我们也顺便提一下Ionic，作为混合应用的翘楚：移动端应用： React Native既然我们已经提到了Cordova，那么我们也应该说说React Native。也是一次开发多次运行：虽然它的坑还有很多，但是还是值得期待的。服务端：Node.js正是V8的性能将JavaScript带到了一个新的高度，于是Node.js诞生了——前端、后台都可以用JavaScript，一个JavaScript的全栈时代。Mongodb作为数据库，Express作为Server端MVC，他们可以提供一个RESTful服务，那么再加上MVVM框架的Angular.js，你就知道我在说什么!桌面应用： NW.js 和 ElectronNW.js 是基于 Chromium 和 Node.js 运行的， 它们可以让我们用HTML和JavaScript来制作桌面应用。除了NW.js还有最近比较火的Electron，Atom编辑器的与Cordova的多平台构建多版本不同的是，Electron可以在一个平台上构建多个平台的应用。即我们可以在Mac OS上打包出Linux和Windows上的应用，而不需要在Windows再编译一次。带向了桌面端，让桌面和Web保持了一致。最成功的案例就是估值达30亿美元的Slack：So，如果你使用桌面端的Slack就会很卡~~。全平台应用还记得我写的那篇《》，在Eletcron上运行Ionic，就意味着无限的可能性。能用Web开发的事情就用Web来完成就好了。游戏自从WebGL被带入浏览器的那一刻，就决定了这又是一个新的天地。让我们忘记编译、启动更新、外挂等等的问题，并且我们还可以一次开发直接运行。VR如果你看到过之前的那篇《》，那么你就会对这个内容有更多的印象。主要思想还是通过WebView来渲染VR视角：并且各浏览器产商各在推进WebVR 为虚拟现实设备显示提供支持。AR虽然大部分的AR应用可能离我们有点远，但是离我们最近的就是Leap Motion——它可以利用手掌和手指动作来进行输入，但无需手部接触或者触摸。同理于VR，读取传感器的数据，再将其手势交由浏览器端来处理。详细可以参考我之前写的：《》硬件早先我看到了Arduino在编译的时候，以DSL的方式封装了API。而NodeMCU则内建了Lua语言的支持，可以让开始者使用Lua来开始。 而Tessel 原生就提供了JavaScript运行环境，我们写需要写好JavaScript就可以在上面运行。Tessel 2属于配置比较高的硬件，而低配的呢？三星设计了JerryScript引擎，它能够运行在小于64KB内存上，且全部代码能够存储在不足200KB的只读存储（ROM）上。想想就觉得未来是美好的。物联网等等，上面三星推出的是IoT.js，这就意味着它已经可以在物联网领域中应用了，为什么还会有这里的应用呢？我只是想稍微提一下这个：上面说到的只是Node.js在Web中的应用，而物联网和Web的很大不同之处在于，物联网可以使用各种不同的协议，而这些协议都需要Node.js对其的支持。因此，如果我们需要开始Web版、移动应用，那么我们自然更需要其作为后台。操作系统界面虽然更好的机器带来了更好的性能，但是显然人们对于原生应用的需求并没有那么强烈。Firefox OS已经在移动操作系统败下阵来，但是这个操作被带到了物联网领域：这就意味着，我们可以使用JavaScript来开发操作系统的界面了。你觉得JavaScript还能做什么？更多精彩内容欢迎关注我的微信公众号：Phodal","updated":"T11:26:00.000Z","canComment":false,"commentPermission":"anyone","commentCount":12,"likeCount":121,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"T19:26:00+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/4d656cfbb76638b40faed4_r.png","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":12,"likesCount":121},"":{"title":"致JavaScript也将征服的物联网世界","author":"phodal","content":"凡是能用JavaScript写出来的，最终都会用JavaScript写出来。—— Atwood定律在那篇《》里，我们列举了JavaScript在不同领域的使用情况，今天让我们来详解一下JavaScript在物联网中的应用。基础：物联网的三个层级开始之前， 先让我们简单地介绍点物联网的基础知识。如果你有点Web开发经验的话，都知道下图是CS架构：相比于一个物联网系统，无非就是多了一层硬件层以及可选的协调层。这个硬件层决定了物联网应用比Web应用更加复杂。对于大部分的Web应用来说 ，客户端都是手机、电脑、平板这些设备，都有着强大的处理能力，不需要考虑一些额外的因素。对于物联网应用来说，我们需要考虑设备上的MCU的处理能力，根据其处理能力和使用环境使用不同的通信协议，如我们在一些设备上需要使用CoAP协议。在一些设备上不具备网络功能，需要考虑借助于可以联网的协助层，并且还需要使用一些短距离的无线传输协议，如低功耗蓝牙、红外、Zigbee等等。一个物联网系统：六种语言两年半以前，大四，电子信息工程，我选定的毕业论文是一篇关于物联网的论文——《基于REST服务的最小物联网系统设计》。这是一篇入门级的物联网论文，如果大部分学习CS的人有一点硬件基础，都能写出这样的论文。这篇论文是之前参加比赛的作品论文的“最小化”，里面使用到的主要就是创建RESTful服务，而它甚至称不上是一种技术。在这个作品里：我们使用Python语言里的Django框架作为Web服务框架，使用Django REST Framework来创建RESTful服务。为了使用手机当控制器，我们还要用Java写一个Android应用。我们使用Raspberry Pi作为硬件端的协调层，用于连接网络，并传输控制信号给硬件。我们在硬件端使用Arduino作为控制器，写起代码特别简单，可以让我们关注于业务。最后，我们还需要在网页上做一个图表来显示实时数据。所有的这些，我们需要使用Python、Java、JavaScript、C、Arduino五种语言。而如果我们要写相应的iOS应用，我们还需要Objective-C。JavaScript在物联网领域的发展同样的，两年多以前，刚实习，在我们的项目里，我们的新项目里我们使用Backbone作为单页面应用框架的核心来打造Web应用。这时，我开始关注Node.js实现物联网应用的可能性。当时，已经有了物联网协议MQTT和CoAP协议的库，于是我照猫画虎地写了一个支持HTTP、CoAP、WebSocket和MQTT的物联网。由于，当时缺乏一些大型应用的开发经典，所以做得并不是很好，但是已经可以看到JavaScript在这方面的远景。一年多以前，Ionic还没推出正式版的时候，我发现到了这个框架真的很棒——它自带了一系列的UI，还用NgCordova集成了Cordova的一系列插件。我便开始使用Ionic写了一些移动应用，发现还挺顺手的。接着，我就开始拿这个框架尝试写物联网应用，这需要一些原生的插件，如BLE、MQTT。后来，我也写了一个简单的CoAP插件。后来我们不再需要编译Node.js，就可以在ARM处理器上运行Node.js。并且我们已经有Tessel、Espruino、Kinoma Create、Ruff这些可以直接运行JavaScript的开发板。三星还推出iot.js，可以让更多的嵌入式设备可以使用JavaScript语言作为开发语言。人们开始在硬件上使用JavaScript的原因有很多，如Web的开发人员是最多的、JavaScript很容易上手。现在，这次我们在这三个层级上都可以使用JavaScript，只需要一种语言。使用一种语言开发物联网应用：JavaScript在我写的那本《》中，我就试图去展示JavaScript在这方面的威力。使用Node.js + Node-CoAP + MQTT.js + MongoDB + Express搭建了一个支持多协议的物联网：不过，上图是完善版的物联网，代码自然是在GitHub上啦：。作为服务端来说，Node.js的能力已经是经过验证的。而在混合应用上，仍然也可以经受住考验，混合应用在手机上做个图表是轻轻松松的事（只需要获取数据，然后显示）：作一个控制端也是轻轻松松的事（我们只需要发个POST请求，更具逻辑一点的就是先获取状态）。而在硬件端，我并没有在书中以JavaScript作为例子来展示JavaScript的用法，因为这会局限了用户的硬件设备。不过，我们仍然可以使用类似于Johnny-Five这样的库来做硬件方面的编程，只是它没有那么好玩~~。既然我们可以JavaScript来实现，为什么我们还要喝杯咖啡等它用C编译完呢？你想知道的答案都在这本书里，已在亚马逊、京东、当当上架A Phodal's Book亚马逊：京东：毕竟：凡是能用JavaScript写出来的，最终都会用JavaScript写出来。","updated":"T14:06:26.000Z","canComment":false,"commentPermission":"anyone","commentCount":34,"likeCount":229,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"T22:06:26+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/88924f6cfc7ddc5e69b4f00dede909fd_r.png","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":34,"likesCount":229},"":{"title":"我的职业是前端工程师【一】: 我要成为一个前端设计师","author":"phodal","content":"我年轻的时候，是一个前端工程师。那时候，有这样一个传说：美工是最受妹子的欢迎，其次是半个美工的前端工程师。本故事纯属瞎掰，如有雷同纯属巧合——Phodal @PasteRight未满 18 年时，想成为一名 Kernel Hacker，就是那种操着键盘，在屏幕洒下一行行汇编语言的大牛。在我学了一段时间 C++ 后，我觉得：『用记事本写代码，并运行起来』的故事都是骗人的。为了将代码转变为程序，你还需要一个编译工具。然而有一天，我在网吧里看到一个人在记事本里写代码。开始的时候，我觉得这个人是个新手吧，怎么拿记事本在写代码呢，不是应该都拿 IDE 才能编译运行吗？几分钟过后，我发现他居然能将，记事本写的程序运行起来，太神奇了，Amazing Man。后来，为了在别人面前装这个 100 分的逼，我成了一名 Web 工程师，而且还是一个前端工程师。（PS：以上纯属瞎扯）漂亮的前台各位看官中，有些可能不是前端工程师，那就先让我来说说前端工程师是干什么。前端又可以称之为前台，不是那种每天对你笑、帮你开门、长得还算不错的前台，然而却也差不了多少。他们要做出好看的、美丽大方的界面，以免吓走那些对颜值有要求的挑剔客户；还要对指引好用户，免得有些用户认错了楼、走错了路口，然后再也不来光顾你们的网站了；有些时候，还要像处女座纠结于对齐，纠结于 px px 的程序员。你还会看到他们拿起纸当尺子，一点点的测量着什么东西，好似在怀疑这个屏幕是不是真的是 15.4 寸。 如果你看到一个程序员，他在纠结椅子是不是摆放正确的，那么它有可能是三种程序员中的一种：处女座程序员、前端工程师，还有测试工程师。我们就像上个世纪的网民，时不时地按下 F5 又或者 Command + R 来刷新页面，一直在怀疑页面上的内容是不是最新的。好在后来，有一个伟大的大魔法师发明了一个工具，可以检测到代码修改，自动地帮你刷新页面。终于，不再像个老大爷一样踢电脑，以指望提高图片的质量，甚至去掉马赛克。过去，我也无法理解：这群智力超群的程序员，为什么会变得如此px px 计较，直到我成为了其中的一员。我要成为一个前端设计师习惯了大学的生活过后，我和好友楚非就一起去租了一个服务器，从此生活就变得有点艰难。不过有了一个服务器，我们就可以去做个网站，并托管别人的网站，然后就可以坐在学校里数钱了。对于当时的我而言，我并不想成为一个 Web 开发工程师，我还是从心底向往底层的开发。理想很美好，现实很残酷。虽然我们有了一个服务器，但是它不能立刻地为我们赚钱。我不知道一个完整的网站是怎样的，也没有找到客户。后来，直到大二下学期快结束的时候，我们才算迎来真正的客户。在那段找不到客户，也没有能力找客户的日子里，我们就这样把自己逼上了一条不归路。就这样和很多人一样，为了赚钱，就这样成为了一个前端工程师。这时，我们就遇到了一个问题：我们俩究竟谁做前端，谁做后台？这结局大多数人都是知道的，我来负责前端。然而每每说到：他是学美术的，他去做后台；而我是学电子信息工程的，我来负责前端，总会有人感到一些惊讶。选择前端，有这么一个主要的原因：离成为设计师的目标更进一步。我所理解的“设计师”，是广泛意义上的设计师。他们做一些创意的工作，以此来创造一些令人啧啧称赞的作品。这些作品不仅仅可以是一件雕塑，一幅画，还能是一个 Idea，一段代码。当你是一个前端工程师的时候，你是一个程序员，还是一个设计师。程序员本身也是设计师。虽然程序已经代替了相当数量的手工操作，要想代替程序员则需要更多的时日。然而，程序员手艺的好坏是有相当大的差异的。初学编程的时候，总会看到各种“程序设计”这样高大上的字眼，设计才是程序的核心。这就意味着，写代码的时候，就是在设计作品。设计是一门脑力活，也是一门模式活，从中能看出一个人的风格，从而了解一个人的水平。因为我认为，前端工程师还应该懂得设计。我便花费了很多时间去：学习素描，熟悉一些原型设计软件，了解各种配色原理。以指望我可以像一个设计师一样，做好前端网页的设计。毕竟代码和大部分艺术作品一样，容易被临摹、复制，而要复制思想则不是一件容易的事。而到了今天，我的设计能力还是有待商榷。幸运的是，我可以熟练地使用各种可视化工具，然后做出各种美妙的图案。我还能写编写一行行的前端代码，并写下这个系列（《我的职业是前端工程师》）的文章，来帮助大家深入了解前端工程师。关于《我的职业是前端工程师》人啊，总是喜欢写点东西去纪念自己的功绩，我也不例外。当我写了一段有意思的代码、尝试了一个新的框架、解决了一个很久的 Bug，我总会写个博客来炫耀一下。后来，随着博客越写越多，我开始尝试的整理一些话题，并将其编成电子书放在 GitHub 上共享。后来，就慢慢地有了出版第一本书的机会，想来第二本书也是能出版的，也应该很快地就会出版的。我的第一本书是纪念大学的专业，电子学习的是电子信息工程，便写了一本物联网相关的书籍。第二本则是一本关于全栈书籍，想来我在前后端之间已经受过很多苦，也因此学了很多知识，这些知识对于我来说像是一种财富。虽然花费了相当多的时间在编写上，但是总体上来说，对于我的益处还是大于弊处的。为了保证内容的准确性，一遍又一遍地去梳理知识体系，不得不再次去翻阅放在书架的书籍。也因此算是印证了那句话：输出是最好的输入。前端是一个很有趣的领域，有太多的知识点，和不同的领域都有所交集。为了展示前端的广度，只能像散文一样展开不同的知识点。因此呢，这一系列的文章，不再像过去的电子书一样，有着连贯的、互相依赖的知识。我真正开始从事前端这个职业，算了一下也差不多是三年了。三年之前的学校三年里，我在努力地成长为前端工程师，成为全栈工程师。而工作的这三年里，正好是前端高速发展的三年，他的发展速度有些夸张。落后了三个月，你就有可能需要重新入门前端了，痛苦的往事。","updated":"T10:34:22.000Z","canComment":false,"commentPermission":"anyone","commentCount":8,"likeCount":52,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"T18:34:22+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-482d3b857a551fbaed438e621ac51093_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":8,"likesCount":52},"":{"title":"我的职业是前端工程师【二】: 入门不是应该很简单吗？","author":"phodal","content":"入门前端，是一件很难的事吗？在今天，我也没有想好一个答案，也不知道怎样给出一个答案。这个问题并不取决于前端，而是取决于不同人的需求。到底是想要快得一步登天呢，还是一点点的慢慢来，去享受前端带来的乐趣。对于不同领域的学者来说，都会有一个相似的问题：如何从入门到精通？入门并不是一件很复杂的事，只是多数人想要的是更快的入门，这才是真正复杂的地方。虽说条条道路都是通过罗马的，但并不是每条道路都是能满足人们要求的。对于 A 说的路线并不一定适合于 A ，有可能会适合于 B；适合于 B 的路线，也有可能只适合于 B。前端之路谈起路线规则这事，就会联想起算法里的路径问题。想了想，发觉“如何教人入门前端”与“选择合适的路径”颇为相似的，要实现这样的规划蛮难的。先上张图，加深一下印象：接着，我们来思考这样的一个问题：每个初学者都处于“1”，最后的目标都是到“9”，那么你会怎么帮助他们规划路线？假设，每一个数字都对应了技术栈，并标注了每个技术栈学习所需要的时间。那么，这时要计算出最快的学习路线也就容易了。而这种开挂的感觉，就像是我们拥有了游戏中的技能树的一样。技能树上，包含了所有已知的技能，以及：学习某个技能所需要的时间，学习某个技能后可以触发某个技能等等。不幸的是，这个路线不可能会怎么简单。倘若你是一个在校的学生，或者是相似的研究人员，那么这种路线也颇为适合。理想的情况下，我们可以自由地分配自己的时间，在对应的技术栈上花费相应的时间。这就好像是游戏世界的技能树一样，我们所拥有的点数是固定的，那么所能学习的技能也是固定的。假使真实世界的前端技能树已经很清晰，那么这里的点数对应的就是时间。在时间固定的情况下，我们所能学习的技能也是固定的。而技能树中的时间花费是一个大的问题：当我们学习完某个技能后，我们可能就拥有其他技能的加成。在已经学会了 ES6 的情况下，学习 TypeScript 就变得更轻松，这时学习 TypeScript 的时间就会更短。也因此，相似的技术栈可以归类到一起。遗憾的是，学习相似的技术栈仍然是需要时间的。回到前端技术的话题上，在编写复杂前端应用时，我们都会采用前端框架来加快开发。前端框架的技术基础都是一样的，有区别的是，它们衍生出来的技术思想。有的框架创造出了一些有意思的 DSL（领域特定语言），可以借此编写出独立于语言的代码，这些代码也可以用在不同的领域里。一个很有意思的例子就是 Mustache 模板，即可以让我们用后台语言，如 Java，来渲染 Mustache 模板为 HTML，又可以在前端里使用 Mustache.js 来将模板渲染为 HTML。相似的，对于 React 中的 JSX 也是如此，我们即可以用 Node.js 与 React 在后台来渲染出页面，又可以在前端来渲染 JSX 为 HTML。我的前端入门在我刚学前端工程师的时候，由于只需要编写 CSS、JavaScript 和 HTML，因此要做前端的活相当的简单。有时，甚至会觉得有些乏味。我的第一个网站大一时，年轻气盛就去办了个社团，当了个社长。那会儿还能使用各种 Google 的服务，Google 刚刚开始推广它的云服务 Google App Engine。用户只需要点击一个按钮，就可以上传代码，应用就会自动地部署到相应的网站上了。下图就是我的第一个网站：当时，写给客户的代码大多乏味，没有挑战性。为了尝试各种新特性，我就将各种奇怪的 CSS3 加到其中。这一点在今天的日常工作里，也没有太多的变化。工作写代码是为了活下去，业余写代码则是为了兴趣。有意识地将两者分开，才能使技术更好的成长。我们不会因为，在项目里引入新技术而沮丧。同时，在业余时自由的使用新的技术，来提升自己的技术与视野。后来，世道变了，免费的东西还能使用，但是网站已经访问不了。我们尝试很 SAE 上迁移，虽然 SAE 很不错，但是你是要去备案的。再后来，我们就去租用自己的服务器了。Copy/Paste from Cookbook与现在稍有不同的是，现在写代码是 Copy/Paste from StackOverflow，那时写代码是 Copy/Paste from Cookbook。所以，我们只需要三本书就足够了：CSS CookbookJavaScript CookbookjQuery Cookbook它们包含了我所需要的一切，对应于不同的功能，都有对应的代码。我们所需要做的就是在合适的地方放上合适的代码。在阅读了大量的书后，我才得到了上面的结论。不过，大学不像现在这么“宽裕”，不能轻松地去买自己想看的书。一本书抵得上好几天的饭钱，不会毫不犹豫地“一键下单”。现在，仍然会稍微犹豫一下，这主要是房价太贵，租的房子太小。尽管我们的学校是一所二本院校，但是图书馆还算是不小的——虽然没有啥各种外语书，但是大部分领域的书总算是有一两本的，每个月还会进一些新书——反正屈指可数。四年下来，我算是能知道每一本计算机书的大概位置。因此，如果你只是想为了完成任务，而去完成任务。你就会发现，编程是相当无聊的，和一般的工作无异。开发工具最初，我颇为喜欢 Adobe DreamWeaver，还有 Chrome 浏览器，它们结合起来能完成大部分的 UI 工作。尽管在今天看来，DreamWeaver 是个一个奇怪的工具，它可以让我们拖拽来生成代码，但是这些生成的代码都是臭不可闻的。但是我爱及了他的及时预览地功能了，特别是当我在编写 CSS 的时候，不再需要在浏览器、开发工具不断切换。慢慢地，当我开始越来越多的使用 JavaScript 时，DreamWeaver 提供的功能就变得越来越有限了，我开始觉得它越来越难用了。曾经有一段时间里，我使用 Aptana——它可以将 minify 后的代码格式化。现在，我使用 Intellij IDEA 和 WebStorm作为主要开发工具，它们的重构功能让我难以自拔。当我需要修改一些简单的文本时，我就会使用 Vim 或者 Sublime text。在命令行里发现了一个问题，直接可用命令行来打开并修改。Chrome 浏览器在当时虽然很不错，但是当时市场占有率太低。只能拿它来作平时的浏览器，看看各种 IE 上的 Bug，再玩 CSS3、HTML 5 等等各种特效。多数时候你还是要用 IE 的，写下一行行的 CSS Hack，以确保大部分的用户是可以正常使用的。今天，也仍然在使用 Chrome 作为我的日常和开发用浏览器。虽然它还没有解释臭名昭著的内存问题，但是我们已经离不开它的 Console，Device Toolbar 等等的功能，同时还有运行在这上面的各种插件，如 Postman，PageSpeed 等等。jQuery 是最好用的在我发现了 jQuery 之后，我才知道它是一个神器。jQuery 有一个庞大的生态系统，有一系列丰富的插件。我们所需要做的就是，知道我们要实现的功能，找到相应的插件。紧接着，就去 Google 有相应的插件，然后按照他的 README 写下来即可。即使没有的插件，我们也可以很容易的编写之。到了后来，我觉得前端甚是无聊。这主要是限制于我们接的一些业务，都是企事业单位的单子，每天都是无尽的 IE 的兼容问题。这让我觉得同时使用很多个 IE 版本的 IETester，是一个伟大的软件。过了那段时间后，看到了 Node.js、Backbone、React、Angular 打开了另外一个世界。这算是前端 3.0 的世界了，这期待下一章《如何在三个月里学会期待》。","updated":"T10:41:18.000Z","canComment":false,"commentPermission":"anyone","commentCount":16,"likeCount":63,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"T18:41:18+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-482d3b857a551fbaed438e621ac51093_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":16,"likesCount":63},"":{"title":"我的职业是前端工程师【三】：学习前端只需要三个月【语言篇】","author":"phodal","content":"过去，我一直无法相信：一个新人在三个月里可以学好前端。后来，我信了。因为三个月后，我又是一个前端的新人，我又需要重新入门前端。前端领域好似也有一个“摩尔定律”。戈登·摩尔提出来：积体电路上可容纳的电晶体（晶体管）数目，约每隔24个月便会增加一倍，后来经常被引用的“18个月”。而对于前端领域来说，每隔3-6个月，知识点将增加一倍。过去一年（即 2016 年）的每三个月（或者半年）里，前端领域不断涌现出新的知识，这些新的知识不断地在更新。这些知识点，可以源自于后台知识领域，源自于某些特定的语言，源自于新的知识理念。我们可以很轻松地找到一个例子，如前端所需要的 JavaScript 语言本身，这个语言出现了越来越多的变种。为了完成一个复杂的前端应用，我们需要编写大量的 JavaScript 代码。但是早期版本的 JavaScript，并不适合编写中大规模的前端工程。JavaScript 语言的变化几年间，出现了 CoffeeScript、TypeScript、ClojureScript、Dart、ES6 等等的语言，他们都可以编译为 JavaScript，随后就可以在浏览器上运行。诸如 ES6，这一个新的 JavaScript 版本（现有的 JavaScript 版本，称为 ES5，即 EcmaScritp 5），则可以在最新的浏览器上运行部分或者全部的特性。这些语言在不同的时间段里，所受到的受关注程度都是不一样的。它们都是各自的特色，在不同的时期所到的欢迎程度也是不一样的：这种变化相当有趣。尽管 JavaScript 是所有主流浏览器上唯一支持的脚本语言，但是它在过去的主要用途是用来：做一些页面“特效”。它可以通过 DOM API 来操作页面上的元素，而这些元素就是显示在页面上的内容。随后 Ajax 技术诞生了，开发人员发现可以用 JavaScript 做更多的事。JavaScript 之时，是用于在客户端上执行一些指令。而 Ajax 则可以让浏览器直接与服务端通讯。这就意味着，你可以在浏览器间接地去操作数据库，前端应用便因此而变得更加庞大。JavaScript最初，JavaScript 是由 Netscape 雇佣 Brendan Eich 来开发的。当时他花了 10 天时间，设计出了这个语言的第一个版本。Netscape 与 Sun公司合作开发了该语言，当时 Java 语言比较火热，也因此该语言由 LiveScript 改名为 JavaScript。由设计初衷就是，适合于新手来使用。此时正值浏览器大战之时，微软也推出了与 JavaScript 相似的 JScript 语言，并且内置于IE 3.0 中。随后 IE 借助于 Windows 的威力，逐渐地占领了市场。后来，Netscape 便将 JavaScript 提交给欧洲计算机制造商协会进行标准化。标准化后的 JavaScript 便称为 ECMAScript，JavaScript 的版本也以 ECMAScript 来命名。尽管 JavaScript 的标准由 ECMA TC39 委员会制定，但是要操作浏览器的元素，还需要 DOM（Document Object Model，文档对象模型）。而 DOM 是由 W3C 组织推荐的处理 XML 的标准编程接口。遗憾的是，不同浏览器对于 DOM 的支持并不一致，还存在一定的差异。在早期的浏览器里，对于 DOM、事件、Ajax 的支持存在一定的差异，因此像 jQuery 这种跨浏览器的 JavaScript 库，相当的受欢迎。然而，为了新手更容易上手，该语言缺少一些关键的功能，如类、模块、类型等等。在一些完备的 Web 框架里，框架本身会拥有相应的功能。这些问题可以由各式各样的 JavaScript 库来解决。我们需要类的功能时，可以用 klass 库来补充；我们需要依赖管理时，可以用 Require.js 库来补充；我们需要类型检查时，可以用 tcomb 库来补充；我们需要Promise 库来解决 callback hell时，可以用 Bluebird 来补充。。。。这一切看上去都很完美，但是好像有一点不对劲。这些功能明明是这个语言应该要有的。我们却要在一个又一个的项目里，引用这些本不需要引用的库。ES6+作为一个程序员，如果我们觉得一个工具不顺手，那么应该造一个新的轮子。我也喜欢去造前端的轮子，有时候是为了理解一个框架的原理，有时候则是为了创建一个更好的工具。也因此，当 JavaScript 不能满足前端工程师需求的时候，我们应该发展出一个更好的语言。于是，ES 6 就这样诞生了。继上面的 JavaScript 的发展历史，现在主流浏览器都支持 ECMAScript 5.0 版本的标准，并且部分浏览器可以支持 ECMAScript 6。随后，ECMA 的草案以年份来命名，如 2016 年发布的 ECMAScript 草案称之为 ECMAScript 2016。而 ES 6 则对应于 ES 2015。于是，现在：你可以使用定义函数的默认参数。不再需要使用 option，并 merge 这个对象了。你可以使用模板对象，使用形如`$ {NAME}`的形式来拼接模板。不再需要在一个变量切换单引号 ' 和双引号 \"，并使用很多加号 + 。你可以使用箭头函数，来减少回调的代码量，并改善作用域 this 的问题。你可以使用原生的 Promises 来解决地狱式回调的问题。你还可以在 JavaScript 中使用真正的面向对象编程。。。。在最新的 Chrome、Edge、Safari、Firefox 浏览器里，它们对于 ES 6 的特性支持几乎都在 90% 以上。当我们需要在浏览器上运行 ES6 代码时，就需要使用类似于 Babel 这样的转译工具，来将代码转换为 ES5 来在普通浏览器上运行。遗憾的是，主流的浏览器对于 ES2016+ 以及下一代的 ES.next 的支持是有限的。除此，它还有一系列需改进的语法，并不能让我觉得满意。然后，我开始转向了 TypeScript。TypeScript我开始尝试 TypeScript 的原因是，ES 6 一直在变化。在 ES6 语言特性没有稳定下来的时候，我选择它作为技术栈总会存在一些风险。在这个时候，TypeScript 就成为了一个更好的选择——它创建得更早，并且语言特性稳定。而真正促使我使用 TypeScript 的契机则是，Angular 2 中采用了 TypeScript 作为开发语言。简单的来说，就是我需要用它，所以我才学 TypeScript 的。TypeScript 与其他编译为 JavaScript 的语言初衷是类似的，为了开发大规模 JavaScript 的应用。TypeScript 是 JavaScript 的严格超集，任何现有的JavaScript程序都是合法的TypeScript程序。TypeScript 第一次对外发布是在 2012 年 10 月，而在那之前在微软的内部已经开发了两年。因此，我们可以认为它是在 2010 年左右开始开发的。与同时期的 ES6 相比，它更加完善，并且更适合于大型应用开发。TypeScript 从其名字来看，就是 Type + Script，它是一个强类型的语言。而 ES6 只带有类型检查器，它无法保证类型是正确的。这一点在处理数据 API 时，显得非常具有优势。当接口发生一些变化时，这些 interface 就会告诉你哪些地方发生了变化。 并且未来 TypeScript 将会和 ECMAScript 建议的标准看齐。小结除去语言本身，还有各种新的前端框架带来的变化。和其他领域（如后台，APP等等）中的框架一样，有的框架可以用于开发中大型应用，有的框架则能让我们更好地完成开发。TC39 是负责 JavaScript 进化的委员会。TC39 定期举行会议，其会议是由成员公司（主要的浏览器厂商）派代表和特邀专家出席了会议。 ","updated":"T14:14:07.000Z","canComment":false,"commentPermission":"anyone","commentCount":21,"likeCount":72,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":true,"rating":"none","sourceUrl":"","publishedTime":"T22:14:07+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-b6fa7e168e5eb1120a1adf_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":21,"likesCount":72},"":{"title":"我的职业是前端工程师【四】：如何选择合适的前端框架，告别选择恐惧症","author":"phodal","content":"将 package.json 中的 Ionic 版本改为 2.0.0 的时候，我就思考一个问题。这个该死的问题是——我到底要用哪个框架继续工作下去。刚开始学习前端的时候，SPA（单页面应用）还没有现在这么流行，可以选择的框架也很少。而今天，我随便打开一个技术相关的网站、应用，只需要简单的看几页，就可以看到丰富的前端框架世界 Angular 2、React、Vue.js、Ember.js。当我还是一个新手程序员，我从不考虑技术选型的问题。因为不需要做技术选型、不需要更换架构的时候，便觉得框架丰富就让它丰富吧，反正我还是用现在的技术栈。等到真正需要用的时候，依靠之前的基础知识，我仍能很轻松地上手。可是一旦需要考虑选型的时候，真觉得天仿佛是要塌下来一般。选择 A 框架，则使用过 B 框架的可能会有些不满。选用 B 框架，则使用 A 框架的人会有些不满。选择一个过时的框架，则大部分的人都会不满。这点“小事”，也足够让你几天几夜睡不了一个好觉。前端的选择恐惧症年轻的程序员都是好奇的猫，玩过一个又一个的前端框架。从毛球上弄出一条条的线，玩啊玩，最后这一个个的框架在脑子里搅浆糊。技术选型：不仅仅受技术影响有太多的选择，就是一件麻烦的事；没有选择时，就是一件更麻烦的事；有唯一的选择时，事情就会变得超级简单。倘若，我是那个使用 Java 来开发 API 的少年，我会使用 Spring Boot 来作为开发框架。尽管 Java 是一门臃肿的语言，但保守的选择不会犯上大错。倘若，我是那个使用 Python 来开发 Web 应用的少年，我会使用 Django 来作为开发框架。它可以让我快速地开发出一个应用。只可惜，我不再是一个后台开发者，我不再像过去，可以直接、没有顾虑的选择。当我选择 JavaScript 时，我就犯上了「选择恐惧症」。技术选型也是没有银弹的——没有一个框架能解决所有的问题。在《Growth：全栈 Web 开发思想》一书中，我曾提到过影响技术选型的几个因素。这时，为了更好的考量不同的因素，你就需要列出重要的象限，如开发效率、团队喜好等等。并依此来决定，哪个框架更适合当前的团队和项目。即使，不考虑前端框架以外的因素，那么技术选型也是相当痛苦的一件事。上线时间影响框架每一个框架从诞生到受欢迎，都有其特定的原因和背景。不同的开发者选择时，也是依据于其特定情景下的原因和背景。如 Ruby On Rails诞生之时，带来了极大的开发效率，而开发效率正是当时大部分人的痛点。我们知道 Ruby On Rails 是一个大而广的框架，它可以提供开发者所需要的一切，开发者所需要做的就是实现业务代码。当开发效率不再是问题时，自由度变成了一些开发者的痛点，此时像 Sinatra 这样的微框架就受这些人欢迎。也因此，开发效率会在很大程度上影响技术选型。毕竟，开发效率在很大程度上决定了上线时间，上线时间很大地影响了技术选型。用几星期的时间来做一个网站，我首先想到的会是找一个模板。用几个月的时候来做一个网站，我仍然会想到找一个框架。用几个年的时间来做一个网站，我会想着是不是可以造几个轮子。遗憾的是，要遇到可以造轮子的项目不多。锤子定律：你需要更大的视野年轻的时候，学会了 A 框架，总觉得 Z 网站用 A 框架来实现会更好，一定不会像今天这样经常崩溃、出Bug。**时间一长，有时候就会发现，Z 网站使用 A 不合适，他们的问题并不是框架的问题，而是运维的问题。后来，出于对职业发展的探索，我开始了解咨询师，看到一本名为《咨询的奥秘》的书籍。在这其中，提到一个有意思的定律“锤子定律”（又称为工具定律）——圣诞节收到一把锤子的孩子，会发现所有东西都需要敲打。 出现这种情况的主要原因是，开发者对一个熟悉的工具过度的依赖。认真观察，就会发现这个现象随处可见。当一个新手程序员学会了某个最新的框架，通常来说这个框架有着更多的优点，这个时候最容易出现的想法是：替换现有的框架。可是，现有的框架并没有什么大的问题。并且凭估不充分时，新的框架则存在更多的风险。并且，对于某个熟悉工具的过度依赖，特别容易影响到技术决策——看不到更多的可能性。这时候，我们就需要头脑风暴。但是这种情况下，头脑风暴很难帮助解决问题。在这个时候，拥有更多项目、框架经验的人，可能会做出更好的选择。前端框架一览在这个复杂的前端框架世界里，我不敢自称是有丰富的徒刑经验。我只能去分享我用过的那些框架，读者们再结合其他不同的框架来做决定。jQuery, 使用生态解决问题jQuery 创立之初的主要目标是，简化 HTML 与 JavaScript 之间的操作，开发者可以轻松地使用 $('elment').doSomething() 的形式来对元素进行操作。诞生之后，由于其简单容易手、并且拥有丰富的插件，几度成为最受欢迎的前端框架。大部分动态交互效果，都能轻松地找到 jQuery 插件。即使，没有也能通过其 API，快速地编写相应的插件。在很多人看来，jQuery 似乎是一个不会在未来用到的框架。可惜到了今天（2017年），我仍然还在项目中使用 jQuery 框架。一年前，我们仍在一个流量巨大的搜索网站上使用用 jQuery。在这几个项目上，仍然使用 jQuery 的原因，大抵有：项目功能比较简单。并不需要做成一个单页面应用，就不需要 MV* 框架项目是一个遗留系统。与其使用其他框架来替换，不如留着以后重写项目所以，在互联网上仍有大量的网站在使用 jQuery。这些网站多数是 CMS（内容管理系统）、学校网站、政府机构的网站等等。对于这些以内容为主的网站来说，他们并不需要更好的用户体验，只需要能正确的显示内容即可。因此即使在今天，对于一般的 Web 应用来说，JavaScript 搭配 jQuery 生态下的插件就够用。然而，对于一些为用户提供服务的网站来说，前端就不是那么简单。Backbone.js，脊椎连接框架从 Ajax 出现的那时候开始，前端便迎来了一个新的天地。后来，智能手机开始流行开来。Web 便从桌面端往移动端发展，越来越多的公司开始制作移动应用（APP 和 移动网站）。jQuery Mobile 也诞生这个特殊的时候，然而开发起中大型应用就有些吃力。随后就诞生了 Backbone、Angular 等等的一系列框架。毕竟，作为一个程序员，如果我们觉得一个工具不顺手，那么应该造一个新的轮子。Backbone.js 是一个轻量级的前端框架，其编程范型大致上匹配MVC架构。它为应用程序提供了模型(models)、集合(collections)、视图(views)的结构。Backbone 的神奇之处在于，在可以结合不同的框架在一起使用。就像脊椎一样，连接上身体的各个部分。使用 Require.js 来管理依赖；使用 jQuery 来管理 DOM；使用 Mustache 来作为模板。它可以和当时流行的框架，很好地结合到一起。在今天看来，能结合其他前端框架，是一件非常难得的事。遗憾的是，Backbone.js 有一些的缺陷，使它无法满足复杂的前端应用，如 Model 模型比较简单，要处理好 View 比较复杂。除此，还有更新 DOM 带来的性能问题。Angular，一站式提高生产力与 Backbone 同一时代诞生的 Angular 便是一个大而全的 MVC 框架。在这个框架里，它提供了我们所需要的各种功能，如模块管理、双向绑定等等。它涵盖了开发中的各个层面，并且层与层之间都经过了精心调适。我们所需要做的便是遵循其设计思想，来一步步完善我们的应用。Angular.js 的创建理念是：即声明式编程应该用于构建用户界面以及编写软件构建，而命令式编程非常适合来表示业务逻辑。我开始使用 Angular.js 的原因是，我使用 Ionic 来创建混合应用。出于对制作移动应用的好奇，我创建了一个又一个的移动应用，也在这时学会了 Angular.js。对于我而言，选择合适的技术栈，远远比选择流行的技术栈要重要得多，这也是我喜欢使用 Ionic 的原因。当我们在制作一个应用，它对性能要求不是很高的时候，那么我们应该选择开发速度更快的技术栈。对于复杂的前端应用来说，基于 Angular.js 应用的运行效率，仍然有大量地改进空间。在应用运行的过程中，需要不断地操作 DOM，会造成明显的卡顿。对于 WebView 性能较差或早期的移动设备来说，这就是一个致命伤。幸运的是在 2016 年底，Angular 团队推出了 Angular 2，它使用 Zone.js 实现变化的自动检测、而迟来的 Angular 2 则受奥斯本效应的影响，逼得相当多的开发者们开始转向其它的框架。: 颇受欢迎的个人电脑厂商奥斯本，其公司的创新式便携电脑还没有上市，就宣布他们要推出的更高档的机器，而又迟迟无法交货，消费者闻风纷纷停止下单订购现有机种，最后导致奥斯本因收入枯竭而宣布破产。React，组件化提高复用从 Backbone 和 Angular.js 的性能问题上来看，我们会发现 DOM 是单页面应用急需改善的问题——主要是DOM 的操作非常慢。而在单页面应用中，我们又需要处理大量的 DOM，性能就更是问题了。于是，采用 Virtual DOM 的 React 的诞生，让那些饱受性能苦恼的开发者欢迎。传统的 DOM 操作是直接在 DOM 上操作的，当需要修改一系列元素中的值时，就会直接对 DOM 进行操作。而采用 Virtual DOM 则会对需要修改的 DOM 进行比较（DIFF），从而只选择需要修改的部分。也因此对于不需要大量修改 DOM 的应用来说，采用 Virtual DOM 并不会有优势。开发者就可以创建出可交互的 UI。除了编写应用时，不需要对 DOM 进行直接操作，提高了应用的性能。React 还有一个重要思想是组件化，即 UI 中的每个组件都是独立封装的。与此同时，由于这些组件独立于 HTML，使它们不仅仅可以运行在浏览器里，还能作为原生应用的组件来运行。同时，在 React 中还引入了 JSX 模板，即在 JS 中编写模板，还需要使用 ES 6。令人遗憾的是 React 只是一个 View 层，它是为了优化 DOM 的操作而诞生的。为了完成一个完整的应用，我们还需要路由库、执行单向流库、web API 调用库、测试库、依赖管理库等等，这简直是一场噩梦。因此为了完整搭建出一个完整的 React 项目，我们还需要做大量的额外工作。大量的人选择 React 还有一个原因是：React Native、React VR 等等，可以让 React 运行在不同的平台之上。我们还能通过 React 轻松编写出原生应用，还有 VR 应用。在看到 Angular 2 升级以及 React 复杂性的时候，我相信有相当多的开发者转而选择 Vue.js。Vue.js，简单也是提高效率引自官网的介绍，Vue.js 是一套构建用户界面的渐进式框架，专注于MVVM 模型的 ViewModel 层。Vue.js 不仅简单、容易上手、配置设施齐全，同时拥有中文文档。对于使用 Vue.js 的开发者来说，我们仍然可以使用 熟悉的 HTML 和 CSS 来编写代码。并且，Vue.js 也使用了 Virtual DOM、Reactive 及组件化的思想，可以让我们集中精力于编写应用，而不是应用的性能。对于没有 Angular 和 React 经验的团队，并且规模不大的前端项目来说，Vue.js 是一个非常好的选择。虽然 Vue.js 的生态与 React 相比虽然差上一截，但是配套设施还是相当齐全的，如 Vuex 、 VueRouter。只是，这些组件配套都由官方来提供、维护，甚至连 awesome-vue 也都是官方项目，总觉得有些奇怪。除此，Vue.js 中定义了相当多的规矩，这种风格似乎由 jQuery 时代遗留下来的。照着这些规矩来写代码，让人觉得有些不自在。和 React 相似的是，Vue.js 也有相应的 Native 方案 Weex，仍然值得我们期待。小结除了上面提到的这些前端框架，我还用过 Reactive、Ember.js、Mithril.js，遗憾的是同 Vue.js 一样，我没有在大一点的、正式项目上用过。也因此，我没有能力、经验、精力去做更详细的介绍。有兴趣的读者，可以做更详细的了解，也可以在 GitHub () 上给我们提交一个 Pull Request。总结今天，大部分的框架并不只是那么简单。为了使用这个框架你，可能需要学习更多的框架、知识、理论。一个很好的例子就是 React，这个框架的开发人员，引入了相当多的概念，JSX、VIrtual Dom。而为了更好地使用 React 来开发，我们还需要引入其他框架，如 Redux、ES6 等等的内容。这些框架从思想上存在一些差异，但是它们都有相似之处，如组件化、MV**、All in JS、模板引擎等等。欲知后事如何，请期待每周一更的《我的职业是前端工程师》：。","updated":"T00:33:08.000Z","canComment":false,"commentPermission":"anyone","commentCount":11,"likeCount":54,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"T08:33:08+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-482d3b857a551fbaed438e621ac51093_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":11,"likesCount":54},"":{"title":"我的职业是前端工程师【五】: 前端工程师必会的六个调试技能","author":"phodal","content":"我还是一个野生程序员的时候，不会 Debug，只会傻傻地写一句句 std::count。即使是在今天，有些时候我也会这样做：打一个 console.log，然后看看结果是不是和预期的一样。如果不是和预期一样，就修改一下代码，刷新一下浏览器。这得亏是 JavaScript 是一门动态语言，可以很快的看到运行的结果。前言： 本章里，主要介绍如何调试前端应用——基本的调试： HTML、CSS 和 JavaScript；使用网络工具对 API 进行测试；对移动设备进行调试：使用浏览器的模拟器、真机、iOS 模拟；对网站的性能进行调试等内容。调试（Debug）在维基百科上的定义是：是发现和减少计算机程序或电子仪器设备中程序错误的一个过程。多数时候，调试是为了找到代码中的错误，并具体定位到错误的地方。幸运的是，现在的前端框架都比较人性化了，可以和大部分的后台框架一样，提示代码中出错的地方。这时，我们只需要借助于浏览器的调试，找到错误的行数，并查看错误的原因。有些时候，我们调试是为下一步编程，提供一些理论依据。如在应用运行的时候，我们可以使用浏览器打个断点，并在 Console 中输入代码调试下一步要做的事。最后，再将这些代码复制到 IDE 或者编辑器上即可。我的调试入门与我的编程经验相比，我学会 Debug 的时间比较晚。我是在大学里学会 Debug 的，当时在为一个支持在线调试的芯片写程序。对于嵌入式开发而言，不同的芯片都会有不同的 IDE。有的 IDE 可以支持调试，有的则不行；有的 IDE 则连基本的语法高亮都没有。对于支持在线调试的开发环境来说，我们只需要打一两个断点，看程序是否运行到这个逻辑，又或者是按下“下一步”按钮，看程序运行到哪些地方，并实时的预览变量的值。对于不支持在线调试的芯片来说，没有屏幕也就不能使用 printf 来输出结果。只能通过 SD 卡里的文件系统来写入日记，再计算机上读取日记来分析。这只的是一件麻烦的事，对于没有 SD 卡的开发板来说，还需要腾出几个脚本接上 SD 卡。也有些芯片是不能使用 SD 卡的，这时我们就只能依靠于想象力来调试。在今天开发 Web 应用时，上述的内容都只是基本的调试。有一些能支持更高级的调试——如评估表达式，即利用当前的变量值，来实时计算，并慢慢完成下一步的代码。最初，我是在用 Intellij Idea 写程序的时候，学会在后台编程时使用 evaluate expression。它可以在调度代码的时候，我们可以边实现功能。后来，我才醒悟到在前端领域，这是基本的调试功能，在 Chrome、Safari 这些现代的浏览器上都能这样做。与一般的单机应用相比，让 Web 应用不能如期运行有更多的原因。并且相当多的原因与代码无关，如：服务在运行中崩溃，没有向前端返回数据，前端只能使用超时来处理。这时，我们可以通过浏览器中的 Network 来知道这件事。本地开发的时候，URL 的编码都是没有问题的，而在线上则出了问题。经过一系列复现和排察后，才发现问题出在 Nginx 上的转义上。等等这时，我们就需要使用更好的工具来帮助开发。基本调试技巧：实时调试开始之前，我们需要打开 Chrome 浏览器的调试窗口。除了点鼠标右键，然后选择“审查元素”之外，还可以：Windows / Linux 操作系统，使用 Ctrl + Shift + I 快捷键打开开发人员工具Mac OS 操作系统，使用 Comand + Option + I 快捷键打开开发人员工具这个调试窗口看上去，有点高大上：图中左上角的两个图标，分别是：审查元素。可以让我们检查页面上的 DOM 元素，了解 DOM 结构设备工具栏开关。在设备工具栏里，可以模拟不同的移动设备屏幕、网络状态等等的内容。随后就是各类工具了，让我们在随后的内容里慢慢欣赏。而在平时的工作中，前端工程师用得最多的就是调试样式和代码了，这些也是作为一个前端程序员必须要掌握的。实时调试样式作为一个有经验的前端程序员，当我们开发前端界面时，都会：在浏览器上编写 CSS 和 HTML将编写好的 CSS 和 HTML 复制到代码中重新加载页面，看修改完的页面是否正确如果不正确，重复 1~3而当我们想查看页面上某个元素的 DOM 结构或者 CSS 时，我们可以点击开发者工具中的 Inspect 图标，并在页面上选择相应的元素。我们还可以使用快捷键来选择元素，Windows / Linux上使用 Shift + Ctrl + C，Mac OS 上使用 Command + Shift + C。如下图所示：我们还会发现工具栏中的 Elements 菜单自动被选上了，这是因为我们要选择的元素是属于 Elements 下的。也因此，还可以在 Elements 中选择 HTML代码，查看它在页面上的位置。它们两者是互相对应的，当我们选择一个元素时，会自动为我们选择相应的元素。编码时，可以在左侧的“元素区”编辑 HTML，右侧的区域的“Styles”可以查看元素的样式，“Computed”可以查看元素的拿模型，“Event Listeners”则可以查看元素的监听事件，等等的内容。由于 CSS 样式存在一定的优化级，如：元素选择器选择越精确，优化级越高相同类型选择器制定的样式，越靠后的优先级越高因而在复杂的前端项目里，我们看到右侧的样式区域特别复杂，一层嵌套一层，如上图中的右侧区域。有些时候，是因为我们想共用一些样式；有些时候，是因为在修改时，我们担心影响其他区域，而使用更精确的选择器。不幸的是，在一些早期的代码里，我们还会看到在很多的地方里写了 !important这样的代码。实时调试代码与静态语言相比，JavaScript的调试就相对比较简单一些，我们可以在运行的时候调试代码。只需要在浏览器的相就部分打个断点，再执行相应的操作，就可以等代码掉到这个坑里。如下是 Chrome 浏览器进行代码调试时的截图：从工具栏中的 Sources 就可以进行到这个界面。左侧的部分会显示当前页面的代码及资源，如 HTML、CSS、JavaScript，还有图片等。这些内容都是由当前页面的 html 加载来决定的，如果是单页面应用，则会是所有的资源。如上图所示，调试时，我们只需要：选择相应的源码文件在中间区域在相应的行数上打上断点再刷新页面就可以进入调试这时，我们只需要将光标，移动到正在调试的变量上，就可以实时预览这个值。我们还能在 Console 里对这些值进行实时的处理，当业务逻辑比较复杂时，这个功能就特别有帮助——实时的编写代码。移动设备调试从几年前开始，越来越多的公司将 Mobile First 作为第一优先级的技术转型。这时对于前端而言，我们需要响应式设计，我们需要处理不同的分辨率，我们需要处理不同的操作系统，我们需要编写更多的代码，以及见证更多的 Bug 诞生。越来越多的移动端功能需要开发时，能提供好的开发体验的工具就会越受欢迎，于是各个浏览器产商就提供了更好的移动开发功能：可以在浏览器上模拟真机的分辨率、User Agent 等等基本的信息提供接口来连接真机，并允许开发者在上面进行调试。在浏览器上模拟的特点是，我们可以一次开发匹配多种分辨率的设备，但是并不能发现一些真机才存在的 Bug——如 Android 设备的后退键。而真机的缺点则是，需要一个个设备的进行调试。因此，理想的开发模式是：先在浏览器进行响应式设计，随后在真机上进行测试。模拟真机：设备模拟器为了适配不同分配率的移动设备时，我们会使用 media query 进行响应式设计。并制定出一些屏幕的分辨率，并以此来区分三种类型的设备：计算机、平板、手机，如针对于计算机的像素应该是大于 1024 的。屏幕大小只是用来判断的一部分依据，还有一部分是通过 User Agent。它包含客户端浏览器的相关信息，如所使用的操作系统及版本、CPU 类型、浏览器及版本、浏览器渲染引擎等等。如下是我使用浏览器时，浏览器发出的 User Agent：Mozilla/5.0 (L Android 6.0; Nexus 5 Build/MRA58N)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87Mobile Safari/537.36\n那么，我们就可以根据这些信息，最终确定设备是桌面设备，还是移动设备，是 Android 手机，还是 iOS 手机。我们所需要的就是，打开开发者工具，然后选择图标中的设备工具栏，就有如下的图：在使用它进行调试时，我们可以自定义屏幕大小，也可以选择一些主流的设备进行响应式设计，如iPhone。除此，我们还能测试不同的网络环境，如 4G、2G 的下载速度，又或者是离线情况下使用。如果我们只是适配不同的设备屏幕，那么我们使用这个工具就够了。而当我们需要做一些设备相关的逻辑时，我们还需要使用真机来进行调试。真机调试：Device Inspect过去的很长一段时间里，我一直都不需要真机调试这种功能——因为只是进行响应式设计。当我们在项目上遇到一系列关于 Android 返回键的 Bug 时，我们就不得不使用设备进行调试。对于移动单页面应用来说，我们需要创建一系列的 UI、事件和行为。理论上，我们需要保证用户可以在全屏的情况下，像一个移动应用一样运行。除了一般应用的功能，我们还需要在页面上创建返回键来返回到上一个页面。这时，难免的我们就需要处理 Android 设备上的这种 Bug。于是，我们需要：判断设备是不是 Android 设备判断按下的是设备上的返回键，而不是浏览器上的返回如果是设备上的返回键，则进行特殊处理，避免用户退出应用这时我们就需要连接上真机，并在浏览器上打开 chrome://inspect/，进入移动设备的调试界面，并在手机 Chrome 浏览器上敲入要调试的网址：https://phodal.github.io/motree/随后，我们就可以像在桌面浏览器的调试一样，对代码进行调试。同理，对于 Safari 浏览器来说也是类似的。除此，Safari 浏览器可以支持更有意思的调试，如果正在开发的应用是混合应用，Safari 也可以对此进行调试。开发混合应用时，我们往往会遇到一些奇怪的 Bug，这时我们就需要它了。网络调试在前后端 Web 应用开发的初期，前后端进行交互是一种痛苦的事，会遇到各种意味之外的错误。我们需要查看参数传递过程中是否漏传了，是否传入了一些错误的值，是否是跨域问题等等。网络调试Chrome 里的开发者工具中的 Network 不仅可以查看页面的加速速度，还可以看我们发出的请求的详细信息、返回结果的详细信息，以及我们发送给服务端的数据。如下图所示：在图里，我们可以清晰地看到请求的 URL、返回的状态码，它可以让我们知道发出的请求是对的、返回的状态也是对的。如果我们发出的请求是对的，而返回的内容是错的，那么我们可以相信这是服务端的错误。如果返回的状态码是错的，我们也可以看出到底是服务端的错误，还是客户端的错误。设计表单时，我们可以看到它发出的参数是否是正确的。这一来一往，我们就知道到底是哪个地方的问题。使用插件除了上面说到的工具，我们还可以在 Chrome 应用商店里找到更多、更合适的工具。我在我的 GitHub 上维护了，我常用的一些工具：/phodal/toolbox，我整理了平时使用的插件在上面。让我推荐两个简单的工具，一个是 Postman，用于调试 API 用的：还有一个是 Google 的 Page Speed，可以帮助我们优化网络：小结在这一章里介绍了使用 Chrome 浏览器来调试的工具，这些在前端工程师的日常开发中非常有用。除此，在 Chrome 浏览器里还有一些额外的功能可以使用。如在 “Application”菜单栏中，我们可以看到与应用相关的一些缓存和存储信息。Chrome 浏览器里，我们可以看到 Local Storage、Cookies、Session Storage、IndexedDB、Web SQL 等等的用于数据存储的工具。编写单页面应用时，我们都需要在客户端存储一些数据，这时就需要用到这个工具。除此，还有 Google PWA 应用的一些相关属性，Manifest、Service Workers。在 GitHub 上可阅读最新内容：","updated":"T12:23:53.000Z","canComment":false,"commentPermission":"anyone","commentCount":11,"likeCount":164,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"T20:23:53+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-a029a2a2d378cd44dca84965da07bebc_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":11,"likesCount":164},"":{"title":"我的职业是前端工程师【六】：前端程序员如何有效地提高自己","author":"phodal","content":"要成为一个优秀的前端工程师，需要什么技能和学习？答案：练习在逛知乎、SegmentFault 又或者是相似的技术社区，我们总会看到类似的问题。新手总会关注于，需要怎样的技能，怎么才能入门？有一点经验的程序员则是，需要练习什么？如若一个程序员已经懂得问题的关键是，编程需要大量的练习。那么，我想这个程序员已经入了这个行道了。在我成为所谓的『前端工程师』之前，我没有想到会变成这样的结果。前端项目的练习过程年少的时候，想要做的是 Kernel Hacker。大学时，我做点前端相关的兼职，顺便赚钱点钱。再用这点钱，买点硬件做一些底层、低级的编程，带着去实验室，拿着电洛铁，高喊着：让我们来做一个毁灭世界的机器人。好在，后来我离这个行当有点远，要不这个