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

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

关于组件

引言

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

正文

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

但是，HTML本身的目标，是标准化的语义，既然是标准化，跟自定义标签名就有一定的冲突。所以从前端最早出现的2005年，到现在2019年，我们一直没有等到自定义标签这个功能，至今仍然是Draft状态。

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

封装：组件屏蔽了内部的细节，组件的使用者可以只关心组件的属性、事件和方法。
解耦：组件本身隔离了变化，组件开发者和业务开发者可以根据组件的约定各自独立开发和测试。
复用：组件将会作为一种复用单元，被用在多处。
抽象：组件通过属性和事件、方法等基础设施，提供了一种描述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在群里分享的一个截图发到掘金沸点后有不少人问如何进群。

觉得不错，欢迎点个赞^_^