十日谈,第一日:初尝禁果 #1

Open
jayli opened this Issue Apr 4, 2013 · 1 comment

Projects

None yet

2 participants

@jayli
Owner
jayli commented Apr 4, 2013

@2014.7.23,这是我2012年写的文章,两年时间过去了,重读后依然体会到当年的冲动,只是如今这味道被冲淡许多,真真让人感慨。现在看来,前九日的好多观点太自我,也有不少偏激的文字,也误导了很多人,实在不应该,我再将前九日的文字整理出摘要,大家辩证的阅读!


索引

  • #1 第一日:初尝禁果
  • #2 第二日:科班秀才
  • #3 第三日:幸福感 和 归属感
  • #4 第四日:架构 和 伪架构
  • #5 第五日:寻找突破
  • #6 第六日:码农的宿命
  • #7 第七日:伯乐与千里马
  • #8 第八日:做地球上最好的UED
  • #9 第九日:前端技术体系
  • #10 第十日:未来已来

4ec2d5628535e5ddca46cb4876c6a7efce1b623a

第一日:初尝禁果

引言

一直想写这篇“十日谈”,聊聊我对Web前端开发的体会,我不打算聊太多技术,我想,通过技术的历练,得到的反思应当更重要。

我是一名“初级”前端开发工程师,一则入道尚浅,毕业四年,二则我自知对技术的钻研不够,可能是环境的原因,当然最重要的是,我幸运的赶上了互联网崛起的浪潮之巅。时势造就了一批技能薄弱但备受追捧的“弄潮者”,这极大的影响了我们对“技术本质”的洞察力,同时一直未有成体系的“前端技术”布道著作,以至于多数人对前端技术的了解,盖始于表述并不严谨的岗位招聘描述,而这正恰恰反映了Web前端开发对自身的模糊定位。对于很多FE新手来说,初尝禁果的快感无法持续很久,很快就面临重择职业道路,试图寻找到方向、看清瓶颈,寻找突破。遗憾的是,Web前端技术被广泛接纳时日尚短,没有多少励志的成功样板。然而情况不总是这么糟,毕竟Web前端技术是一门“技术”,和计算机科学系出同门,只是因为互联网的高速崛起而让我们傻傻看不清时局。

那么,如何定义Web前端技术职责边界?Web前端技术的价值体现在何处?前端工程师如何“打怪升级”?当前“我”处在什么位置?接下来的路应怎样走?何谓前端技术之“道”?我的观点可能有些偏激,但抛砖引玉,读者权且把这些言论当作一个引子吧。

上帝说:“要有光!”便有了光

万物生灵、阳光雨露盖源于造物之初的天工开物,我们无法想象上帝创造光明之前的世界模样。但幸运的是,前端开发没有神祗般的诡魅。这个技术工种的孕育、定型、发展自有轨迹,在杨致远和费罗在斯坦福大学的机房里撺掇出Yahoo!时,Web前端技术就开始进入公众视野,只不过当时没有一个响亮的名字。从那时起,“基于浏览器端的开发”就成了软件开发的新的分支,即不论何时何地何种系统以及怎样的设备,但凡基于浏览器,都是Web前端开发的范畴。

在 2000 年之后浏览器技术渐渐成熟,Web产品也越来越丰富,大批年轻人开始接触互联网,注意,大部分人接触互联网不是始于对浏览器功能的好奇,而是被浏览器所承载的内容所吸引,我们的思维模式从一开始就被限制在一个小窗口之内,以至于很长时间内我们将“视觉”认为是一种“功能”,Web产品无非是用来展现信息之用。起初的入行者无一例外对“视觉”的关注超过了对“内容”的重视,先让页面看起来漂亮,去关注html/css。因此,这类人是被“视觉”所吸引,从切页面入行,着迷于结构化的html和书写工整的css,喜欢简洁优雅的UI和工整的页面设计,之后开始接触视觉特效,并使用jQuery来实现视觉特效,以此为线索,开始深入研究Dom、Bom和浏览器的渲染机制等,html/css在这些人手中就像进攻兵器,而JavaScript则更如防守的盾牌。

还有另外一群人从另一条道路接触Web前端,即工程师转行做前端,他们有较多的后台语言开发背景,从读写数据开始,渐渐触及浏览器端,接触JavaScript库,起初是在html代码上加js逻辑,后来开始涉及html和css,他们喜欢OO、逻辑清晰、结构悦目的代码,更关注界面背后的数据逻辑。html/css在这些人手中则更像盾牌,而JavaScript更如进攻的兵器。

