12月末：

嗯。。。又是个搞事情的冬冬；

先理解下使用的场景

1. 获取数据

实现一个简单的page，用到了多个组件嵌套，每个组件都可以通过fetch去获取数据，当然可以在最顶部获取所有数据再渲染。

a. 每个组件都自己获取数据，没有问题，但需要发茫茫多的请求；（性能）

b.顶部获取数据，没有问题，就是维护起来会很累；（可维护性）

所以，Server Components 解决了数据获取的问题，让数据和component在服务器端进行组合，直接展示；

2.ssr

服务器端渲染免不了提一下ssr，ssr最早起源于解决首屏白屏和seo的问题，也就是服务器端返回的是html；

Server Components 返回的是序列化的“指令”，所以和ssr没半毛钱关系；

另外纠结了下“渲染”两个字的含义，Server Components 算不上是服务器端渲染，我们常说的渲染往往支持转换为html，Server Components 应该理解为build更合适，build成序列化“指令”；

啊，这是个性能不错、可维护性强的解决方案，用户体验？？额，我感觉用户体验就体现在前两者上面了。
那么，沉思。。。这东西到底有什么好的使用场景呢？？？

1.组件即服务

以前拿数据只能通过后端提供的api，还要自己去组装，现在不用了，直接拿来，例如图表；

2.报表（BI）

组件即服务的延伸，可以直接获取报表；

3.组件中台

业务中台，从数据中台进化为组件中台；

4.开箱即用

5.降低服务器的并发压力

6.提速提速！！！

最后，如何实现，demo在哪里？？看官网吧，我还没尝试。。。

什么是设计模式？

“设计模式”这个术语最初并不是出现在软件设计中，而是被用于建筑领域的设计中。

设计模式是对软件设计开发过程中反复出现的某类问题的通用解决方案。

设计模式更多的是指导**和方法论，而不是现成的代码，当然每种设计模式都有每种语言中的具体实现方式。

狭义的，常见的设计模式有 23 种经典设计模式。

设计模式的类型

设计模式有两种分类方法，即根据模式的目的来分和根据模式的作用的范围来分。

1. 根据目的来分

根据模式是用来完成什么工作来划分，这种方式可分为创建型模式、结构型模式和行为型模式 3 种。

• 创建型模式：处理对象的创建，完成“将对象的创建与使用分离”。

• 结构型模式：处理对象间的逻辑和关系，完成简化系统的设计。

• 行为型模式：处理多个对象之间的交互，共同完成单个对象都无法单独完成的任务。

2. 根据作用范围来分

根据模式是主要用于类上还是主要用于对象上来分，这种方式可分为类模式和对象模式两种。

在ES6中，class (类)作为对象的模板被引入，可以通过 class 关键字定义类。class 的本质依然还是 function。

它可以看作一个语法糖，让对象原型的写法更加清晰、更像面向对象编程的语法。

本次讲解暂时不以类和对象的区别展开。

3. 23 种设计模式的分类表

前端常用到的几个设计模式

创建型模式

1. 单例模式（Singleton Pattern）

顾名思义，单例模式中Class的实例个数最多为1。从前端比较好处理，每个对象、匿名函数都可以看做是一个单例。

var singleton = {
    attr : 1,
    method : function(){ return this.attr; }
}
var t1 = singleton ;
var t2 = singleton ;
// true
t1 === t2

2. 工厂模式（Factory Pattern）

工厂模式是用来创建对象的一种最常用的设计模式。对象实例化过程通过工厂实现，用工厂代替new的操作。

工厂模式根据抽象程度的不同可以分为：简单工厂，工厂方法和抽象工厂。简单工厂其实不是一个标准的设计模式，23 种设计模式中只有工厂方法和抽象工厂。

2.1 简单工厂

为了方便理解简单工厂，用了匿名函数实现工厂函数。

