猿急送>

武汉后端兼职程序员

ID：242217

果果

资深后端工程师

公司信息：
石墨文档

工作经验：
11年

兼职日薪：
1300元/8小时

兼职时间：
可工作日远程
可工作日驻场（自由职业原因）

所在区域：
武汉
全区

技术能力

全栈工程师，精通 Java 开发，熟悉的框架有 Spring 全家桶，MyBatis，Hibernate 等等常用 Java 框架；精通 Node.js 开发，熟练使用 express、koa 等 web 框架；熟练使用 ES6；精通 React 开发；对 React Native 和小程序亦有经验。

项目经验

项目名：石墨文档小表格

描述：
石墨文档的文档内插入表格是通过嵌入另一个石墨大表格的方式来实现的，这种实现方式有诸多缺点：

需要加载大表格的庞大 js，且大表格的启动和渲染都很耗时，这就使文档的加载和渲染都变得很慢。在插入多个表格后尤其明显。
大表格不支持单元格级别的实时协作
大表格的单元格不支持富文本
大表格的增删行列等交互不友好，也无法在其基础上改变。
大表格基于 canvas 的实现方式在手机端交互不友好。

因而需要独立实现文档自己的表格，来解决以上痛点。

难点：
文档是基于一个开源文档内核开发的，这个内核机制十分复杂，且只支持一维数据结构，并不支持二维的小表格（当时官方都未有很好的表格实现）。我认真研究其代码后，在上面扩展出了支持二维数据结构的小表格，并实现了产品的所有功能，解决了上面罗列的所有痛点。

项目名：石墨文档历史

项目描述：
石墨文档的历史功能。

由于石墨文档是一个多人实时协作的文档，为了便于追溯和管理文档的版本，需要有历史功能。在文档的侧边栏，可以使用户清晰的看到谁在什么时间做了什么改动，并可以将内容还原到该时间节点。

难点：
一个文档，同一秒，可能有几个不同的人分别在相同或不同的位置进行编辑，如插入文本、删除文本、给文本加粗。怎样将这个操作痕迹记录并展现，是一件非常复杂的事。

项目的协同算法本身就十分复杂，在这个算法基础上实现这个功能，没有一丁点的开源产品或者网上资料可以借鉴，全靠自己设计。

历史的生成是在写文档时实时生成和同步的，为了保证性能，将一些频繁使用的数据用 Redis 做了缓存。

项目名：石墨文档协同模块

描述：石墨文档内核，支持多人同时编辑同一份文档。

难点：
对协同算法毫无经验，需要自己研究。对这个项目涉及到的其他技术如 Node.js、Redis、WebSocket 均无经验。

实时协作模块同时涉及到前后端代码，需要紧密配合，且过程高度精密，一旦某个环节出问题就会导致数据紊乱、文档异常，排查和调试十分困难。

Node.js 当时还很不完善，回调使用起来十分不便，代码难以维护。

项目名：伺动常客 CRM 系统

描述：
公司的 CRM 产品，有会员资料管理、会籍管理、门店管理、礼品管理、兑礼管理、活动管理等模块。主要是基于公司的业务规则写后台接口逻辑 + 前端。

前端基于 ExtJS，界面类似 windows。

后端并未采用当时流行的 strusts/strust2，而是 Spring MVC 3，个人觉得 Spring MVC 3 在当时就已经做的比 struts2 好了，比如配置方便，且请求的参数绑定在方法参数而不是类属性。

项目用 Spring Security 做鉴权。

项目会定时跑一些业务，比如每天凌晨要导入柜点机器的数据同时将更新的资料导出给柜点，每个月的月末要清理过期的会籍，这就要用到 CronJob。并且这个模块是在前端可查看和配置的。

难点：
基于注解的 Spring MVC 3，Spring Security，CronJob 等技术使用方便且实用，当时刚从学校出来，花了很多精力去学习公司的这些技术。

公司的业务比较复杂，如何保证代码尽可能少出 bug 是一件费时费力的事。

项目有很多数据处理是用 sql 实现的，写的很长，要用到游标。而且时常要写 sql 维护线上运行的数据，一旦出错，可能影响很多人，让人神经紧张。

由于之前并未接触复杂的前端框架，ExtJS 算是一个难点。

项目名：伺动常客会员网站

描述：
公司的会员网站产品，主要提供给一些知名化妆品牌使用。使购买化妆品的用户能够在网站上参加活动，查看积分，兑换礼品等。