Winter | 你不知道的组件化开发:组件化的前世此生

时间 2019-11-24

标签 winter 不知道组件开发前世此生繁體版

原文原文链接

这个分享是由极客时间组织的微信群内分享，本文内容前半部分是winter关于组件的分享，后半部分是Q&A。前端

Q&A部分包含诸如组件构建、GraphQL以及前端架构师等前端相关的各部份内容共25个问题，winter以他老法师的见识分享了独到的看法。vue

关于组件

引言

今天前端生态里面，React、Angular和Vue三分天下。虽然这三个框架的定位各有不一样，可是它们有一个核心的共同点，那就是提供了组件化的能力。W3C也有Web Component的相关草案，也是为了提供组件化能力。今天咱们就来聊聊组件化是什么，以及它为何这么重要。node

正文

其实组件化思想是一种前端技术很是天然的延伸，若是你使用过HTML，相信你必定有过“我要是能定义一个标签就行了”这样的想法。HTML虽然提供了一百多个标签，可是它们都只能实现一些很是初级的功能。python

可是，HTML自己的目标，是标准化的语义，既然是标准化，跟自定义标签名就有必定的冲突。因此从前端最先出现的2005年，到如今2019年，咱们一直没有等到自定义标签这个功能，至今仍然是Draft状态。react

不过有同窗会问：自定义标签也不等于组件化自己啊。没错，不过能够进一步思考，其实咱们须要的并不必定是自定义标签这样的一个形式，能够从软件工程的通用思想来解释，组件化能够拆解为四个更基本的概念：web

封装：组件屏蔽了内部的细节，组件的使用者能够只关心组件的属性、事件和方法。面试
解耦：组件自己隔离了变化，组件开发者和业务开发者能够根据组件的约定各自独立开发和测试。算法
复用：组件将会做为一种复用单元，被用在多处。chrome
抽象：组件经过属性和事件、方法等基础设施，提供了一种描述UI的统一模式，下降了使用者学习的心智成本。小程序

咱们能够进一步分析，其实组件化并不是前端独有的一种需求，任何软件开发过程，或多或少都有那么一些组件化的需求。而你能够思考为何较好的组件化解决方案（三大框架）会出如今2014年左右这个时间点，这是一个回味无穷的问题。而我认为这个问题的答案，就藏在前端发展的历史当中。

咱们能够看下复用、解耦、封装、抽象这四个概念，很显然，它们都是为了大型的、多人协做的软件开发所准备的。因此我认为，2014年左右这个时间点，正是前端发展到了一个须要规模化的时间点。

咱们纵观前端的发展历程，开始于2005年左右，是特效为王的时代，前端领域追逐的是炫酷的效果；到了2009年左右，jQuery开始统治前端，这时API易用性和浏览器兼容性是最重要的；等到了2012年移动互联网出现以后，提供组件化方案的“三大框架”逐步占据了前端重要的生态地位。

接下来咱们深刻具体的技术细节，看看组件化是如何一步步发展的。首先，标准的DOM元素是这样建立和挂载的：

var element = document.createElement('div')
document.getElementById('container').appendChild(element)
复制代码

这里的element是一个对象，可是其实JavaScript（早期）里面，根本无法建立这样的对象。一方面也是咱们没有办法改变createElement这个函数的行为。既然API风格无法靠拢DOM原生，那么就靠拢JS原生吧，因此一些前端开发同窗就萌生了建立一个带容器的对象的想法：

function MyComponent() {
    this.prop1;
    this.method1;
}
复制代码

不过，要想挂载又成了难题，普通的JS对象无法被用于appendChild，因此前端工程师就有了两种思路，第一种是反过来，设计一个appendTo方法，让组件把本身挂到DOM树上去。

function MyComponent () {
    this._root = document.createElment('div')
    this.appendTo = function (node) {
        node.appendChild(this._root)
    }
}
复制代码

