原文链接:http://rmurphey.com/blog/2012/04/12/a-baseline-for-front-end-developers/
前几天我为一个项目写README文档,我希望其他开发者能够看到这个项目,并从中学到一些东西。突然我意识到,若放在几年前,我写作的过程中随口提到的Node,pnm,Homebrew,git,测试还有产品构建,会把我魂都吓没了。
曾经有段时间,一个前端开工程师基本的工作流程是:编辑文件,本地测试下(尽我们可能做到最好),然后通过FTP上传到服务器。我们评价一个前端工 程师的水平,是通过他是否能够兼容IE6,或者取得跨浏览器的像素级的一致。很多社区的成员——包括我在内——缺少传统的编程经验。HTML、CSS和 JavaScript——通常指jQuery——是自学的技能。
这些事情在过去的几年里发生了变化。可能是因为大家开始认真的看待前端开发者的工作,或者是因为浏览器开发商开始臭味相投(趋向一致?原句 getting their shit together),又或者是前端开发者自己——同样,包括我在内——开始看到软件开发变得完善的曙光。
不管怎么说,我们看到前端开发的重点,从繁琐转向了重视工具化。想要成为一名成功的前端开发者,你需要掌握一套新的基础技能,而不满足要求的前端开发者会感觉到落后越来越多,而那些正在分享他们知识的工程师们觉得这些事情是自然而然的。
下面提到的一些内容是我希望人们能够熟悉的,除此之外还有一些相关的资源,如果你觉得你需要在成长的道路上加速的话。(感谢Paul Irish,Mike Taylor,Angus Croll,以及Vlad Fillppov的贡献)
JavaScript
这个不用多说,但仅仅知道一个javascript库再也不够了。我并不是说你需要知道如何用原生的JavaScript实现一个 JavaScript库的所有特性,但你需要知道,什么时候的确需要用库,同时,在不需要用库的时候,有能力用简单而古老的JavaScript完成你的 工作。
这意味着,你已经读过《JavaScript语言精粹》—— 希望不止一次。你理解像对象、数组这样的数据结构;函数,包括如何、为什么你需要~call
和apply
他们;掌握原型继承;掌握javascript的异步操作。
如果你的原生JS比较弱,这里有一些资源可以帮到你:
- 《JavaScript编程精解》:一本可以带你回归JavaScript基础的书,挺不错的(有纸质版的)
- 《测试驱动的JS评价》:一系列失败测试,它们覆盖了不同的JavaScript主题;你能够编写让测试通过的代码吗?
- 《我从jQuery源码中学到的10点》:Paul Irish给我们带来的礼物,虽然比较旧,但的确不错,它让我们知道从阅读他人的代码中所能学到的东西。
Git(还有一个Github账户)
如果你没访问过Github,你绝对无法参与到这个资源丰富的开源社区中来,它已经在前端开发技术领域呈现欣欣向荣之势。克隆一个分支然后跑一下应该成为你的习惯,同时你需要知道在多人协作的项目中如何使用分支。
需要提升你的git
技能?
模块化,依赖管理,产品构建
通过在页面塞几个script或style标签来管理依赖的日子已经一去不复返了。即使你还没能能够将RequireJS引入你的工作流程中去,也应该找时间在自己的个人项目,或像Backbone Boilerplate这样的项目里试下它,因为它能给我们带来许多好处。RequireJS能够让你开发的JS、CSS文件保持模块化、粒度足够细,而在产品上线前可以通过配套的优化工具进行文件压缩、合并。
AMD听起来很吓人?再也没有借口什么也不干了。至少,你应该知道存在像UglifyJS、Closure Compiler这样的工具,它们能够在你的产品上线前,对你的代码进行智能压缩和合并。
如果你还在写原生的CSS —— 也就是说,目前没有用像Sass或者Stylus这样的CSS预处理器 —— RereireJS也能够帮你保持你的CSS文件模块化。在一个基础样式文件里使用@import
声明来加载相关依赖文件,然后对这个基础文件运行ReqireJS Optimizer来构建实际生产环境所要用到的文件。
浏览器内置开发者工具
在过去的几年里,基于浏览器的开发工具已经大大得到了提升,如果你知道怎么利用好它们的话,它们能够大大提高你的开发体验。(提示:如果你还在使用alert
调试代码的话,你会浪费很多时间)
你或许需要确定一款浏览器,你主要使用它的开发者工具 —— 近来我比较倾向于使用Google Chrome开发者工具 —— 但不要立即抛弃其他浏览器的开发者工具,因为他们经常会根据开发者的反馈来添加有用的特性。特别值得一提的是,Opera的Dragonfly的某些功能让它的开发者工具与众不同,比如(尚在实验中的)CSS分析器,可用户自定义的键盘快捷键,无需USB连接的远程调试,以及能够保存并使用自定义的调色板。
命令行
说到命令行,适应它(being comfortable with it)再也不是可选项了——如果你没有准备好坐到终端窗口前,并亲自动手敲命令行的话,你一路上会错过非常多的东西。我并不是说你必须在终端上完成所有事 情——我不会抢走你的git GUI(图形化用户操作界面),虽然我的确觉得最终你离开它会更好——但不管做什么项目,你最好一直开着你的命令行终端。下面几个命令行任务是你必须不假 思索就必须能够完成的:
ssh
登录另一台机器或服务器scp
拷贝文件到另一台机器或服务器ack
或者grep
找到文件名包含某个字符串或符合某种模式的文件find
定位文件名符合某种模式的文件git
至少能够用它完成如下事情:add
,commit
,status
和pull
brew
通过Homebrew 来安装文件npm
安装Node包gem
安装Ruby包
如果有些命令你用得比较多,你可以编辑.bashrc
或者.profile
或者.zshrc
或者其他,然后创建alias,这样你就不用像之前那样敲很多字符。你也可以添加alias到你的~/.gitconfig
文件里。Gianni Chiappetta的dofiles是个不错的范例。
注意:如果你在Windows上开发,我不知道如何帮助你,除了建议使用Cygwin。在Windows上参与前端开源社区的活动比较麻烦,当然我说的不一定正确。相反的,MacBook Air便宜、强大,而且不可思议地便携,而且总是会有Ubuntu或者各种*nix。
前端模板
在不久之前,对于前端的XHR请求,服务器典型的应答方式是返回一段HTML文本。但在过去的12到18个月间,前端开发社区看到了曙光,要求服务端返回单纯的数据。将数据转成HTML是件麻烦的事情,如果处理得不好的话,可维护性会相当糟糕。这就是前端模版库诞生的目的:你仅需要维护一套模板,在需要的时候提供数据,就能够将模板转换成HTML。在模板库的选择上需要帮助?Garann Mean的template chooser能够给你指明方向。
CSS预处理器
Paul Irish前些天注意到,前端开发者编写的代码,跟最终在生产环境部署的差别开始变得很大。通过CSS预处理器写出来的代码就是很好的例子。仍然有不少人坚持说原生的CSS才是唯一的出路,但它们离我们越来越近(but they are starting to come around)。这些工具提供了一些CSS属性按理来说早就该有的特性,包括——变量、数学运算、逻辑、混合(mixin),它们能够帮你从一堆冗余的特性前缀中解放出来。
测试
编写模块化、松耦合代码的乐趣之一就是,你的代码变得很容测试。如果你用了Grunt这样的工具,创建一个包含测试用例的项目再简单不过了。虽然Grunt集成了QUnit,但是还有许多测框架供你选择——Jasmine和Mocha是我喜欢的两个测试框架——框架的选择取决于你的个人偏好,以及你项目的结构(the mark up of the rest of your stack)。
如果你的代码是模块化、松耦合的,测试是件有趣的事情。然而,对于那些组织糟糕的代码,测试不单困难,有时甚至不可能的。换句话说,强迫自己编写测 试用例——甚至可能在你正式编码之前——有助于帮你理清你的思路以及你的代码组织。后续当你重构你的代码的时候,它也能让你充满自信。
流程自动化(rake/make/grunt/其他)
流程自动化的一个例子:通过Grunt创建内置单元测试的项目。前端开发的现状是,我们有一大堆重复性的工作需要做,但有个朋友曾经告诉我,一个好的开发者是个“懒惰”的开发者:首要的一点是,如果你发现自己做同一件同样的事件超过三次,那么是时候将它变成自动化的。
像make这样的工具已经存在很长一段时间,主要用来帮我们解决上述问题,但也有类似rake
、grunt
以 及其他类似的工具。如果你想把跟需要跟文件系统打交道的任务变成自动化,学习一门JavaScript以外的语言非常有帮助,因为当你仅仅想要处理文件 时,Node的异步特性会让事情变得更加麻烦。也有许多针对特定任务的自动化工具——部署,构建,代码质量保证,还有其他。
代码质量
如果你曾经被缺失分号,或多一个逗号这样的问题困扰过, 你就知道这样小的代码缺陷可以浪费你多少时间。这就是为什么你正在类似JSHint这样的工具里运行你的代码,没错吧?它不仅可配置,而且有很多方式可以将它集成到你的编辑器或构建流程中去。
好的参考手册
唉,没有针对前端开发的手册,但MDN触手可及。好的前端开发者会在任何搜索查询里加上mdn前缀,比如mdn javascript arrays
,避免搜到像w3schools那样的盈利性组织的内容。
结尾
阅读上面这些东西没办法让你成为一个专家,哪怕是变得更有经验些——在某件事情上做得更好的唯一途径就是做那件事。祝你好运。