class Dog {
  constructor() { console.log("泰迪犬") }
}
class Cat {
  constructor() { console.log("波斯猫") }
}
// 工厂函数，能根据不同的参数创造不同的动物
let CreateAnimal  = (type) => {
  switch (type) {
    case "dog":
      return new Dog();
      break;
    case "cat":
      return new Cat();
      break;
  }
}
// 利用工厂创建对象
let dog = CreateAnimal('dog');

2.2 工厂方法

工厂方法模式是对简单工厂的进一步优化， 在工厂方法模式中，不再提供一个统一的工厂类来创建所有的对象，而是针对不同的对象提供不同的工厂。

// 工厂函数，能创造一个随意动物的工厂，每个动物能讲自己的名字
class CreateAnimalFactory {
  constructor(type){
    console.log("我创造了物种：", type);
    return class {
      constructor(name) { this.name=name }
      say() { console.log("我的名字叫做",this.name) }
    }
  }
}
// 创建自己的工厂
let dogFactory = new CreateAnimalFactory ('泰迪犬');
let dog1 = new dogFactory("tom");
// 我的名字叫做 tom
dog1.say();

2.3 抽象工厂

抽象工厂模式是对工厂方法的进一步优化， 在抽象工厂模式中，在针对不同的对象提供不同的工厂基础之上再抽象一层，形成一个类别，例如从“泰迪犬”工厂抽象成“犬科”。

结构型模式

1. 外观模式（Facade Pattern）

外观模式是将复杂的操作进行封装，对外提供一个简单的方法或者接口。比如JQuery就把复杂的原生DOM操作进行了抽象和封装，并消除了浏览器之间的兼容问题，从而提供了一个更高级更易用的版本。

我们常用的框架和库基本都遵循了外观设计模式。

// 兼容性事件绑定函数
function addEvent(element, event, handler) {
  if (element.addEventListener) {
    element.addEventListener(event, handler, false);
  } else if (element.attachEvent) {
    element.attachEvent("on" + event, handler);
  } else {
    element["on" + event] = fn;
  }
}

行为型模式

1. 策略模式（Strategy Pattern）

策略模式简单描述就是：对象有某个行为，但是在不同的场景中，该行为有不同的实现算法。

最常见的使用策略模式的场景如登录鉴权，鉴权算法取决于用户的登录方式是手机、邮箱或者第三方的微信登录等等，而且登录方式也只有在运行时才能获取，获取到登录方式后再动态的配置鉴权策略。

// 登录控制器
function LoginController() {
  this.strategy = undefined;
  this.setStrategy = function(strategy) {
    this.strategy = strategy;
    this.login = this.strategy.login;
  };
}
// 用户名、密码登录策略
function LocalStragegy() {
  this.login = ({ username, password }) => {
    // authenticating with username and password...
  };
}
// 手机号、验证码登录策略
function PhoneStragety() {
  this.login = ({ phone, verifyCode }) => {
    // authenticating with hone and verifyCode...
  };
}
// 第三方社交登录策略
function SocialStragety() {
  this.login = ({ id, secret }) => {
    // authenticating with id and secret...
  };
}

const loginController = new LoginController();
// 调用用户名、密码登录接口，使用LocalStrategy
app.use("/login/local", function(req, res) {
  loginController.setStrategy(new LocalStragegy());
  loginController.login(req.body);
});
// 调用手机、验证码登录接口，使用PhoneStrategy
app.use("/login/phone", function(req, res) {
  loginController.setStrategy(new PhoneStragety());
  loginController.login(req.body);
});
// 调用社交登录接口，使用SocialStrategy
app.use("/login/social", function(req, res) {
  loginController.setStrategy(new SocialStragety());
  loginController.login(req.body);
});

2. 迭代器模式（Iterator Pattern）

迭代器模式主要的**就是在不暴露对象内部结构的同时可以按照一定顺序访问对象内部的元素。前端还是有很多遍历方法的，比如forEach，every，find，some，map，entries等等。

3. 观察者模式（Observer Pattern）