第二种比较有意思，是让组件直接返回一个DOM元素，把方法和自定义属性挂到这个元素上：

function MyComponent() {
    var root = document.createElement('div')
    root.prop1
    root.method1 = function () {
    //... 
    }
}
复制代码

虽然从前端全领域来看，组件化到后期（2014年）才有比较普及的应用，可是早年用这样的思路实现组件体系的方案并很多，说明组件化在一些公司和领域始终有需求。虽然当时有一些组件化方案没可以影响行业，可是不能否认它们也还算是不错的解决方案，好比著名的ExtJS（现已改名为Sencha），咱们来看看它的组件定义：

MainPanel = function() {
  this.preview = new Ext.Panel({
    id: "preview",
    region: "south"
    // ...
  });
  MainPanel.superclass.constructor.call(this, {
    id: "main-tabs",
    activeTab: 0,
    region: "center"
    // ...
  });

  this.gsm = this.grid.getSelectionModel();

  this.gsm.on(
    "rowselect", function(sm, index, record) {
      // ...
    }, this, { buffer: 250 }
  );

  this.grid.store.on("beforeload", this.preview.clear, this.preview);
  this.grid.store.on("load", this.gsm.selectFirstRow, this.gsm);

  this.grid.on("rowdbclick", this.openTab, this);
};

Ext.extend(MainPanel, Ext.TabPanel, {
  loadFeed: function(feed) {
    // ...
  },
  // ...
  movePreview: function(m, pressed) {
    // ...
  }
});

复制代码

你能够看到，这是一个彻底使用JS来实现组件的体系，它定义了严格的继承关系，这样的方案很好地支撑了ExtJS的前端架构。不过，建立和挂载对象的方式可不止DOM API，还有HTML语言，如何让前端组件融合进HTML语言呢？

<my-component attr1="..."></my-component>
复制代码

关于这方面，依赖早期标准的前端技术能够说几乎没有办法。可是，历史中总有些遗珠，微软的IE浏览器已经提供了组件化的解决方案，名为HTML Component，我找了一段很是古老的示例。

<HTML xmlns:PUBLIC="urn:HTMLComponent">
<PUBLIC:PROPERTY NAME="child">
<PUBLIC:ATTACH EVENT="onclick" HANDLER="onclick_handler">
<PUBLIC:ATTACH EVENT="onmouseover" HANDLER="onmouseover_handler">
<PUBLIC:ATTACH EVENT="onmouseout" HANDLER="onmouseout_handler">

<SCRIPT language="JSCript">
    function onmouseover_handler () {
        element.style.color = "red"
    }
    function onmouseout_handler() {
        element.style.color = "black"
    }
    function onclick_handler () {
        // ...
    }
</SCRIPT>
复制代码

这项技术提供了事件绑定和属性、方法定义，以及一些生命周期相关的事件，应该说已是一个比较完整的组件化方案了。可是咱们能够看到后来的结果，它没有可以进入标准，默默地消失了。用咱们今天的角度来看，它能够说是生不逢时。

到了“三大框架”出现的时代，由于面向的客户群体从少数公司、少数领域变成了广大前端开发群众，也由于一些新技术的出现，让旧时代组件化无法解决的问题有了新的可能性，这些新的组件化方案都保持了HTML甚至CSS的书写习惯。

Vue.js采用了JSON的方法描述一个组件：

Vue.component('todo-item', {
    props: ['todo'],
    template: '<li>{{todo.text}}</li>'
})
复制代码

还提供了SFC（Single File Component，单文件组件）“.vue”文件格式：

<template>
    <div class="example">{{msg}}</div>
</template>

<script>
    export default{
        data () {
            return {
                msg: 'it works'
            }
        }
    }
</script>

<style>
    .example {
        color: red
    }
</style>
复制代码

React.js发明了JSX，把CSS和HTML都塞进JS文件里：

