近期我们计划对Scratch3.0做一系列的技术分析，这是这个系列的开篇。

我们致力于实现以下目标：

  • 理解Scratch3.0的架构设计
  • 理解Scratch拥有强大兼容性的原因
  • 梳理Scratch3.0产品背后使用的一些设计原则
    • 表现与实现的分离
    • 事件驱动
    • 面相对象
    • everything is a message
  • 按照Scratch一贯的设计原则，独立实现Scratch并未开源的部分。确保之后能随着Scratch一同升级，架构上保证向后兼容。
  • 顺着Scratch的思路，对Scratch作出改进。

总而言之，我们希望通过这些分析，获得定制scratch的能力，但同时又能与上游的官方版本保持兼容。我们重视官方对Scratch的改进。与其说我们重视他们技术能力，不如说我们重视他们对教育和社区的深刻理解，这些是极为稀缺的，它不是技术问题，也不是资金问题。我们希望能随时将官方的改进merge回我们调整后的项目中。我们不希望做出硬分叉。

Scratch3.0 正式发布

Scratch3.0于2019.1.2如期而至。

Scratch3.0的GUI和社区的前端都已开源:LLK。

你可以在线体验一番.

目前Scratch3.0团队没有透露社区后端和GUI的存储部分是否有开源计划(我们之后将这两块统称为后端)，我此前和Scratch3.0后端团队成员做过沟通，他提到Scratch3.0后端目前同时采用了新构建的REST API和之前遗留的Django server。他们陆续将一些基础服务从Django中迁出，转化为API对外提供服务。从我们之后的分析中可以知道，他们新的后端基于restify。我想官方的技术选型主要出于restify对REST的友好支持，以及restify应对高负载的能力，毕竟Scratch社区有3000万用户。

考虑到Scratch2.0的后端并未开源，3.0社区后端开源的概率估计也不大。个中原因可能是防止社区分裂。毕竟每家公司跑一个scratch社区挺奇怪的，它分裂了用户群。更何况，大多数的公司采取的教育策略，正是《终生幼儿园》所反对的。

除了Scratch3.0的社区后端，Scratch3.0的其他部分，官方都有计划开源，包括desktop，终生幼儿园小组正在和MIT校方沟通推进这件事，这些信息在scratch团队日常的讨论中有提到。

为何做这个分析

Scratch3.0的社区与插件系统，将开放到什么程度？官方的计划是什么？目前scratch团队并没有给出明确说明.他们在FAQ中提到说这部分的工作还在进展中。

我们(codelab.club)今年(2019)上半年有计划与scratch team碰个面，如果官方接受，我们希望将codelab-adapter集成到官方项目中。帮助Scratch3.0连接到更广阔的世界(education as life)，同时建立Scratch3.0与Python(或者任何其他语言)的无缝连接。如果官方没太大合作意愿，也不愿开放接入机制，我们将独立构建用户社区。我们仍鼓励用户使用scratch官方社区（如果网络顺畅），因为那里边有丰富而友好的的人群，海量的不可思议的创意项目，以及scratch团队令人称赞的运营方式。但对于那些官方不支持的创造，尤其是与生活相关的创造(education as life),我们将提供另一个社区来支持用户。我们的目标是让万物积木化，支持更广泛的创造。支持杜威提倡的

education as life

我们关注如何构建出兼容官方已有开放项目的后端，让用户保持一致的使用体验。同时也保证我们随时可以merge回官方的最新进展。我们另有一个野心是在我们的实现中加入activitypub，让scratch的社区数据，轻松支持跨站共享和分布式存储。 codelab.club是一个非营利组织，这是我们希望支持落后地区的一个举措。让我们设想一种场景，在贫困山区，网络并不通畅，如何帮助那儿的孩子接入到社区中？他们如何了解社区最近创造出的有趣的项目(projects)？而peers和projects是scratch很核心的2个概念。有了activitypub，我们在山区中可以使用树莓派跑一个scratch社区后端，孩子们可以在局域网内形成社区（一台树莓派即可，树莓派可以发射热点构建局域网）。当志愿者到来，开放出手机热点，activitypub将为他们把外部世界的数据同步进来。很多的手机卡已经几乎免流量了。这件事没有想象的那么困难，即便在经济上也没有。

activitypub可能起作用的场景当然远不止贫困山区。关于这块的可能性有空在谈。

为了支持我们上边提到的所有目标。我们需要分析目前官方的后端API（其他开源的部分我们也将分析）。我们看到scratch为兼容性这块付出了巨大的努力，他们精心设计了数据的结构，他们花了很大精力来保持对旧版本的兼容，他们甚至希望兼容到1.4版本(十年前的项目！). Scratch团队始终不抛弃已有的用户和用户创作的项目，很难看到比scratch team更尊重用户作品的组织了，这是一群令人肃然起敬的教育者。

整理已有的Scratch API相关文档

社区里目前有不少Scratch后端API相关的文档和项目。

在此做个梳理。

这些项目是Scratch2.0的API，但Scratch3.0和2.0的API基本是相同的。主要原因我们前边有提到: 出于兼容性的考虑。

我在完成这篇文章的途中，也会顺手给出scratch3.0的api文档，如果时间允许，我还将给出Python实现的Scratch client。

此外，也可能顺手实现Python版本的scratch-parser，这个工具将来会成为我们为scratch用户制作画像的基础，由于Python社区的数据分析生态最成熟，所以我计划用Python来做。评估Scratch用户的学习效果，以及用户对知识的掌握情况，我认为目前是项目驱动的平台（如scratch）存在的痛点。我们希望这个项目支持所有Scratch平台，只要大家兼容官方的数据结构即可。这就是我们如此重视兼容性的原因，因为这样有助于打造通用的工具链。

评估学习者的学习进展并不容易，我认为对程序的静态分析可能是突破口之一，所以我们需要重新实现scratch-parser。在静态分析的基础上，加上一些机器学习的算法和推荐系统，将来甚至可以做到，针对用户的学习情况和兴趣点，给他推荐可能感兴趣的人与项目。如此一来，线上平台就部分实现了我们希望在club中实现的东西：帮助用户去寻找和发现感兴趣的projects与peers。

工作计划

我们的分析工作从创作平台开始。

之后转向分析社区。

我们相信这一系列的文章对于准备使用Scratch3.0作为公司基础项目的产品经理和系统架构师会有价值。

文章列表

截止到2019.05.01这个系列的分析文章基本写完了,整理如下: