zoukankan      html  css  js  c++  java
  • 前端工程师的未来2——摘录两篇不错的文章

    摘自:http://chinese.catchen.me/2011/12/blog-post_14.html

    要做关键任务

    我觉得,要别人重视你的工作,不仅仅是你做得好就行了,还要求你的工作对别人来说足够重要。这跟产品定位有关——例如说对搜索引擎来说,前端对产品的影响不会非常大,用户只要能搜索到自己想要的结果就行了。搜索引擎最复杂的交互可能就是搜索框的自动完成了,但有自动完成和无自动完成的区别到底有多大呢?跟准确率和召回率相比,有没有自动完成实在没有多重要。况且,自动完成的结果本身也依赖于准确率和召回率,所以后端工程师比前端工程师重要得多。

    因此,前端工程师在选择工作时首先要选择前端足够重要的工作。重要用什么来衡量?务实的话,是钱;务虚的话,是产品。如果一个功能只能在前端实现,并且这个实现能够提高多少的转化率,使得多少原本不产生利润的点击产生利润,那么前端对这个产品来说一定十分重要。可惜往往跟钱相关的事情不由前端工程师来研究和决定,所以这部分工作还是安心交给产品设计师来做吧,让他们来决定怎么样的产品能赚钱,然后由你来完成这个产品的实现,这时候你的目标就是把产品做好。

    回到刚才的问题,有些产品更依赖于后端,例如搜索引擎,当然也有些产品更依赖于前端。什么样的产品更依赖于前端?就是后端难以建立起技术壁垒的产品。这类产品要抄袭一个功能差不多的并不难,因此只有细节做得最好的能够获得足够多的用户。这类产品在 iOS App Store 上很常见——有很多 app 拥有相似的功能,而其中只有一个交互设计得最好的能够获得绝大多数的用户。尽管 app 不存在 HTML + CSS + JS 这个前端,不过道理是一样的。当年 Tweetie 能够取代老牌的 Twitterrific 成为主流 Twitter 客户端,靠的就是交互上的创新,外加不差的性能和稳定性。如果交互对于一个 web app 来说十分重要,这个 web app 自然也就需要十分优秀的前端工程师。

    总结一下,由于前端工程师的价值在于实现复杂的前端细节,因此如果可以选择的话尽量选择一个细节决定成败的产品。如果产品的成败已经由后端工程师决定了,例如某某数据规模要么能做要么不能做,那么这个产品就没你什么事了。

    要懂核心业务

    每一个公司,每一个项目,都有它的官方语言。不是指普通话,也不是指 C++,我指的是大家围绕什么问题来展开项目,什么问题的讨论能让大家为之兴奋。举个例子来说,百度的官方语言就是搜索,跟搜索没有关系的产品也会使用「准确率」、「召回率」这样的术语用来做比喻。前端工程师有多少知道什么是「准确率」、「召回率」的?估计不多,因为前端根本没有这样的概念。这时候前端工程师要跟后端工程师沟通也就不容易了。久而久之,你对人家很兴奋在讨论的什么 O(1) 还是 O(n) 不感兴趣,人家也不理解你的 {} != {} 是什么意思,你就被边缘化了。

    如果不想被边缘化,就算前端不是公司的核心业务,你也必须懂公司的核心业务,然后说着官方语言,而不是前端的方言。这就意味着,如果你在一家后端技术很强大的公司,你最好也懂后端技术。我知道国内有很多前端工程师并不是计算机系毕业的,就算是国内的教育也不怎么样,这时候你只能恶补相关的基础知识了。如果你不懂这些,就算你能把整本《JavaScript 权威指南》背下来,你说的还是方言,说官话的人还是会鄙视你。如果公司主要服务于某个垂直领域的话,你必须对这个垂直领域十分了解,随时能用这个领域的行话来沟通。

    总结一下,由于每个人已经熟悉的领域都不一样,所以没办法说哪个领域更适合前端工程师。如果你原本已经有某个领域的从业经验,进入服务于该领域的技术公司总是有显著优势的。如果你进入了一个自己不熟悉的领域,那就一定要补充相关基础知识,否则你对这个领域不感兴趣,这个领域也不会对你的前端工作感兴趣。

    实际例子

    为什么我选择加入豌豆荚?主要考虑的还是上面两点。

    我在百度的时候一直就在想,既然前端对搜索引擎来说不重要,那对什么类型的应用来说比较重要呢?当时看到 Facebook 做得不错,所以觉得社区会需要复杂的交互,而如果复杂交互做不好则会影响用户使用,因此前端对社区来说应该十分重要。现在看来,也不完全是这样子。前端对社区来说确实重要,但 Facebook 并不是一个典型的例子,它是一个前端做得尤其优秀的例子。

    在我了解到豌豆荚 Windows 客户端的实现方式时,我立即意识到它可以通过我的第一个判别标准——前端对它来说是关键任务。它使用 Webkit 做了一个容器,然后把所有的交互都通过 web app 的形式做在里面,然后通过一组接口跟 native 进行交互。如果一个应用决定要这样做了,那么前端就能影响到它的成败,因为这时候前端后端的分隔线已经很明确了。如果一项功能应该由前端来做那就必须由前端来做,后端基本不可能成为实现此项功能的备选方案,这时候前端就具备了无可替代的位置。

    至于第二个判别标准——豌豆荚的核心业务是什么?我觉得豌豆荚做的很多事情都是以产品设计为起点的,而这至少是我感兴趣并且也有点感觉的东西。从细节上来说,就是大家喜欢谈论的事情是一致的,例如产品如何做一些很智能的设计,最新的技术方案如何能够巧妙地帮助这些设计得以实现。Junyu 说「设计就是创造性地解决问题」,这是我喜欢的解决问题方式。这个世界上能够把逻辑转化为代码的人非常多,同时有一定数学和计算机专业基础的人也不少,因此要拼谁的解决方案更好的话那还要加上创造力。

    我知道国内有很多产品设计师,在考虑产品时首先想到的是百万千万级用户量,这样无论从单个用户身上赚到的钱多么的少,最终产品还是能赚大钱。百度曾经就属于这种思维方式,但这不是我喜欢的风格,因为没有明确的目标用户定位。我知道国内由很多工程师,在编写代码时用尽各种技巧以展示自己过人的才智,但是这样的代码还有可复用性吗?除了作者本人没有人能够维护啊。不同的人有不同的品味,能够跟品味一致的人一起工作是一件幸福的事情。

    摘自:http://hi.baidu.com/cly84920/item/dfc869c2f73bcd300931c685

    我自己是又写前端又写服务端的,特别是来盛大以后,前端只是我1/3的工作,同样占1/3的还有后端的工作。我工作时同时在前端和后端,一会儿切到前端,一会儿切到后端。不说后端的分布式问题,也不说前端的兼容问题,那个其实都和“编程”本身的体验关系不大。

     

         我有一个非常明显的体会是:后端编程我只需要在编程之初,设计好OO,画出UML图之后,基本上在编程过程中会一路非常顺,也不太需要怎么动脑子;但在前端,设计好OO,画出UML之后,我仍然需要马力全开,每实现一个效果,脑子里都会同时跑出多种解决方案 ,然后比较各种方案的扩展性,可维护性,不断地权衡。前端需要权衡的东西太多,每走一步全是权衡,解决方案太多了,我必须选择,不停地选择。

     

         伴随这些选择的,伴随种种解决方案的,需要的就是“创意”。服务端语言当然也是胶水,要粘起数据库,要粘起各种垂直功能库,但编码过程中其实思路还是很清晰的,只在几个必要的时候粘一下;但前端语言的胶水性更强,时时刻刻在粘着css、DOM和BOM, 每一步都在粘,脱离了DOM、css基本上一无是处寸步难行,每一步脑子里都在权衡几个不同的东西,工作时时刻也无法抛开DOM、css这些low level的东西,单纯工作在OO的抽象层面。而server端大多数时候却都是工作在OO的抽象层面的,工作时要考虑的东西单纯得多。

     

         我在项目里,花在前端的时间和后端的时间基本上是7/3开的,而前后端的代码量更是超过7/3开,远不成正比。我明白每个领域关注点不同,单纯说谁比谁好,谁比谁有价值是没有意义,而且很孩子气的,脱了哪一环事都办不好。但的确前后端工作的劳心程度存在巨大差异,这是事实。

  • 相关阅读:
    导入导出模块
    jQuery复习
    vue记录
    angular 初探之父子组件之间传递数据
    webpack
    go语言语法记录
    dom元素的滚动(如何实现点击展开更多功能)
    正则回忆录
    Attributes 和 properties区别和联系?
    显示 隐藏DIV的技巧
  • 原文地址:https://www.cnblogs.com/doit8791/p/3514654.html
Copyright © 2011-2022 走看看