class ShopplingList extends React.Component {
    render() {
        return (
            <div className="shopping-list">
                <h1>Shoppling List for {this.props.name}</h1>
                <ul>
                    <li>Instagram</li>
                    <li>whatsApp</li>
                    <li>Oculus</li>
                </ul>
            </div>
        )
    }
}
复制代码

Angular.js选择在本来的HTML上扩展，定义组件的方式也是JS class：

export class HeroListComponent implements OnInit {
    heroes: ['hero'];
    selectedHero: hero;

    constructor(private service: HeroService) {}

    ngOnInit() {
        this.heroes = this.service.getHeroes()
    }

    selectHero(hero:hero) {this.selectedHero = hero}
}
复制代码

咱们能够看到，现代的组件化方案跟旧时代组件化方案的一个明显区别就是，如今的组件化方案保留了原有的标记语言部分，而且努力保留了样式表部分。

虽然技术从旧到新经历了各类变迁，可是组件化的核心并无变化，咱们的目标仍然是在API设计尽量接近原生的状况下完成复用、解耦、封装、抽象的目标，最终服务于开发，提升效率，下降错误发生比率。

若是你的公司和前端团队规模正好面临须要创建组件化体系，但愿你能从今天所分享的历史中得到一点灵感。

Q&A

1.渣渣提问 我想请问老师，组件的颗粒度什么样比较合适？它的包含度又应该是什么样的范围？

组件这个东西，它的粒度是无所谓的，他是一个级联的结构，因此说你能够有粗粒度的组件，也能够有细粒度的组件。我以为其实替代粒度的这个概念应该是体系这个词，即如何去设计细粒度的组件，又如何去设计这个粗粒度的组件，最后造成一个很好用的体系。我想用简单的能够用，想用复杂的、现成儿的、大块儿的，也能够用。

2.tk提问 组件化了还能作SEO么？

其实你若是对现代的SEO有必定的了解的话，你会发现这个东西其实已经走到了一条彻底不同的道路上了，咱们如今不少的SEO方案是服务端专门渲染一套给这个搜索引擎去看的。可是你说组件化，若是说咱们正常的使用各类组件化的技术，他对SEO是否是会有负面影响，我认为确定是会的，毕竟你用了一个自定义的标签，浏览器是不认识的。可是，其实你们看了咱们那个重学前端的课程，就会发现其实重点不在于这些地方，浏览器也有专门的一些标签儿，专门写给搜索引擎看。

3.李小刚提问 如何避免过分封装？

我以为你们没有到担忧过分封装的时候，你们每每会发生一种状况就是没有封装。固然，这个状态也会有一个比较危险的状况，从没有封装一下，忽然发现封装这东西很好用，而后咱们就去过分封装了，实际上我以为是应该去了解一些基本的知识，好比说什么叫对象，为何这些方法和这些属性要聚合成一个对象，由于他有一些局部性，你把局部性这个聚合起来就是好的，你把没有局部性的聚合起来，就拔苗助长。这只是个例子，面向对象的基本原则，其实均可以去学习一下，就不会过分封装。

4.共性问题 组件化体系设计

其实以前，我也没有什么特别的理论思路，有些时候是凭感受。不事后来我有一个朋友也是前同事前下属勾三股四，跟我说你若是作UI组件的话，能够去参考那个web accessibility，你去看W3C的标准里面，它基本上把你人类经常使用的组件规范都总结完了，它自己不是组件，可是去设计组件时以此为参考是很是好的。

5.stussury_41提问 jsx作组件化后期会不会很差维护？组建自定义部分用插槽好仍是jsx？

用JSX，确定是没有不可维护这个问题的，我估计大家的业务应该不太可能会比淘宝复杂。淘宝相对来讲已是一个中等偏上的复杂业务了，我在淘宝工做期间，使用JSX去作组件化，这个彻底没有问题。

6.vey提问 前端微服务对比组件化，使用场景和优劣如何？