观察者模式又称发布订阅模式（Publish/Subscribe Pattern），是前端经常接触到的设计模式。被观察对象（subject）维护一组观察者（observer），当被观察对象状态改变时，通过调用观察者的某个方法将这些变化通知到观察者。

最常见的就是动态绑定。Redux、Vuex的设计实现中也存在观察者模式，对数据store的订阅。

target.addEventListener(type, listener [, options]);

此为《硝烟中的scrum》内部团队实践整理。

实践之前的方案

在建设初期，团队通过开源的gitlab搭建项目内部源码库，然后利用项目自身的issues来完成任务派发，bug修复，功能迭代等，实现了初步的研发跟踪和管理。

为什么能做到？因为issue体现了项目backlog的功能。开发人员通过相关issues，理解需求，计算估时，追踪任务。还通过tag进行优先级划分。

展示下传统backlog的样子：

实践

1. Sprint会议

举行Sprint会议，产品负责人一般会先概括一下希望在这个 sprint 中达成的目标，还有他认为最重要的故事。接下来，团队从最重要的故事开始逐一讨论每个故事，并估算时间。

总结上一个Sprint会议的问题：估时问题！

Sprint 计划会议议程（9:00 – 11:00）

• 9:00 – 9:15，测试人员对测试情况进行反馈。安全人员对安全情况进行反馈。
• 9:15 – 9:30，团队回顾上个迭代完成的情况。
• 9:30 – 10:00，产品负责人对 sprint 目标进行总体介绍，概括产品 backlog。定下演示的时间地点。
• 10:00 – 10:30，团队估算时间，在必要的情况下拆分 backlog 条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的 backlog 条目都要填写“如何演示”。
• 10:30 – 11:00，团队选择要放入 sprint 中的故事。计算生产率，用作核查工作安排的基础。

用在线 Excel 来管理产品 backlog 很不错，不过你仍然需要一个 bug 跟踪系统（后续引入了测试平台，由专门的测试人员维护）。

2. 站立会

站立会包括如下议程：

1. 对已有任务的一个推进情况反馈，每个人把各自的任务推进情况核对一下。（转变为测试人员对测试情况进行反馈）
2. 对衍生任务的新增情况进行反馈，包括任务拆解。
3. 对互助，沟通问题进行处理。
   估时10分钟

第一次站立会召开，会出现工具不太齐全，流程团队尚未清楚。所以会超时。估时20分钟。
可以事先准备一下，衍生任务或者任务拆解两种情况形成的任务，单独整理（上便利贴）。

3. Sprint 回顾会议

方式一

Sprint 回顾总结会议议程（9:00 – 11:15）
• 9:30 – 9:45，产品负责人对本次 sprint 成果进行总结，给出一个整体性的评价。
• 9:45 – 11:15，根据《团队建设复盘分析》在线表单反馈问题的情况逐一分析，留存好的问题及处理方案，加入下一个迭代的工作中。

方式二

Sprint 回顾总结会议流程预设

会前数据收集

1. 收集本次sprint的大事记；
2. 收集新员工自我介绍ppt，整理些进入团队的心得体会，包括工作中的缺点和改进方案。大家能更好的了解团队，了解彼此，加强友谊，发现问题，解决问题，提供团队的融合度和工作效率；
3. 收集团队所有成员对本次sprint的心情（例如愤怒、开心、忧伤）或者一个词描述（例如完美、不爽）；
4. 收集团队所有成员对本次sprint的问题；
5. 收集感谢卡，感谢xxx在本次sprint中对我的帮助，因为xxxx（简短的事情描述）。

会议流程

• 14:00 – 14:30，宣布本次迭代成绩。
• 14:30 – 15:00，下一迭代的计划。
• 15:00 – 16:00，分析本次迭代的问题。
• 16:00 – 16:30，分发感谢卡。

考虑秀迭代卡

首先介绍一下Zepto：

1. 它是一个轻量化的，API类似jQuery的javascript类库。
2. 它是一个面向移动端的类库，虽然能在桌面客户端运行，不过仅支持高级游览器（IE10+）。
3. 它支持移动端“touch”有关的一些事件。

