去年总结，我在展望新年时做了一个小小的预言，就是2019年会重新进入职场，而直到写年终总结为止，未兑现结果。对于这个事实，我想说的是， 其实一直以来我都是个看重过程实质，而轻视表面上结果的人。比如说，开发者的实质就是技术水平，2018年底，我的软件开发水平是稳定的，随着学习会稳步增长，但是不会突飞猛进。能力是我个人的，进展也是我个人的，跟进不进企业，没有关系。进了企业公司，我只是多一份收入，学习的方向会有所调整，仅此而已，正所谓幸福不会突然降临，我的人个水平，不会因为进了集体有某种跳跃。我不担心是否在职这个事实。
再说，进入了集体，有了保障也会失去一定的得个人自由，商业资本不会让你按自己的想法随意创造的，商业资本会让你用个人自由来兑换收入。 总言之，2019年我个人专业水平是有很大进展的，进职场也是可见未来内可期的。
有一种引人思索的事实，就是在职的开发者不必全知全会，就可入岗；这个事实存在合理性的前提是：
所以更实际的情景是，你的专业技能越来越完满（通过有效的学习），从团队的一个角色跃进到另一个角色。
作为一名JS入门者，如何进阶，从一个次要的角色转变为更有价值的角色，对他们来说非常重要。我以为 Ben McCormick的《Ten Things A Serious JavaScript Developer Should Learn》作了一个尝试，尝试列出了JS进阶的技能清单，我觉得很有趣，于是略译出来。
八月陆陆续续将 Ben McCormick 讲解 Marionette 的系列六篇文章《Marionette: Explained》翻译和学习完成。首先非常感谢作者，给了像我这样的初涉前端应用程序的开发者一个比较全面完整的学习指引。
这六篇文章我还是以我一贯的风格，以略译的形式完成，略译不但不是意译，甚至是笔记式的改写，以自己的语言概念系统重新梳理一遍这些开发知识、技术和理论。
正所谓一百位教师就有一百种教学方法，在略译Ben的文章过程中，除了忽略部分过时的内容，我还以自己喜好的表述方式重组织过内容，并且使用了很多自己提炼的语言和概念。我的理由是，前端应用开发是块热土，各路英雄各举一器，到目前还没一个稳定成熟开发路法，教什么都不确定，如何教更是五花八门。
作为「前端开发者」或「Web应用设计师」，对 单页应用程序（SPA）的形式[注]和逻辑结构[注]有特别细致的了解 是他的专业基础。这些基础知识，有助于作为「开发者」精确的 对（设计方案上的）某种功能设计 进行技术实现，也有助于作为「设计师」更专业的将用户需求转化具体的容易技术实现的设计方案。
注：根据被认识的主体不同（矿物和生物），形式有静态属性，和动态规律，两种；程序是种被动弱智生命；
注：逻辑结构就是质料结构（构造）
「设计案」是设计师和开发者沟通的中间媒体，「设计案」全称构造设计案，Web应用程序（WGP）的构造设计案是对项目需求文档的技术具体，是对程序源码的逻辑概述。WGP构造设计案异常的重要，其制作（由设计师）和使用（由开发者）都是以WGP理论为基础的，是它的一种应用。 
然，这里有个疑问，形式理论如何为「设计案」的基础呢？原因为，「某物理论」可指导认识和制造「某物」，以及「某物」的逻辑模型，逻辑模型就是设计案，算是某物成型的半成品。 「某物理论」可指导可举一个简单的例子，例如，GP界面程序的MVC结构模式，构件关系和构件逻辑都是基于GP理论的。
单页应用程序 发展有一段时间，然而纯粹的完整的 SPA理论[注]，我还没有读到过。本文参考《Master React 2016》的部分与SPA理论相关的内容，我以为还不错，在其基础上丰富一下。
我们现在已经给项目添加了git系统，为 项目管理 打好了基础条件。接下来的一个版本继续完善「构建系统」的形式，并给wgp添加少许复杂度，做一个完整的交互页面。
wgp项目新版本功能计划如下：
至此，「我们的定制系列」有了一定的发展模式——都是给项目的build sys完整形式，并增强功能（注意构建系统和目标应用程序功能是一对一）。「我们的系列」最后的一个目标是定制出高效的「React项目构建系统」，然而由此（简单交互页）至最后目标（React SPA）之间，还有几个版本的「构建系统」，每个版本都计划“生长”些什么，是没有严格指引的。而我们为了更好为了下一个版本作计划，我们需要这种指引。
git版本跟踪系统 可以理解为 build sys的子系统，类似于 测试子系统，因它们共用同一个系统工作目录；然而，git版本跟踪系统 比测试等「build子系统」更具独立性，因为它使用独立的工具或技术基础（git 独立于nodejs）和操作接口（git不使用npm script执行，不是构建任务的一项）。
不管怎样，版本跟踪任务 还是现代软件项目管理、构建、协作和分享的重要一环。在继续给我们的构建系统增加功能之前，先将为它添加版本跟踪系统（或者叫加入到项目管理之中）。
EM：「项目目录」是多个逻辑任务的宿主，版本管理，和软件构建是软件管理并行的两个任务。
相信很多人（包括初学者），无论是通过实践学习程序开发，还是真的开始一项商业软件项目，他们一般直接「使用现成的构建工具」作为新项目的构建工具，例如一些流行的脚手架，或者项目模板。鲜有人细究构建工具的内部构成。原因有几：
而我个人认为还——研究构建工具的构成——是很有必要，这个道理有点像学前端不能只学应用框架（例如react vue），原生JS和浏览器API还是必修的；这是一个理由：了解构建工具内部结构，有助扫除「后继开发构建过程」出现的问题；
第二个理由，虽然构建工具的使用与编程是无涉的，但构建工具是用来「构建」目标程序，「构建工具」的特性与「程序」特性是一一对应的，「认识构建工具」是我们对自己的任务——程序组成的性质——深入认识的一个极好的侧面。
总得来说，构建工具的认识是很有必要的，它能提高我们的专业性——对自己的工具和任务有特别细致的了解。
最近觉得React编程技术学得有一定操作能力，开始转向实操阶段，转向开发环境的学习。第一个任务，是学习和定制构建工具，或构建系统。
然而，名不正，言不顺，在尝试制作一个东西之前，必须对这个东西有一定深度的认识。构建程序，或构建系统 是什么，有什么用，相信有过一定项目经验都不陌生，但并不一定精确；如果你还不能为一个特殊的项目定制 构建系统，直接使用现成的脚手架， 也是你不精通的例证之一。
2020开年很特殊，今年的春节假期长达一个月，整整一个月我都忙着学习React及相关的知识。现在是2月下旬，回想起我是在1月上旬正式宣布正儿八经的学习React，算起来有一个半月，我以为2020春节过后已经进入一个阶段了，值得小结回顾和展望一下。怎么回顾，这个模式我觉得蛮好：
我计划做什么？我从哪里开始的？过程是如何的？我已经走到哪里？下面最值得往哪里去？
ES6新增iterator技术是被高度关注的技术，然，iterator确切是什么技术，解决何种编程任务（方便我们制作什么样的程序功能），又与 generator 技术（generator函数返一个iterator对象实例）是何关系，是一系列相关的重要的问题。
EM：编程任务，与程序本身的计算任务，是不同的。「编程」是（程序员）制作具有某处计算结构的程序存在；「计算任务」是（机器）制作某种需要复杂处理过程的计算结果。
交互页面（网页）不是一张图片、图表或绘画，但是【现代交互页】漂亮的就像一副绘画，层次分明，色彩绚丽，还能响应用户。很难想象一张二维平面作品，背后的（起点）居然是一份结构化的HTML文档。动画不说，光页面格式化和二维空间布局都很复杂，将一条“树”转为一张平面图，CSS和浏览器需要做什么。
“布局”是一种任务（描述），布就是安排，局就是位置空间；按照最新的作业观，布局任务的产出（存在）是一张二维的交互界面，包括局部交互功能组件和全局的交互页。12/19/19 12:34 PM
**「对象」／Object技术**是JS开发中使用最多的技术之一。因为JS应用规模越来越大，对象越来越多（多应用角色，多结构层次的对象），对象的创建和使用应该尽可能的简洁。
ES6对**对象**这个工具作了多个优化改进，让它使用更加方便，和灵活。
本文部分内容择译自《Understanding ECMAScript 6 》。