应该说微服务这个概念，它自己就是从后端来的一个纯粹的概念，我还没见过谁在前端要搞这个微服务，由于微服务这个词对前端页面的这个维度来讲有点大，通常来讲前端是没有服务这个东西的，那就更况且说这个里面再衍生出来微服务这个东西。微服务的主张是咱们一个服务只作一件事情，专一作好本身的这一部分。而不是去混合业务场景设计这个API。从某种意义上说，我认为一个前端页面，甚至有可能都不必定有后端的一个微服务大。因此我不建议把微服务引进前端里面来。

7.lynn-上海-前端提问 请问老师，以前封装好的组件，随着项目迭代功能不全，如何添加功能尽可能减小对其余使用过该组件的影响？

这个组件设计好了以后，如何去给他添加功能、如何去迭代。坦白地说，这是个难题。虽然我能够讲出不少听起来特别有道理的理论。但事实上，曾经在淘宝发生的一件事是一个轮播最后被加了30多个参数。固然我仍是要讲一下这个理论知识，咱们设计组件也是遵循面向对象的这个基本原则，对修改封闭、对扩展开放。那好比说你有新功能，你就能够选择继承，或者是包装这个组件，造成一个新的组件来完成你的新功能，这样组件体系就会变丰富，不会有不少的麻烦。

8.关于将来的问题 Web Components | TypeScript | Webassembly

一句话讲就是我不知道，这个将来的东西不太好预测。可是目前来看，我认为这三个东西都是偏向比较积极，都是高速发展且快速落地的。可是你说他会不会真的超过现有的一些东西，他能发展到什么程度，这个我就很差说了。那我建议这三个东西是应该积极对待，都去学一下。不必定哪一个将来就会成为一起很重要的东西，另外，他们也确实可以解决咱们不少前端开发的问题。

9.lx提问 winter老师您好：我司正在使用GraphQL接口，请问winter老师在您的前端生涯中，GraphQL结合react进行组件化开发有没有很棒的实例场景？

其实提及来比较惭愧，我之前在淘宝工做的时候，咱们的 GraphQL也没有真正落实的特别好，并且据我了解，这个在Facebook本身那边 GraphQL，落实的也不是特别好。我以为这个理念特别的先进，这个叫BackEnd For FrontEnd，我以为他是BFF的一个延伸，可是其实不多公司是这么落实的，好比说在淘宝，其实咱们落了一个半像不像的这样的一个东西，就是咱们那有些API，咱们能够经过后端去写 GraphQL来生成出来。最后你前端看到的仍是一堆数据，可是其实这个 GraphQL本来的设计不太同样。

10.农夫-北京-前端开发提问 老师您好，在开发公司内部组件库时，有必要去设计组件间的消息机制吗？若是有必要，能带来哪些明显的优点？

其实我不太建议postMessage这样的机制，我记得其实在前三四年吧，大概2015年左右的时候，那时候听阿里的晋升面试，每一个人都要讲一下他设计的组件体系和他中间的这个消息通信机制，有用一个消息池的、有用这个各类分发的策略的，其实这个很差，这个东西最后都会变成这个消息进了这个东西以后，你debug的链路就断了，消息过去了，你不知道后面执行什么代码，因此我不太建议作这种直接的消息机制。但其实你看如今的Flux、Redux，这样的东西，其实它都是一种变形的消息机制。我比较推崇的是Vue Angular的这个双向绑定，他不彻底是一种消息机制，那么你去操纵这个数据，这个数据变了之后，全部跟这个数据相关联的这个组件，它都产生了一个变化，实际上这个里面是有消息流转的，你去看Vue的源代码。他必定是有消息通知过来，这个代码变了，那边去observe这个属性。这个其实替代了某种程度上的消息，可是他的语义化更好，他不是一个未经定义的消息告诉你，你本身去拿一个字符串去定义，而是一种给你规定好了的，这叫数据变化性的消息，甚至它规定了你应该如何响应他，我认为这种模式可以减小开发出错。

11.新哥~Lewis提问 有vue 页面首次加载白屏好的方案吗？

你看一看你是不模板没有预编译。通常来讲，这个Vue首次加载白屏，都是由于在运行时引了那个Vue的那个调试版本，因此说致使他有加载白屏，由于他要编译你的代码。咱们通常来讲用Vue CLI建立的都是没有这个问题的，若是你的状况比较特殊，我建议你直接去Vue项目里面留言，Vue社区他很喜欢这样的例子，你若是有这种真正意义上的会致使它白屏的案例，他会很积极的帮你去设计方案去解决。

12.共性问题页面性能

其实在工程的角度来看，性能跟组件化实际上是两个方向，因此说跟我们组件化没有关系，可是能够稍微讲一下。凡是工程体系，都是要有一些监控手段和评估手段。因此你作性能的话，确定先建这个标准，可以知道这个页面的性能怎么样，而后再去看如何优化。若是说你看我买了个人这个重学前端这个课，这里面有讲到一些关于性能优化的这样的一个方法论。其实网上自己相关的知识也是不少的，细节其实不重要，网上都能找到各类各样很好的性能优化的小细节。

13.peter提问 传统的架构师大多数是后端过来的，相对于后端架构师，咱们前端在架构方面怎么能最大的体现价值？或者什么才是一个前端“架构师”？

其实前端架构师面临的问题，实际上跟别的架构师不太同样。前端是零碎的页面大量的重复性劳动，而不是传统软件意义上的模块间的耦合和复杂性。因此前端架构重点关注的是复用，这个就跟我们今天的组件化很是的相关了，因此我原来带手淘的架构组，基本上都是在作这个组件体系的事，先把复用作上来。

另外还有一点是，前端架构跟别的架构师，好比服务端架构师、客户端软件架构是不太同样的，就是这咱们前端架构仍是能够用一些工具去解决的。好比说，淘宝有一个特别重视的系统，叫搭建系统。这是咱们的工程体系里面的很重要的一环，能够大量的产出这种简单的页面，不须要通过前端，经过模板化或者是模块化的方法。其实组件化就是复用的一个很重要的话题。

14.许凯旋提问 但是angularJS这种脏检查模式，在一些状况下，影响性能，有要注意改进的地方嘛？

我从他出来的第一天就在喷这个事情。不过你会看到，这个问题其实他是一个技术问题，这是由这个Angular.js最开始的这个设计者的这个技术不过关形成的。那对于技术问题，当这个东西影响力足够大了之后，必定会有人给他解决，好比说后面这个JS标准也出了proxy。后面在Angular2上，这个问题也获得了很好的处理。因此你去Angular社区能够找到这个东西的答案。

15.lester-深圳-前端开发提问 老师，前端开发人员有必要向全栈方向发展么，若是作全栈技术选择上有什么建议没？

说实话，目前来看在国内全栈的市场不是特别的看好。另外，我特别不建议你去作Node全栈，不是说我看不起Node，反而是我以为Node难。Node这个局面能够说是百废待兴，你去拿Node作前端，看起来是一个server，其实你想把这个server真正可以跑到线上稳定且可以本身重启，你要写的代码实际上是很是多的。因此只有阿里的那几位大神，苏千朴灵，他们在阿里能搞起一块Node这样的场景，其实他们也很艰难，因此我不建议通常人去往Node全栈转。那你拿一个已经很火的这种后端语言，好比python、Ruby或者是Java，跟JS搭一下去作这个全栈，你说可不能够，我以为确定是能够。毕竟手艺活，多学一门确定是好的，就看你本身怎么分配精力了。另外就是这个全栈，是否是在市场上有足够的岗位，如今来看全栈的岗位偏向小公司一些。或者说你本身要创业，那你搞个全栈这个是很好的。因此我以为这个事情自己，就是职业发展以及我的的偏好问题。没有一个放之四海皆准的规则。我也不可能给你一个建议，说你就作全栈或者别作全栈了。其实我本身也是会一点儿服务端，可是我确定不会往全栈去作，由于我以为这个精力跟不上。