两类人是互补的,他们各自了解浏览器本质的一部分,一拨人对渲染引擎了如指掌,另一拨人则将JS引擎奉为至宝。大部分前端工程师都能从这两条渊源中找到自己的影子。但,这两类人的思维模式和观点是如此不同,以至于形成了一些不必要的对抗,比如在某些公司,干脆将Web前端技术一分为二,“切页面的”和“写js的”。这样做看上去明确了分工提高了效率,但他对员工的职业发展带来巨大伤害。

我应该属于第二类,即在学校正儿八经的学习C/Java和C#,以为大学毕业后能去做ERP软件、桌面软件或者进某些通信公司做网络编程。校招时选择了中国雅虎,因为当年(2008年)雅虎还是有一点儿名气,而且我听说雅虎比较算技术流的公司……自此就上了贼船,一发不可收拾。

在雅虎的这段时间,我有幸接触到一股正气凛然的技术流派,也形成了我对前端技术的一些基本看法,一直影响我至今。

优雅的学院派

当年雅虎的技术流派正如日中天,拥有众多“之父”级的高人,所营造出的 Hack 氛围实在让人陶醉的无法自拔,那段时间我甚至宁愿加班到深夜阅读海量的文档和源代码,感觉真的很舒服,我深深的被雅虎工程师这种低调务实、精工细琢的“服务精神”所打动,而这种不起眼的优秀品质很大程度的影响雅虎产品的用户体验和高质量的技术输出。那么,何谓“服务精神”?即你所做的东西是服务于人的,要么是产品客户、要么是接手你项目的人、要么是使用你开发的功能的人,所以技术文档成为伴随代码的标配。因此,工程师之间通过代码就能做到高效沟通。这是工程师的基本素质,即,思路清晰的完成项目,且配备了有价值的技术文档,如果你的程序是给其他程序员用的,则更要如此,就好比你制造一款家电都要配备说明书一样。因此,YDN成了当时最受全球程序员最喜爱的技术文档库,这种优雅务实的“学院气息”让人感觉独具魅力。

Yahoo 的工程师习惯于总结和沉淀,他们愿意这样做,更重要的,他们的文笔也不错。文笔往往被人忽视,难以置信这竟然是阻碍工程师突破瓶颈的关键所在。我看到太多人因为不会写而吃了大亏,太多工程师真的不善于写文字(文档、邮件、ChangeLog、CommitLog等)。除非你走狗屎运碰到一个懂技术的老板,否则真的没办法逃脱码农的宿命。很多人对此不以为然,特别是前端工程师。前端工程师是最喜欢搞重构的,但除了“感觉代码更整洁”之外,真的无法解释重构的商业价值,解释不清就容易招人闲话。

当然,情况不总是这么糟糕,我们看到中文社区中已经锻炼出了很多写手,他们在用高质量的文字推销自己的技术理念,这是一个好兆头,好的文笔是可以锻炼出来的。而在职场,特别对前端工程师来讲,这种基本技能可以帮你反思梳理事情的轻重缓急,从凌乱的事情中把握七寸。因为当你开始认真写一封邮件的时候,这种思考已经包含其中了。

所以,雅虎技术的推销是相对成功和远播的。关键在于两方面,扎实的技术功底和高超的写手。而真正的技术大牛一定是集两者与一身,不仅钻研剑道,还能产出秘籍。这也是Yahoo!优雅的学院派气息的动力源泉。国内很多技术团体想在这方面有所建树,应当首先想清楚这一点。

规范的破与立 1

雅虎的技术运作非常规范,包括技术、组织、文化,一切看起来有模有样,堪称标杆,自然成了国内很多技术团队和社区的效仿对象。一时间各种“规范“成风、各色“标准“大行其道,瞬间泛滥成灾。

我们到底需要什么样的规范?雅虎的技术规范到底有何种魔力?什么规范才有价值?规范有着怎样的生命周期?想清楚这些问题,能很大程度减轻Web前端工程师的思想负担,避免盲目跟风。

