程序员,都去写一写前端代码吧

标签: JavaScript Recommended 前端 | 发表时间:2013-01-19 01:10 | 作者:四火
出处:http://www.raychase.net

文章系本人原创,转载请保持完整性并注明出自 《四火的唠叨》

程序员,都去写一写前端代码吧 你可以认为我是一个极端的人,就像有许多人专注于自己的领域而不屑于其它“肤浅”的工作范畴一样。比如我见过不少认为做portal没有技术含量的判定,做工程都是充满苦逼行为的言论,最近则还有那些“大数据”崇拜者的疯狂吐槽……我的极端则有些不同,我的极端在于我认为绝大多数优秀的程序员,都要尝试多方面的事情。并不只有底层开发或者机器学习充满睿智的挑战,我做了几年网站,很难说这就是我最初的兴趣,虽然也在接触和学习其他的领域,但是依然觉得,做网站仍旧充满挑战,互联网真是一个奇葩充斥的地方。

前端开发,则是这“多方面的事情”中的一个重要方面。潜心尝试过的人兴许会有这样的体会,这是一片崭新的世界,无论是理念、技巧,都有一种新鲜的感觉。如果你还没有尝试过,相信我,它会丰富你的视野,至少在设计和编码上,你会有崭新的认识。

JavaScript代码是存在诸多天生缺陷的,你可以找得到 太多它的替代品和改进品。另一方面,它确实给了程序员很少的限制——如果你写过perl代码,你大概也深有体会,什么样的代码是自由的代码,什么样的代码是 充满诗意的代码。与之相对的大概是语法严格的Java代码,就像老实、规矩的孩子,他不会带给你多少破坏性,但是也没法带给你丰盈的代码美感。但是JavaScript有N多类库,有足够活跃的语法自由度,有eval和prototype,还有那些动态语言的特性,你可以写出许多飘逸的代码。

另一方面,代码的自由一定带来代码层面规划和解耦的艺术。如果代码还处在漫山遍野全局var和全局function的温饱阶段,那么肯定是无法感受到这一点的,而且在这个阶段也根本称不上会写JavaScript代码。有许多人说前端开发简单,如果只是把它理解成为“好上手”,或者说alert一个字符串,改变一个div的颜色,那它还真是太好学了。再加上CSS的方便和简陋性让它连编程语言都算不上,而HTML又是容错性非常强的标记语言,所以你可以很容易写出能看到效果的界面来。

写一个UI稍微复杂一点的产品代码,就会无比地感受到规划和解耦的力量。无论是HTML、CSS还是JavaScript,变量或者对象都是极易被污染的,“模块化”显得举足轻重。在Java的世界里,你的武器很少,包、类、加载器又在你无意识的时候把这些繁琐的模块化的工作轻易化简完成了。但是写前端代码的时候你发现需要自己去考虑了,比如页面的分块布局、CSS的继承树、JavaScript的绑定和匿名函数,还有那么多开源的库来帮助完成模块化。

前端开发还可以帮助你成为最懂产品UI的程序员。程序员容易陷入使用各种技术去纠结实现的泥潭,但是却忽略了清晰、合理的用户需求。你写的界面,是要去帮助用户解决问题的,无论是布局设计、配色还是行为回馈,都会始终帮助你专注于用户的实际操作。会写前端代码,可以帮助你容易地和用户沟通,快速地做出界面原型,这比多少页胶片都强。少招一点美工和UI设计师,试着自己去设计界面,自己去切图和写样式,这些事情并没有那么困难,更何况还有Bootstrap呢。:)

前端开发的过程中,你还可以感受到最快速的成就感和回馈。只需要一个浏览器,一个代码高亮的文本编辑器,好吧,也许你还需要一点帮助调试的小工具。这就足够了,不用纠结在编译执行的过程,等待着应用的重启,不住地咒骂环境部署的繁琐。现在,你可以专注到你的代码设计和编写上。

前端开发应当成为工程师工具包中重要的一项工具。中国的程序员普遍“engineering”技巧丰富,学术领域显得差一些,但这并不代表工程技巧缺乏价值。举例来说,你可以做出任何有意思、有价值的东西,如果你会写前端代码,可以自己做网站,你就可以不需要别人帮助,自己完成整个端到端的过程,不管它是指你上线一个产品还是展示你的伟大成果。你真的可以独当一面。这也契合我所说的,程序员要做各方面的事情。

最后提醒一句,初涉前端开发,学习的材料很重要。就像VB会害了那些程序员新手一样(而且这一害就会影响很多年),前端的代码实在是太容易写烂掉了,需要筛选。

PS:看一看这个 编程语言转换矩阵,就知道JavaScript有多大威力(图片来自微博@程序员的那些事):

程序员,都去写一写前端代码吧

文章系本人原创,转载请保持完整性并注明出自 《四火的唠叨》

分享到:
你可能也喜欢:

相关 [程序员 前端 代码] 推荐:

程序员,都去写一写前端代码吧

- - 四火的唠叨
文章系本人原创,转载请保持完整性并注明出自 《四火的唠叨》. 你可以认为我是一个极端的人,就像有许多人专注于自己的领域而不屑于其它“肤浅”的工作范畴一样. 比如我见过不少认为做portal没有技术含量的判定,做工程都是充满苦逼行为的言论,最近则还有那些“大数据”崇拜者的疯狂吐槽……我的极端则有些不同,我的极端在于我认为绝大多数优秀的程序员,都要尝试多方面的事情.

前端代码规范

- - Web前端 - ITeye博客
1 结构、样式、行为三层分离;. 2 采用统一的缩进(两个或四个空格/Tab);. 3 嵌套标签应当缩进一次,必须合理嵌套;. 4 HTML页面必须包含文档类型声明,采用HTML5文档类型声明;. 5 CSS样式全部采用外链的方式在标签中引入;禁用行内样式,复用已有的样式规则;. 6 所有标签和属性名称必须小写,标签的属性值全部使用双引号,不采用属性简写方式;.

强制程序员使用统一的代码格式,好吗?

- - TECH2IPO创见
Java程序员Stijn Geukens与其他10位程序员一起为企业开发产品,但是他们11个人每个人都有自己喜好的编程平台,语言编写起来也是千奇百怪. 不过,这种情况很快就会发生变化,因为企业即将强制要求所有的程序员使用统一代码格式,统一使用Eclipse Java平台. 于是Stijn Geukens便在Stackexchange上 提问,“这样的强制要求是否值得.

IBM新专利:通过代码提交评判程序员

- - 奶味网-IT人- 最新RSS订阅
新闻来源:Slashdot. 觉得老板只需要用软件扫描一下你提交的代码就能判断你的工作效率进而决定解雇还是留下你这种事情怎么样. 这不是幻想 - 这是 IBM 最近披露的最新专利申请的内容. IBM 称, 对一名开发者的代码提交以及其他操作的统计可以用来产生一份用于同其他人比较的 "总结报告", 从而帮助管理层避免在低效率的程序员身上浪费时间.

[译]程序员要学会读源代码

- - 呦呦鹿鸣
在“沟通”这个复杂的领域里,写出能让人类领会并理解的连贯段落比敲出几行让解释器或编译器不致于“呕吐”的软件代码要难得多. 这就是为什么——就软件开发而言——所有的文档大概都是很差劲的. 而且,由于为人写作比为机器写作要困难得多,文档恐怕在可预见的将来还会继续差劲下去. 译者注:卢克(Luke Skywalker)是电影《星球大战》中的一个角色,他来自塔图因星球,在发现了莉雅公主输入到机器人R2-D2中的求救信息后,他与绝地骑士欧比旺一起迎战邪恶的银河帝国,最终救出了公主.

程序员的成长和代码行数的关系

- - 外刊IT评论
Cook写了一篇 博客,其中提到:. 我的朋友Clift Norris发现了一个基本常数,我称之为Norris常数,一个未经培训的程序员在他或她遇到瓶颈之前能写出的平均代码量. Clift估计这个值是1500行. 超过这个数以后,代码会变得如此混乱,以至于本人都无法轻而易举的进行调试和修改. 我还不了解足够多的初级程序员来验证这一结果,不过我自己认识到,程序员生涯的下一个瓶颈将发生在20,000行.

优秀程序员眼中的整洁代码

- - 博客园_知识库
  有多少程序员,就有多少定义. 所以我只询问了一些非常知名且经验丰富的程序员.   Bjarne Stroustrup,C++语言发明者,C++ Programming Language(中译版《C++程序设计语言》)一书作者. 代码逻辑应当直截了当,叫缺陷难以隐藏;尽量减少依赖关系,使之便于维护;依据某种分层战略完善错误处理代码;性能调至最优,省得引诱别人做没规矩的优化,搞出一堆混乱来.

程序员新人怎样在复杂代码中找 bug?

- - IT瘾-geek
我曾经做了两年大型软件的维护工作,那个项目有10多年了,大约3000万行以上的代码,参与过开发的有数千人,代码checkout出来有大约5个GB,而且bug特别多,open的有上千,即使最高优先级的showstopper也有上百. 优先解决那些可重现的,可重现的bug特别好找,反复调试测试就好了,先把好解决的干掉,这样最节约时间.

无代码开发,站到了程序员鄙视链顶端

- - InfoQ推荐
“无代码”不是在“淘汰”开发者,而是给予开发者更大挑战、更多机会. 疫情进一步推动了“无代码”行业的爆发. 微软称无代码是它的“Next Big Thing”,谷歌说无代码是下一代的变革和提升. 也有越来越多的企业开始进入“无代码”领域. 所谓“无代码”,并不是“不存在代码”,无代码平台的开发对后台的支撑能力提出了更高的要求,需要更为强大的技术团队.

为什么每个程序员都应该学习代码编译器知识

- - 外刊IT评论
所有优秀的计算机科学学院都提供了编译器课程,但是相对比较少的学校把它作为本科课程的必修部分. 这篇文章回答了这个问题:为什么需要学习编译器知识. 我写这篇文章的其中一个原因是,尽管我在读本科时很喜欢编译器课程,但是我几乎看不到它的实际作用. 大多数资料看起来要么简单易懂,要么很深奥(事实上,我找到的大部分编译器资料都是很枯燥的.