https://jysperm.me/2016/02/programming-of-2015/
从 2014 岁终最先开辟的一个互联网金融项目终究在本年三月份上线了，这是一个 Node.js 编写的 Web 效劳，但上线仅仅是个最先，今后的半年时刻我们仍在这个项目上举行着麋集地开辟。
就像 2014 年度的手艺小结 中提到的，2014 一全年我都在举行有关自动测试的实践，经由几个项目标积聚，这个项目自始至终都有着掩盖完整的自动测试，我一切的调试事变也都是借助自动测试完成的，我以至没有在自身的电脑上运转过这个项目标前端页面。由于路由层面受营业影响很大，常常修正一些功用的行动，所以厥后大部份测试都是针对 Model 层面的单元测试。
这个项目运用了一种「以数据构造为中心」的设想，所谓数据构造就是一个 JavaScript 的 Object, 对应着数据库中数据表的各个字段，这些代表着营业实体的 Object 在项目中的各个函数之间通报。绝大部份函数的参数和返回值都是这类 Object, 它们在这些 Object 上取得或修正数据，并将这些 Object 与数据库同步，纵然须要通报分外的数据，也是将数据作为属性附加到相干的 Object 上。可以说这是一种非常 JavaScript 的作风，由于这些 Object 非常近似于数据库中的一行纪录，所以在单元测试中很轻易组织，非常大地简化了单元测试中「组织特定环境」的这个步骤 —— 函数的输入和输出都是特定构造的 Object, 这关于 JavaScript 来说太简朴了。
跟着功用的增加，营业逻辑变得愈来愈庞杂，由于 Node.js 强迫 IO 操纵异步的这个特性，异步流程掌握变成了一个使人头痛的题目 —— 直到我发明了 Promise。Promise 是 对异步使命的一种笼统，当我深切地舆解了它的事变道理后，才熟悉到我在进修 Node.js 上走的最大的弯路就是很晚才最先相识和运用 Promise.
比拟于编写 Callback 作风的异步代码，运用 Promise 意味着一种思绪上的转变，虽然 Promise 的道理简朴，但在详细的运用场景上照样须要自身做很多尝试的，比方具有分支的异步逻辑、轮回地处置惩罚数据、逐级通报非常等。
在这个实践的历程当中，我逐渐地将自身的项目中的异步代码改成基于 Promise. 在和 Express 的合营中，我发明由于 Express 没有对 Promise 的支撑，所以 Express 的路由定义现实上变成了 Promise 的「边境」，一切的 Promise 都要在这里举行一次转换，改成 Express 的毛病处置惩罚机制。因而我想假如有一个支撑 Promise 的路由框架将会是一件很风趣的事变，因而我花了几天的时刻设想并完成了 Cichorium, 这是一个代码只需一百来行，基于 Promise 来供应异步中心件和毛病处置惩罚的路由框架。
在运用 Promise 的历程当中，也让我对「非常」有了越发深切的熟悉，非常是当代言语所供应的非常壮大的流程掌握机制，让原本唯一一条一般的、准确的实行途径变得可以从任何一处中缀，并进入一个所谓的非常处置惩罚流程。非常可以包括「预期到的状况」和「非预期的状况」，假如在自身的代码中抛出了非常，那末一般是属于可以预期到的状况，比方参数毛病、前提前提不满足等，抛出非常的目标是为了中缀一般流程，并关照挪用者；而非预期的状况则多是所依靠的库抛出的非常，或因运转时毛病 JavaScript 引擎抛出的非常。
非常会被挪用栈上离非常被抛出处近来的处置惩罚顺序捕捉到，一旦非常处置惩罚顺序「处理」了这个非常，其他的非常处置惩罚顺序就不会再获得关照。所以处置惩罚顺序应当只去处置惩罚已知的、必需在此处置惩罚的非常，然后将其他的非常继续向其他处置惩罚顺序抛出，末了抵达一个「边境」，比方作为 HTTP 响应发给客户端，或打印一条日记。
这个项目在上线早期时刻赶得比较紧，加上履历不足，在上线后的前几个月时刻一向都在遭受机能题目。中心涌现过频频由于并发要求过量，多个要求修正一致条数据进而涌现的数据不一致的状况。原本是有一个经由历程简朴的 Redis 锁限定一个用户同时只能有一个写入数据的要求的机制的，但毕竟不是基础的处理计划。因而我最先尝试运用 MySQL 的事件，将一组相干的 SQL 查询放入一个事件中实行，关于有前提前提的更新操纵（比方扣余额后余额不能为负数），将前提前提作为一个更新前提，假如实行后发明并没有行被更新，就申明前提前提不满足，然后回滚这个事件，向客户端报告失利。借助于数据库供应的原子性和一致性，纵然并发很高，或许顺序崩溃，都不会涌现数据不一致。
运用事件只是处理了在高并发状况下的数据一致性的题目，但并没有处理机能题目。这个项目中的数据主如果财务纪录，用户的每一次操纵都邑天生财务纪录，这些数据被用来追踪每一笔资金的流向，会被聚合起来用于给用户展示统计信息，这个历程须要对数据举行挑选、分组、排序等庞杂的盘算。
明显这些盘算假如在数据库中盘算会有更好的机能，由于不须要在顺序和数据库之间传输大批的数据，而且 MySQL 应当会对这类盘算有更好的优化。因而我最先补习 SQL, 将险些悉数的挑选、分组、排序逻辑都在 MySQL 中完成。同时我最先进修怎样剖析 MySQL 的机能瓶颈，最简朴的就是慢查询日记，曾一度有一些查询须要 300 秒的实行时刻。至于处理计划，除了优化查询前提以外最重要的就是加索引了，我也花了一些时刻来相识索引背地的道理和最好实践。
这些统计数据和时刻是强相干的，过去的数据一般来说就不会再修正了，所以假如可以将这些数据的统计效果缓存起来，将会显著地进步机能。实在原本也有一个简朴的缓存机制，用户接见统计信息后会被缓存，但一旦用户实行任何财务操纵都邑使全部缓存革新。所以很轻易想到的是举行更细粒度的缓存，即在时刻的维度上运用所谓的「套娃娃缓存」，在 Redis 中以天为单元缓存发作的财务更改、当日结束时各项统计目标的值。假如某一天的财务数据发作更改，只需之前一天的数据为基础去盘算今后的数据，大多数状况下历史数据是不会转变的，只会革新当天的缓存。
这项修正消费了不少时刻，由于须要重写一切天生统计数据的代码，在前一天的盘算效果的基础上盘算出当天的统计数据，并连一致些中心效果一同缓存起来，供下一天的盘算运用。相当于将本来一个简朴明了的盘算历程被拆分成了若干个小步骤，步骤之间还须要经由历程 Redis 来交流数据，看似庞杂，但削减了很多没必要要的重复盘算，上线今后将机能进步了差不多一个数量级。
这个项目大概是我这一年完成的最惬意的项目了，我介入到了绝大部份的设想事变中，也完成了差不多一半的编程事变，自始至终都有着完整的自动测试掩盖，借助 Promise 完成硬朗的异步流程掌握和非常处置惩罚，在高并发的状况下实践了事件、缓存、索引相干的学问。
–
我从年终 最先运用 Atom 完成我的悉数事变，挑选 Atom 并不是由于它已经有何等好用了，而是由于 Atom 有着优异的设想和活泼的社区。近来两年我事变都是运用 Node.js 来完成的，而 Atom 也基于 Node.js 和 Web 手艺构建起来的，以至 Atom 也是用 CoffeeScript 完成的，这类雷同的手艺栈，令我非常有「安全感」。我也在相识和进修 Atom 的完成，它有着完整插件化的架构和设想优越的 API, 对我厥后重构 RootPanel 都非常有协助。
在我相识 Atom 的历程当中，我发明中文收集上对 Atom 的议论非常疏散，因而我建立了 Atom 中文社区，到岁终已经有 800个注册用户和 1000 个帖子了。说实话，中文手艺社区的气氛并不好，由于可以手艺才较强或英语水平较高的人会直接挑选去介入官方的社区，如今也基础上是我一个人在回复题目、翻译官方博客和文档、汇总一些材料，不过既然我还在用 Atom, 就会一向将这个社区保护下去。
–
RootPanel 在 2015 年上半年依旧在缓慢地举行着，由于经由历程浏览 Atom 的代码进修到了大批有关插件化设想的要领，所以我这半年并没有向 RootPanel 中增加新功用，而是一向在重复地重构 RootPanel 的架构。
起首是为个中的重要观点竖立笼统，比方效劳组件（MySQL 数据库、Nginx 站点之类）、计费计划（计费周期、价钱、限定）、付出渠道、掌握台上的控件等。之前虽然也有针对这些观点举行笼统，但基础上是写到那里、须要什么接口，就增加一个响应的接口，缺少一个全局性的计划。进而致使笼统出的观点不够简约、不够完全（有一些插件的逻辑仍散落在中心代码中）。
JavaScript 自身是一个很天真的言语，对象自身是「无形式」的，属性和要领都可以随便地修正，也供应了「原型链」来支撑对象之间的继续关联。为观点竖立笼统的一种有效途径就是「面向对象」作风的设想，Atom 就采纳了如许的设想，我以为面向对象关于 RootPanel 可以一样很适宜。
面向对象起首一致了「数据」和「行动」，让数据可以带有行动，而在实行这些行动的时刻又没必要显式地通报数据；对象自身也是一个笼统层级，只需两个对象有雷同的属性和要领（而不管背地的行动），就可以被看成一致种对象操纵，即所谓的「鸭子范例」，这关于插件化的体系而言非常方便。
因而我用了一部份面向对象的作风来重构 RootPanel, 将个中很多观点笼统为了类，为每一个模块起一个适当的名字，削减差别模块之间的依靠；为模块分别「级别」，竖立层级一致的笼统 —— 即在任何一个层级来看，笼统都是完整的，让同层级的类来打交道，而不是将条理不一的类混在一同。
–
在 2014 年我就一向对 Mongoose 有很多不满，一向想自身造一个轮子，在 RootPanel 的开辟历程当中也遇到了 Mongoose 的一些坑和一些难以完成的需求，因而本年终究行动起来了，然后就有了 Mabolo —— 一个轻量级的 MongoDB ORM。
我对 Mabolo 的定位是一个简朴的、「没有魔法」的 ORM, 每一个 Model 都是一个一般的 JavaScript 组织函数，而每一个文档则都是由这个组织函数天生的实例 —— 除了几个用来保留内部状况的不可枚举属性以外和一般的对象没有任何区分。Mabolo 不去追踪数据被转变的状况，而是勉励运用 MongoDB 的原子操纵符举行数据更新，Mabolo 仅在更新后帮你将最新的数据同步到这个对象上。
嵌套对象是 MongoDB 的特征之一，在现实项目中也常常会用到如许的设想，因而我也为 Mabolo 增加了嵌入式对象的支撑，许可将 Model 中某个字段的范例设置为另一个 Model. 在贮存到数据库前会运转一切子 Model 的考证要领，在从数据库掏出效果后会为每一个子 Model 字段组织响应的对象，以便在这些子 Model 上运转更新和删除等要领。
–
五月初的时刻和 Yeechan 等人列入了 SegmentFault D-Day 上海站 的运动，重要听了有关 Docker 和 React 的主题分享。
由于我开辟 RootPanel 的履历，对 Docker 这类机能斲丧极低的假造化手艺天然非常感兴致，在列入此次运动之前就去简朴地相识过 Docker, 当时我对 Docker 的不解重要在于 Image 只能单继续，如许就不太轻易像「搭积木」一样去组合自身想要的环境，这多是由于文档上面谁人搭积木的示意图对我的误导比较大。
经由此次的主题分享，我才比较周全地相识到基于 Docker 去布置运用的思绪，即既然建立容器的成本是极低的，那末可以为体系中的每一个部份去建立零丁的 Image, 运转零丁的容器，然后经由历程 Docker Compose 这类东西去组合容器。Dockerfile 形貌了运用的运转环境和依靠项，而 docker-compose.yml 形貌了怎样将一个体系中所须要的各个部份组合起来，完成了关于一个体系的完整形貌。在现实运转时，由于容器之间的联络非常少，一般只暴露几个收集端口，所以给全部体系带来了非常好的横向拓展的才，体系的每一个部份都可以会运转多个容器，以至这些容器可以会散布在差别的物理效劳器上，同时供应一致的效劳。
由于 Docker 是内核级别的假造化，对体系挪用的笼统代价很低，而由于运用了 AUFS 对文件体系举行笼统、须要竖立假造网卡举行端口转发，所以磁盘和收集 IO 的笼统开支相对较大。所以 Docker 更适合盘算麋集型、依靠庞杂（如许才发挥 Docker Image 的上风）的顺序，就是一般 Web 项目中担任处置惩罚要求的「运用」这部份，而将数据库等 IO 麋集、布置简朴、不频仍晋级的顺序直接布置在物理机上。
如今 Web 后端顺序面对的重要应战就是高并发，保证单个顺序的稳定性，倒不如采纳散布式的架构，将一个处置惩罚才强的实例拆分为若干个处置惩罚才较弱的实例，转而保证一旦有实例失效，可以马上从新建立一个实例代替它继续事变。但假如在实例中贮存了一些全局的状况（比方锁）就没法经由历程启动多个实例的体式格局来横向拓展。所以比较抱负的实践就是将运用完成为「无状况」的，即容器中的运用只依据来自收集的要求举行盘算，对数据库、缓存和文件体系的挪用一样经由历程收集去要求容器外部的效劳。如许才可以进一步应用 Docker 的上风 —— 容器可以依据范围须要随时去在差别的物理机上建立和烧毁而不须要同步数据。
跟着对 Docker 相识的深切，我最先意想到 Docker 对 RootPanel 这类 PaaS 平台是一个「杀手级」的运用，像 RootPanel 那样愚笨地运用一系列 Linux 的机制和东西去断绝用户和直接运用 Docker 比拟毫无上风，让我很有将 RootPanel 改成基于 Docker 的架构的激动。但想来想去照样摒弃了这个主意，由于一方面这个修改可以会非常大，另一方面实在已经有了很多非常优异的基于 Docker 的开源 PaaS 顺序了。
厥后我到场 LeanCloud 担任云引擎的开辟事变，云引擎现实上就是一个基于 Docker 的 PaaS 平台，各方面都和 RootPanel 非常类似。既然一样平常的事变已经是如许一个项目了，所以进一步促使我中断了 RootPanel 的开辟。但说实话我对 PaaS 还依旧有兴致，或许有一天我会依据我在 RootPanel 和 LeanCloud 的履历，从新设想一个最简架构的 PaaS 来留念 RootPanel.
跟着在事变中深切地相识 Docker, 在岁终的时刻我将我的效劳器上运用悉数换成了基于 Docker 来运转，如许的优点就是每一个运用都可以有自身的环境，而且每一个效劳的环境和效劳之间的依靠关联都被形貌在了 Dockerfile 和 compose.yml 中，完全处理了之前效劳器上种种运用「杂乱无章」的征象，今后若要迁徙效劳器或从新布置将会变得非常轻易。
–
过去一年我花了不少时刻断断续续地将「JavaScript 威望指南」和「盘算机顺序的组织和诠释」看完了，对 JavaScript 的相识也进了一步，实在 JavaScript 对函数式作风的代码照样有很不错的支撑的。按我在 JavaScript 中对函数式编程的实践，最有代价的的两点就是「无状况」和「无副作用」。
跟着前端运用愈来愈庞杂，所展示的数据之间的逻辑关联也愈来愈庞杂，也涌现了很多框架来处理前端 UI 和数据（即状况）之间的同步题目，个中之一的 React 从一个非常风趣的角度来入手 —— UI 可所以运用状况的一个函数，给定一组状况就有一个肯定的 UI. 假如每次状况发作变化都从新衬着全部 UI, 便可以极大地下降治理 UI 和 状况的庞杂度。
React 还在浏览器供应的 DOM 上竖立了一层笼统，在每次从新衬着 UI 时，React 操纵的都是 Virtual DOM, 然后再去与真正的 DOM 举行对照，更新必要的部份。我以为这类笼统照样非常有代价的，Virtual DOM 限定了很多操纵，但它供应了优化机能的空间，也为将 React 顺序迁徙到非 Web 平台供应了可以性，比方厥后我就尝试过在效劳器端运用 React 来衬着 HTML.
厥后我在 RootPanel 和其他一些项目上试验性地运用了 React, 我也运用了官方引荐的 JSX 来编写代码，React 这类将 JavaScript 作为运用主体的做法很差别于一些将 HTML 作为运用主体的框架。有一些人指摘 JSX 将这些年非常困难才脱离的 HTML 和营业逻辑（JavaScript 代码）又从新混在了一同。而我则以为「模板言语」的涌现一方面是由于部份言语表现才较弱，须要模板言语将 HTML 和噜苏的语法细节星散；另一方面则是试图在数据和冗杂的 HTML 表现之间竖立一层笼统。JavaScript 原本已有很不错的表现才，JSX 又增加了一些与 HTML 相融会的语法；React 经由历程引入「组件」的观点来拓展 HTML 的标签，让用户可以自身建立包括内部逻辑和状况的标签，进而让 HTML 表现不再冗杂，所以星散就变得没必要要了。
总体上来说我对 React 很有好感，由于我以为 React 很好地完成了一些函数式编程的作风，来简化 UI 编程中对状况的治理，React 勉励将组件设想为无状况的，同时将衬着历程设想为无副作用的，如许不管什么时候，只需状况发作转变就从新衬着全部 UI 即可。
在我厥后编写 LeanEngine Snipper 的时刻，须要在前端举行大批数据处置惩罚以便依据用户的挑选来展示图表。一最先没有斟酌太多，部份函数是会修正其参数（往往是一个包括大批对象的数组）的，在厥后支撑用户修正挑选前提时就遇到了题目 —— 原始数据在画图的各个环节中都有可以被修正，不能不在最先画图之前对原始数据举行一次 clone, 在厥后的机能剖析中发明 98% 的时刻都消费在了 clone 上面。
因而我不能不重构代码，让大部份函数不修正参数，而是在参数的基础上返回一个新的对象，将须要 clone 的数据削减到了最小，经由此次的优化，挑选的机能进步了 40 倍以上。从直观感觉上来看，每一个函数返回新的对象会斲丧更多的资本，但在 JavaScript 中，返回新对象现实上只是在拷贝它的属性的援用，并不会消费若干时刻，反倒是在 clone 对象时须要遍历一切的属性，才须要消费大批的 CPU 时刻。
–
由于近来两年都在运用 Node.js, 我愿望也运用 Node.js 来驱动我的博客，我末了挑选了插件化架构的 Hexo —— 一个静态博客天生器，我自身编写了 主题，并将博客的数据也托管在 GitHub 上。厥后我将 RP 主机博客、粉丝团主页 也都迁徙到了 Hexo, 厥后新建的 京彩豆腐的博客 也运用了 Hexo.
–
本年我作为 HackPlan 的成员，介入了频频雇用，厥后我也作为求职者列入了频频口试。
外洋的一些职业，包括大夫、状师，也包括工程师，都普各处去打造自身的个人品牌，目标是为了找到更好的事变。确切在过去两年中这类个人品牌对我的事变是很有协助的，在我口试的历程当中，我去的险些一切公司的口试官都示意曾听说过我。虽然说手艺岗亭以才为先，但至少假如混个脸熟，两边会有一个基础的信托。
我当时说在找到事变今后会和人人分享一下列入口试的履历，但厥后想了一下，写出来的话应当都是关于我没有挑选的那些公司的负面评价，人人都是偕行，如许不是很好，所以厥后只写了 到场 LeanCloud 的历程。
–
说实话，如今运用 Node.js 的公司依旧是少数，因此在求职时我也将 PHP 纳入了斟酌。在我脱离 PHP 今后，社区发作了很多变化，涌现了像 Laravel 如许设想优异的一站式框架，composer 这个包治理器也被愈来愈多的人接收。为了从新捡起 PHP 这个妙技，我花了一些时刻用 Laravel 做了一个最简朴的论坛体系的轮子 —— labbs-laravel.
在之前，不管是 PHP 照样 Node.js 中，我都没有运用过像 Laravel 这类重量级的框架。Laravel 差别于国内一些粗制滥造的重量级框架，虽然它供应了很多功用，但却并不显得痴肥。起首 Laravel 并没有挑选造轮子而是构建在 搜刮效果 Packagist 中已有的包之上，它有着一个非常精简的中心架构，除了典范的 MVC 支撑外，其他的各种功用（认证、缓存、行列）都被笼统成了「效劳」，这些效劳可以自力为零丁的包宣布在 Packagist 上，且同类的效劳是可以相互替代的。
Laravel 对我来说最大的亮点是 ORM 部份（Eloquent），我之前用过的 ORM 比较少，在完成 Mabolo 的历程当中一向在纠结怎样完成对象之间的援用关联。Eloquent ORM 将关联自身也笼统为了一个类，当你接见一个对象的关联字段时，获得的是一个「关联对象」，你可以在这个对象上举行挑选和查询等操纵。实在如许的设想照样非常直观的，但由于我之前闭门造车，一向没能「自力发明」，在新的一年中我会用如许的思绪去给 Mabolo 增加关联支撑。
–
末了假如做个总结的话，我这一年依旧重要在编写 Node.js 代码，也写过少许的前端代码，对 JavaScript 的相识愈来愈深切。这一年的我在关注基于 Promise 的异步流程掌握和毛病处置惩罚、深切相识关联型数据库和 SQL、探究函数式作风的 JavaScript、探究和进修插件化架构的设想、借助 Docker 来治理运用的布置和拓展。