16.但愿提问 电商网站，金额计算有必要先后端都进行计算嘛？

这个问题比较奇怪。我以为通常来讲是要后端进行计算的。至少在阿里咱们不多拿前端去计算一些折扣这样的事情。这里面的主要缘由是从这个风险上去评估的，有一些东西，好比说客户端版本更新不上，从而形成一些优惠错误，可能就会产生一些资损。固然这个事不是绝对的，购物车里的总价，你要不要到服务端去再绕一圈，那我以为不用。因此我以为这个仍是要分析一下具体状况。

17.lynn-上海-前端 老师，请教一下，之前面试的时候听面试官说，前端后期须要了解http协议制定规范，还有须要回设计模式甚至用nodejs成为web全栈，这是成长必须的么？

HTTP规范我以为有用，可是其实你真要去问的话，你能知道几个HTTP状态码？我以为通常人不会超过十个，因此你说这个谁知道HTTP协议的细节。我以为要求有点偏高，这不是必要的知识。可是我以为他确定在某些时候会有用，因此从学习的角度来说我建议你学。那你说从面试的角度来说，我以为这个是一个无理要求，由于你也不知道他要考哪儿。而后对于设计模式，其实你要知道这个设计模式这本书，他是为基于类的面向对象来编写的。因此说不少模式在JS这边，早就已经要么不须要，要么不能用。好比说这个工厂模式，他们要解决的问题是在new的时候，class的这个东西你无法传的问题。那实际上你说在JS里有这个问题吗，咱们的JS构造器就能够看成函数参数往里传，因此根本就不存在工厂模式的这种需求，无论是抽象工厂仍是这个builder，仍是这甚至是不在23模式中的简单工厂模式，都不须要，咱们没这需求。

18.凯提问 flutter最近很火的，做为前端有必要学吗？

我以为要是什么技术火学什么，那估计你要累死，其实最火的不是flutter，最火的是区块链和AI。但你不太可能往那边转，去学flutter也是同样的道理，你若是以为这块儿你很喜欢，你就转过去学。可是你要知道fluter是一个全新的体系，他其实跟咱们传统的前端开发，已经有必定的隔离了。我是认为它会是一个小众的东西，可是我以为他确实作的很好，因此必定他可以有本身的一席之地。

19.pandaTsui提问 前端是否是应该有一套本身的设计模式？

有的。以前有一个比较火的石川讲过前端本身的模式。可是咱们前端其实不太有像GOF四位大神同样的这种人物，因此说咱们可能总结的模式都比较弱，这个里面是包含个人。咱们前端仍是一个很年轻的行业，有一些小的模式微模式，其实已是很成熟的。可是达到这个GOF总结的这个23模式这种水平的，我以为客观上会存在，可是我以为我们水平不够还总结不出来。

20.共性问题 数据结构与算法

其实我以为你们把这个数据结构和算法想复杂了，你写For循环是否是算法，它就是一种简单的算法对吧，那你写这个数组他是否是数据结构，固然也是数据结构。在数据结构里，这个玩意叫作顺序表，若是你有数据结构的书，是能找到的。他跟链表相对，因此你去学数据结构和算法学的是什么，这个叫作经典数据结构和经典算法。我不是特别建议你去一个一个的去啃这些经典数据结构和经典算法。可是我建议你提升本身的数据结构和算法的水平。另外一个，其实你们有些时候会把一些公司出的算法题，以为这是不该该考的前端都不须要。在我看来，咱们大部分公司考的所谓的算法题，他都是一个简单的小程序，咱们的代码跟算法没那么容易分开，他很模糊。你说你写一个复杂一点的小程序，他就是一个算法，你写一个简单一点的算法，他就是咱们平常写的一段代码，其实这两个没区别，广义的算法就是全部你写的只要是有逻辑的都叫算法。