简单的介绍完Zepto之后，我们再谈谈它和jQuery之间的区别，从功能先入手，之后会讲到大家纠结的大小，效率等问题：

1. 选择器的区别；Zepto实现了一些基本的选择器，排除了部分选择方式。其中不支持的有：

   • 基本伪类选择：:first、:not(selector)、:even、:odd、:eq等通过“:”来实现选择方式。
   • 属性选择：[attribute!=value]。

2. 宽度和高度的区别（以宽度为例）；

   a. 首先介绍jQuery的几种取值方式：

   • .width()，返回内容宽度；

     

   • .css('width')，同上，不过返回的是带完整单位的字符串。

   • .innerWidth()，返回带padding的内容宽度；

     

   • .outerWidth(boolen)，有两种情况，默认返回带padding以及border的内容宽度；当传参数“true”时，返回值将包含margin；

     

   b. 接下来介绍Zepto的取值方式，它只提供了两种：

   • .width()，返回带border，padding的内容宽度，和jQuery里面的.outerWidth()一致。
   • .css('width')，和jQuery的方法一致。

   c. 综上所述：

   • 想要通过Zepto获取内容宽度，需要通过$(elm).css('width').slice(0, -2)来实现。
   • 其他的距离以此类推。

3. Zepto的.offset()包含4个属性值，比jQuery多出了width和height的值。当然这个width和height同样是包含border以及padding的内容宽度。

4. Zepto的animate只使用css过渡效果动画（所以游览器一定要高级），对于jQuery的easings不会支持。jQuery的相对变化（"=+10px"）syntax也不支持。同时Zepto拥有总的动画设置$.fx，设置即时生效。详细可以了解官网文档。

5. 其他经常性用到的区别可以这里补充，如果不怎么用到的，毕竟类库本身就不同，没必要做到那么细致的了解。

功能性的问题就对比到这里。接下来对比一些纠结性问题，这些问题的分析能帮助你如何去取舍：

1. 生态圈问题。jQuery拥有成熟的生态圈，能在网上找到一大堆相关的控件以及框架，遇到困难也能在社区当中寻找答案。很多招聘信息一般性也都会加熟悉jQuery等信息。这些都是Zepto所缺乏的。当然这也阻止不了Zepto使用者的热情，哪个工具不是经历从无到有的过程的。造成这个问题的原因我觉得可以有这几点：

   • 时间问题。Zepto出生于2010年10月末，对于出生于2006年1月的大哥jQuery小了将近5年的时间。先行占领市场的肯定能多分杯羹了。
   • 市场问题。Zepto的本意就是使用于移动端，但是移动端的发展近几年才迅猛起来。同时jQuery又出来了一版jQuery.mobile，所以很多人开发控件的时候一般性都会去选择jQuery。导致这么一个小弟一直被放在一边默默无闻。

2. 大小问题。Zepto的体积很小，压缩之后只有25k。因为Zepto支持移动端事件的特性，相当于jQuery（98K）和jQuery.mobile（198K，一般性连着UI一起用了，所以也不会少）的集合。虽然4G年代来了，上百KB无所谓了，优化个图片就有了，不过国内流量那么贵，依然需要省省用的。

3. 性能问题。Zepto的性能略差于jQuery；不过通过数十万的计算得出一个百分之几的差距，实际使用中很少会出现。而且目前移动端游览器都如此先进，就跟上面的大小问题一样，还在出那么点性能么。

4. 跨平台问题。想制作跨平台响应式的网站，不需要多想，请使用jQuery吧。jQuery以其优良的兼容性完胜了仅支持IE10+的Zepto。

5. 更新问题。大哥jQuery还在不停更新当中，小弟Zepto官方最后一次更新是在2013年12月初。

总的来讲，虽然在移动端使用Zepto占据很大优势，不过限制于各种原因，它还有很长的路要走，譬如“点透”等问题还未解决。