我用三个月时间仿造了一个稿定设计 | 2022年中总结
项目の初
该从哪里说起呢。。回想当时我还在做着一些零散的项目需求，这时候领导给了我一个任务，说让我重构一个“在线PS”，我一听哎，这有点意思了，但是它并没有立项，是的，直到我做了一个多月，团队里还没有其他人知道这个项目的存在，所以我要在搞完其他需求之后挤出来的时间里完成它的开发（因为连PM都不清楚我在搞这个），而且领导表示虽然我们不ToC，但要向稿定设计这类产品看齐。我就在这样一个没有产品、没有UI、研发只有1人、开发工时约等于没有的情况下，在追逐竞品的无限挫败感中，勉强完成了第一版的开发。
第一版的样子，肉眼可见的粗糙。公司是vue2技术栈的，一开始出于惯性也用vue2搭建项目，做了一小段时间感觉项目和后台系统整体耦合不大，于是改造成了vite2+Vue3：
这时候可能有细心的小伙伴发现了，不是重构项目吗？怎么看起来像是重写了？好吧，我自始至终都没见过旧版“在线PS”的源码，后来我才了解到，旧项目原本是老板五年前扒的别人生产环境代码来上线的，这可真是五线谱上瞧不见马——就你马离谱了呀😂。
等到其他项目忙完一阵，领导也开始催我进度，年底的时候我便向前端组长报备了一下，说接下来我要把这个项目好好完善一下（主要是项目穿插来穿插去不利于开发），组长人也很好，其他需求也就没安排我做，过完年后到4月的这两个月时间，我得以专注于这个项目的开发。
当时基本功能都做的差不多了也开始优化界面，没有UI设计怎么写界面？别问，问就是就是学(chao)习别人优秀的设计，当然也加入了一些自己的想法🤔，三个月时间里，虽然细节仍尚欠火候，然项目大致成型，psd解析也有，还爬了一些模板和资源，整个使用流程算是跑通：
转危为安的服务端生成图片方案
开发中遇到的问题已经数不清有多少了，但最大的问题还是莫过于图片的生成方案，想想在客户端一顿操作，以为自己画了只虎，结果下载一看却是只猫，那不是白搞了？
一开始思维局限于前端，我也做过不少分享海报的业务，都是采用 html2canvas 这个库，记得以前为了实现渐变色的支持，还有object-fit:cover(也就是图片等比居中)之类的效果，花了不少时间修改源码，知道了其原理是解析DOM并转化成Canvas语法重新绘制，也就明白这其中必定存在许多坑，虽然用来做一般的页面截图倒也没什么问题，但是碰上文字特效等css属性、svg等场景，顿时头皮发麻，而且像 html2canvas、dom2image 这类库，最终生成的图片都不能保证跟你页面呈现是完全一致的，除非你的整个画布就是用canvas渲染，所有操作和效果都转化成canvas语法去做，那前端就可以直出图片了，但是抛开实现成本不谈，canvas对于处理复杂操作的能力本身就较弱，这样做出来的页面会很卡，而且许多高级的css语法也没法用上会比较可惜。
稿定设计很多效果也是用canvas标签绘制的，所以元素多的时候稍会卡顿。比较特殊的是创客贴，画布是用svg渲染的，svg比canvas拥有更好的底层能力，所以比较流畅，它的产品是在页面直出图片的，但除了出图速度以外看起来没有其他优势，而且我觉得稿定设计也并不是不能在前端直出图片，从他们的吸色器功能上就可以看出，在前端应该已经具备了解析整张画布的能力（可能有自研的canvas解析器）。
搞不定图片生成，这项目还有做下去的必要吗？写一套DOM解析器？那得花多少时间？开发人员就我一个，能力上限就摆在这，即使硬着头皮去开发，也没有什么具体思路，没有最佳实践可以参考，如何保证今后迭代更多功能的时候不会推倒重写？当时想到这已经是直冒冷汗了，找前端组长聊了下，提了一嘴 puppeteer，这个之前接触的时候只认为是做自动化测试和爬虫的工具，但从原理上讲似乎也可以解决目前的场景，当天晚上回去就写了demo测试，发现效果还不错，而且图片生成用浏览器截图的话也可以和前端解耦，前端就可以尝试各种方法去实现效果，只要保持linux谷歌浏览器是最新版本兼容性便可以拉满，顿时又燃起了希望！不过组长并不建议我部署到服务器上，而是说让后端写什么轮询的接口，在本地用主机跑这个服务，因为当时公司的一个视频制作项目就是用这种方法搞的。但我觉得是ffmpeg对机器性能要求高，密集型运算的服务器又特别贵，所以可能才考虑用这种方案降低成本，我这只是个无头浏览器问题不大（当然我在自己服务器实践了），最终部署的时候确实遇上些小波折，但那都是后话了。
飞龙探云手
为了弥补设计部产能不足的问题，领导示意我从网上采集些模板和素材过来，让设计可以在里面挑选/调整之后快速扩充模板数量：
其实说白了就是爬虫+分析数据结构、转成自己的模板结构、资源下载、入库。这个过程就好像后端写了接口却不写文档，你要去盲猜他每个字段是什么意思、用来干嘛，当然项目里也得支持相关的功能，所以并不是完全复制的概念。
采集的资源会默认为“未激活”状态，由设计部门去修改和判断停启用。一开始边测试边录入数据，每天入库几十个模板，老板嫌速度太慢，我干脆就化身无情的模板搬运工，用公司电脑不舍昼夜地挂机了两天，最终入库将近3万个模板，把设计部几年的工作量都给安排了（这里偷偷说下，其实我也采集了稿定的，但是不敢给公司用，只敢把小厂的偷来😏稿定的只给自己消遣和研究，分析数据的时候也能学到不少东西）
关于字体版权，收费字体可以单买使用权，或者买商业授权，一般一个字体几百到几千不等，授权是永久性的，像正常ToC的设计网站买下商业授权后，提供给用户下载的图片包含的字体也是可商用的了。但字体的授权形式目前还仅是一纸君子协议，只要下载到字体没有版权也可以使用，但是如果你公开商用并且被发现了的话，就会被版权方追究，产生巨额赔款。我司项目通常是私有化部署到客户环境的，商用字体会“温馨提示”一下，风险由客户自己判断，当然我们自己生产的海报都是尽量使用免费字体，毕竟免费的字体其实也不少。
PS: 目前公司后台的未审核模板数还剩下2万个：
但设计部最近又经历了一波人员变动，如今产能是更加不足了😂。。
node服务与linux浏览器docker化部署
关于Node服务的部署，也是困难重重，首先是运维方面非常不认同NodeJs，说漏洞非常多，听到我要使用node+chrome的方案时更是强烈滴反对，说linux浏览器以前就用过，十分不稳定，还会搞崩服务器等等。但我寻思着自己1核1G小主机都不会崩，公司的服务器怕什么呢？于是还是坚持了自己的方案（前面说了纯Web绘制咱也真做不出来啊）。
最后我的服务总算是部署上去了，由于公司没有部署过Node的经验，周日我还在企业微信上和php技术经理来回对接，先在他的本地环境先跑通一个容器，配置好后导出镜像，处理完各种奇奇怪怪的报错之后，最终给到运维一个docker镜像和一条运行命令，代码目录则映射出来走CI/CD发布。原本我还以为这些事能全部抛给运维的，想多了。
运维这边则给了一个内网端口，由后端php再写一个接口调用，并且加了个url回调，当我截图任务完毕时再调用它，通知php去拿到图片。这样可以在url加串md5解决一个鉴权问题，关键外网也不能直接访问到Node服务（运维放下了手中的刀）。而前端下载则只能不停轮询php的接口，轮询到有结果时才拿到下载地址，比较的呆。
模板PSD解析上传
由于我们的项目并不针对C端用户，所以比起覆盖各行业场景的模板需求，垂直领域海报的模板下沉更有意义，这当然离不开设计部的添砖加瓦，此时将平面设计师做好的psd上传到后台解析成可交互模板就很有必要。这块涉及到很多东西，包括各种字体特效、文本多行拆分样式、图片蒙层解析、分组多页面等功能——我都是没有实现的😂，只做到了基本够用的程度，所以也写了一些PSD设计规范给设计部，以免设计师辛苦做了图传上来却显示了个寂寞。
这块和稿定设计比起来就是班门弄斧了，稿定没有任何规范，因为99%的psd文件它都能近乎完美的解析，文件是上传到服务端解析的，不知道具体怎么实现，反正可以支持解析很大的文件，而我是在前端浏览器解析完再上传的，遇到超过200M的psd文件基本上页面就卡死在那摆烂了。
技术先行
由于自己是整个项目的owner，UI和产品介入后我开始有两套代码，一套是给公司开发的，另一套是自己的实验田，有些功能自己做了觉得可以，就git检出比较代码手动迁移到公司项目里，比如当产品告诉我他想加一个二维码功能的时候，我已经开发完一版了，直接截图给他，于是产品原型也不画直接用截图给我提了个需求单😂。
一些可能有趣的功能，但没上线
尝试了不少有趣的功能，但其实折腾多了，有点“面向谷歌浏览器开发”的感觉，因为浏览器之间的差异很难抹平，做到完美兼容对我来说几乎不可能，所以有很多都没上线，怕出什么bug，又有些实验性质的东西，就只是自己玩。
简易css点九图，不太好用，稿定是canvas实现的：
文字特效模块，有点拉跨，还在开发中：
svg，吸色器，图层等功能演示：
图片容器功能，有点bug还没修完：
也简单做了一下后台的模板与素材管理：
项目到这里介绍的也就差不多了，总之就是一个不停摸索又不停折腾的过程。其实互联网行业里大部分的产品我感觉都挺饱和的了，很难讲什么真正的创新，都是缝合一下就出来个产品，再按实际需求去做功能点。而像遇到这种非常规类型的项目，技术主导就显得尤为重要，一般的产品专员很难发挥效果，技术能力既决定了产品的上限，同时也是一道难以逾越的壁垒。我在做这个项目经常想的一类问题就是: 稿定这个功能到底是怎么做到的？当然偶尔也会想摆烂，那会和同事开玩笑说我是一个人的下水道对标百人前端的天花板，但是每当做出来新功能时，多少还是有些小兴奋，人在巨大落差感面前，也总会不断激起前进的欲望吧。
其他
由于公司的基础建设十分薄弱，我自己也花了不少时间在基建探索上面，试图找到一些改善开发的方法，从结果上讲都少有成效吧，就稍微提一下，有空还是会继续研究的。
一开始搭建过Vue2组件库、Vue3组件库，由于公司的前端项目基本都是使用Vue2技术栈的，所以我在4人前端小组里推过我做的这个组件库，当时我考虑的重点是怎么用起来舒服，所以编写了自动化脚本代替一些操作，而且我认为公共组件库就是给大家用的，使用文档很重要，所以组件文档也是要做到能根据代码和注释自动生成，降低开发成本。
但从结果上来讲，组件库这半年来除了我自己写的demo，就没有其他的提交，我总结了原因一个是生产力难以解放，大家都没有编写组件的时间，同时也很难量化为工作产出。另一个问题是大家都不知道该怎么做公共组件，到底是做业务型组件还是功能型组件？功能类组件其实大部分都有轮子存在，重新造一个轮子对生产效率可能没有提升，偏向业务的组件更能解放生产力，但是比较考验组件抽象能力。
以上是内圈因素，外圈因素是通常我们的项目都是基于收集甲方意见来做的，自身少有明确方向的产品指导和统一，很容易冒出来一些没考虑到的特殊定制化需求，这也导致了组件很难抽象。比如后台一个文章抽屉的组件，几个页面中都有引用，里头几千行代码，由于迭代次数过多，业务逻辑也多，本身已经很难维护，要将其抽成公共组件可谓是心有余而力不足。
我也思考过除了单纯的组件库，形成公司专有的UI库或许也是一条道路？也就是需要UI设计师也参与进来，我们把一些功能类组件风格化，UI在做设计稿的时候则应该避免特殊设计，遵照已有风格化的组件来设计页面，这样在组件库覆盖度足够高的后期，甚至可以不用走查UI，因为大部分都定制在了组件库里，而且还能随时修改风格，将引用升级一下即可，不用一个个页面找出来改。不过这个想法也只能是项目开始之初就定下来，如果在已经成型的项目里，这么做可能就意味着大量旧代码的改造。
我的组件库是基于monorepo模式并由lerna进行管理的，组件deploy会直接发到官网上面去，所以当然也有准备要部署私有npm的（是的我们公司项目都是淘宝镜像梭哈），但是碍于要去和运维申请服务器资源，可能还需要处理权限账号之类的对接，而且很奇葩的是我Gitlab连创建仓库的权限都没有，觉得限制太多懒得去搞了。
公司项目太多，分支管理也有点混乱，经常需要来回横跳切换，发布有的是CI/CD，有的是本地编译后提交dist目录，觉得麻烦，写了个自动化脚本，通过交互式配置任务来自动处理提交发布，还有判断任务执行风险、代码冲突检测机制、任务热重启、自动跳转到pr合并等功能，个人觉得挺酷，但是我们公司操作Git都是“小乌龟”起手（php应该很熟悉），不像我喜欢用命令行。
对于前端团队规范，代码校验、提交规范都探索了一遍，产出了一篇文章，写的时候感觉到过程其实都是些依赖安装和配置修改，而且提交也麻烦（有时连一个空格都不能打错，那么多类型记不住反正不是feat就是fix），所以基于此我编写了一套自动化工具 vue-cli-plugin-norm 自动给项目建立规范配置，基于配置大于约定的原则，默认自动校验代码风格，并且提交也简化了，变成了命令行交互式，还集成了一个小服务，可以把所有commit以网页形式快速查看，不过这个感觉比较的鸡肋。
| 安装效果 | 提交功能预览 |
|---|---|
由于当时也在学习怎么写vue的cli插件，就把这个工具写成了cli Plugin，不知道是不是这个原因，发布到npm后竟然有不少的自然下载量，直到目前已经有 20k+ download数据，不知道别人用着怎么样，反正我基本没在公司项目里使用（因为提交规范原理是拦截git hooks，但是我们多数前端代码是没有独立仓库的，都放在了php仓库的目录下。。
后续更新
项目已正式开源，文章地址：juejin.cn/post/726177…