21.何泽明提问 WebGL会火吗？感受如今招WebGL的也很少，学WebGL光学three.js能够吗？

我我的很是看好WebGL，这跟three.js实际上是两种东西。我以为这块儿，做为一种知识储备，能够去作一下，固然我是比较推荐资深一点的前端，但愿寻求突破的时候往这个方向去走一走。若是你本身自己在前端基础的CSS HTML JS这些地方都没有拿到优点的话，你不面临瓶颈就没有必要往这个方向去发展。由于你的竞争对手有不少，还有一堆C++大神可能对这边有兴趣要转过来。

22.夏晗默提问 请问老师，本身公司的app 能在chrome 上模拟注入某段代码判断是这个app 么，相似于判断是微信、是支付宝仍是浏览器这种，由于咱们不少h5页面都是内嵌在本身app 中的。

若是你的webview是你本身写的，那必定是能。若是你是要到浏览器里的话，这个也是能够的。你能够注册一段协议，而后拉起本身的APP。打开了以后再回来，因此这个综合的结论是能，不过大家要是打开在本身的webview里，那就很方便。你只须要用密码学手段注册一个特殊的字符串进去，而后让这个好比说跟时间有关的，而后加个签名，而后让网页的代码去判断这个签名就能够了。固然大部分的时候，其实咱们没有这么高的要求，好比说这个淘宝，咱们判断这个页面。是否是在本身的APP里面，其实咱们就加了一段UA，没有我前面说的签名之类的奇特的手段，由于咱们不须要这种安全性检查，咱们只须要判断一下是否是。就是你骗我了就骗我了，也无所谓。

23.半月含雪雨提问 WebGPU要是出来的话WebGL如今还有接触的必要吗？

这个问题关键是我也不太可以回答，就是WebGPU跟WebGL，由于这个事背后有不少政治因素。W3C应该是想推Web GPU，那他们跟Khronos这个标准化组织有一个竞争关系，因此这块其实不是技术问题，我也研究不太明白啊，也可能没人能研究明白。就看他们两大组织如何较力。因此个人建议是你去学计算机图形学，不要把宝押在他们两个身上。

24.tk提问 WebAssembly老师讲过吗？怎么看这个东西？

我讲过这个WebAssemmbly如今有不少的问题，可是整体来说我认为他是一个看好的东西，可是看好到什么程度，其实我刚才讲了，我无法判断他会不会取代到把整个JS都取代了，我以为这可能性不大，但也不是没有，可是总的来讲，我以为若是你以为这个地方可以解决你的问题，你能够多投资一点。这个东西长，确定是会长。能涨到多少钱我就不知道了，跟买股票同样对吧。

25.peter提问 带前端技术团队的时候，如何科学的作绩效评定？或者制定一种和公司员工等级独立开的技术等级的评定机制？

这是人类有公司以来的一个千古难题，叫作如何衡量一个创造性工种的产出。我能够介绍一下我本身的方法，其实很简单。首先，要保证一个初心，就是你评估的时候，不要掺杂任何你不该该掺杂的东西。好比这我的跟你关系很好，这我的他最近刚分手心情很差，那我的家里困难。你评估绩效的时候，你根据你们的工做量去评估，另外先排好，而后再评估。你不肯定的，大家互相比比，你认为这我的好仍是那我的好。

其余

除去整场分享我其余的的一些收获。

必定要学会提问，这样即使是在见识不够的状况，在形式上提升问题的质量，这能让你更有机会和大佬交流。

多关注社区周边的消息，不要闭门造车，我把winter在群里分享的一个截图发到掘金沸点后有很多人问如何进群。

以为不错，欢迎点个赞^_^