去年总结，我在展望新年时做了一个小小的预言，就是2019年会重新进入职场，而直到写年终总结为止，未兑现结果。对于这个事实，我想说的是， 其实一直以来我都是个看重过程实质，而轻视表面上结果的人。比如说，开发者的实质就是技术水平，2018年底，我的软件开发水平是稳定的，随着学习会稳步增长，但是不会突飞猛进。能力是我个人的，进展也是我个人的，跟进不进企业，没有关系。进了企业公司，我只是多一份收入，学习的方向会有所调整，仅此而已，正所谓幸福不会突然降临，我的人个水平，不会因为进了集体有某种跳跃。我不担心是否在职这个事实。
再说，进入了集体，有了保障也会失去一定的得个人自由，商业资本不会让你按自己的想法随意创造的，商业资本会让你用个人自由来兑换收入。 总言之，2019年我个人专业水平是有很大进展的，进职场也是可见未来内可期的。
有一种引人思索的事实，就是在职的开发者不必全知全会，就可入岗；这个事实存在合理性的前提是：
所以更实际的情景是，你的专业技能越来越完满（通过有效的学习），从团队的一个角色跃进到另一个角色。
作为一名JS入门者，如何进阶，从一个次要的角色转变为更有价值的角色，对他们来说非常重要。我以为 Ben McCormick的《Ten Things A Serious JavaScript Developer Should Learn》作了一个尝试，尝试列出了JS进阶的技能清单，我觉得很有趣，于是略译出来。
前一课小结SPA理论和工作前提，现在开始本课正题——多页网站改造为单页应用（MPA的SPA改造）。
根据前面的理论的指引，我们的改造概略以下几点：
我们再看看这个常规完整的SPA体系结构图：
服务端交换和 Model都不是必须，本课简单交互功能不需这些组件。
截至上一版本的项目实验，我们实例项目（a-wgp）的项目功能、构建系统和版本跟踪系统 都有了基本的构造，包括：
这些基础功能构造，足以满足一个 由多人协作的中小型动态网站项目 的开发。接着这一版本我们将它转换SPA，一种最基础的SPA程序构造。
作为「前端开发者」或「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：编程任务，与程序本身的计算任务，是不同的。「编程」是（程序员）制作具有某处计算结构的程序存在；「计算任务」是（机器）制作某种需要复杂处理过程的计算结果。