我们的确需要规范,但好的规范一定是务实和“解决问题“的。比如针对项目构建的 DPL 可以收纳公用的视觉元件以减少重复开发、规定某 OPOA 项目的事件分发原则以确立增量开发的代码惯性。还有一些规范则过于“抽象“,比如页面性能指标、响应式设计原则。另外,尽管他山之石可以攻玉,但拿来主义有一个大前提,就是你了解你的项目的关键问题,你要优先解决的是些关键问题,而外来规范正好能解决你的问题。因此规范是一本案头手册,应当是“字典”,而不是“教程“。可见规范的源头是“问题”。所以,当你想用 CoffeeScript 重构你的项目时、当你想引入 CommonJS 规范时、当你想在页面中揉进 Bootstrap时、当你打算重复造轮子时、想想这些东东解决了你的什么问题?还是仅仅为了尝鲜?或者为了在简历中堂而皇之的写上使用并精通各种新技术?

规范之立应当有动因,动因来源于项目需求,项目需求则来自对产品的理解和把握,这是Web前端初级工程师境界提升的重要蜕变,软件工程领域早就有“架构师”角色,而架构师往往存在于项目需求分析和概设、详设阶段。我看到的情况是,前端工程师的思维过多的限制在“界面”之内,向前和产品需求离的太远(认为这是视觉设计师的事)、向后和数据逻辑又隔离开来(认为这是后台工程师该干的事),因此前端规范也大都泛泛,无关项目痛痒,成了玩具。

雅虎技术规范的优秀之初在于它们解决问题。所以,学习使用规范应当多问一句,“他们为什么这样做?”其实,想清楚这些问题时,脑海中自然形成了一种“遇山开山”的创造性思维。

规范的破与立 2

新技术的尝鲜往往缺少针对性,但至少满足程序员的洁癖和快感,那么“负担”从何而来呢?对于初学者来说,有价值学习资料可能只有这些规范,如果说规范价值不大,那又当从何入手来梳理项目遇到的难题呢?

这需要我们对规范进行反思,摆脱规范灌输给我们的思维定势。新人们大概是看了 Wiki 中的很多指标、结论、实践,在编码时背上了“八股式”的负担,甚至影响我们对项目关键需求和关键问题的洞察力和判断力,负担过重就无法轻装上阵,规范是结论性的,也只有经历过大量实践才会真正理解这些结论,比如 DomReady 时间和 http 请求数是否有因果关系,http 请求数增加是否真的会导致页面性能下降,什么条件下会导致性能下降?我们从那些条文和结论中无法找到答案。

举个具体的例子,Kissy DPL 中的布局就采用了经典的双飞翼,使用容器浮动来实现,那么,这种做法就是不可撼动的“标准”吗?淘宝不少类目首页布局容器齐刷刷的使用了 inline-block,只要顶层容器去掉宽度,布局容器自身就能根据浏览器宽度调整自然水平/垂直排列,轻易的适应终端宽度了。

类似这种摆脱原有编程思维,有针对性的用新思路新方法解决问题的做法显然让人感觉更加清爽,编程的乐趣也正体现在打破常规的快感之中,“制造规范是为了打破规范”,万不要因为这些规范标准加重负担,导致开始作一个简单页面时也显得缩手缩脚,无法放开身手。大胆实践,多写代码,自然熟能生巧,也容易形成成熟的技术观点。

在这个过程中,我们唯一的对手是懒惰。还是那句话,任何规范、方法、结论、实践都是为了解决项目中的问题的,所以,我们所接触到那些看似“八股文”式的规范标准也是为了解决某些问题而提出的,想清楚这些问题,理解方法论背后的“因“,内心自然有“果”。

因此,“着眼当下、对症下药”的品质就显得弥足珍贵了,比如,双飞翼布局方法是为了解决一套(html)代码适应多种布局设计,这里的布局相对于固定的产品来说也是固定的,而无针对终端的自适应。这是双飞翼产生的背景,如今终端环境较之 5 年前已经翻天覆地,问题早已不在“多种布局”上,而在“终端适应“上,这才是我们面临的问题,需要我们给出新的技术方案。

所以,勤于思考,轻装上阵,大胆实践,勇于创新,发掘问题所在,实打实的解决(潜在)问题,这才是我们真正需要的能力。放下思维定势枷锁,也会有一种豁然开朗的感觉。

@jayli jayli closed this Oct 15, 2013
@jayli jayli changed the title from 视图滚动时的渲染优化的例子 to 十日谈——第一日,初尝禁果 Jul 23, 2014
@jayli jayli changed the title from 十日谈——第一日,初尝禁果 to 十日谈,第一日:初尝禁果 Jul 23, 2014
@jayli jayli reopened this Jul 24, 2014
@jayli jayli added the blog label Jul 24, 2014
@lixuejiang

获益良多

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment