我用三个月时间仿造了一个稿定设计 | 2022年中总结

语言: CN / TW / HK

「时光不负,创作不停,本文正在参加2022年中总结征文大赛

第一次写点总结,也不知道有没人看,文笔比较随便。疫情持续下公司老本快啃完了,新业务增长缓慢,技术部只见旧人去不见新人来,甚至已经好久没见绩效长啥样了,我想索性之后绩效报告也不用写了,就来掘金随便写个总结吧😂。

正着笔之时PM给我发了个任务,大概内容是隐藏下这个修改下那个的,平时的工作倒也不全是些这么离谱的需求,有时后台的功能,有时APP内嵌H5的页面,甚至之前有产品要我改个陈年Jq项目(然后被我拒绝了),常规项目做多了总会有种瞎忙活的感觉,更难说能总结点什么。很多都是边熟悉边做,但往往让人感到疲惫的不是单纯技术上的问题,而是一系列对接、项目之初设计存在的不合理之处、反复横跳的需求、以及旧项目一个个上千行代码杂糅的文件。。不过其中也有我独立负责,从零开始的项目,还算有些亮点,思考片刻写下标题,就聊聊这个项目吧。

⚠️ 前方多图预警 ⚠️

项目の初

该从哪里说起呢。。回想当时我还在做着一些零零散散的项目需求,这时候领导给了我一个任务,说让我重构一个“在线PS”,我一听哎,这有点意思了,但是它并没有立项,是的,直到我做了一个多月,团队里还没有其他人知道这个项目的存在,所以我要在搞完其他需求之后挤出来的时间里完成它的开发(因为连PM都不清楚我在搞这个),而且领导表示虽然我们不ToC,但要向稿定设计这类产品看齐。我就在这样一个没有产品、没有UI、研发只有1人、开发工时约等于没有的情况下,在追逐竞品的无限挫败感中,勉强完成了第一版的开发。

第一版的样子,肉眼可见的粗糙。公司是vue2技术栈的,一开始出于惯性也用vue2搭建项目,做了一小段时间感觉项目和后台系统整体耦合不大,完全可以尝试新技术,于是改造成了vite2+Vue3:

WX20220622-183754@2x.png

这时候可能有细心的小伙伴发现了,不是重构项目吗?怎么看起来像是重写了呀?好吧,我自始至终都没见过旧版“在线PS”的源码,后来我才了解到,旧项目原本是老板五年前扒的别人生产环境代码来上线的,这可真是五线谱上瞧不见马——就你马离谱了呀😂。

等到其他项目忙完一阵,领导也开始催我进度,年底的时候我便向前端组长报备了一下,说接下来我要把这个项目好好完善一下(主要是项目穿插来穿插去不利于开发),组长人也很好,其他需求也就没安排我做,过完年后到4月的这两个月时间,我得以专注于这个项目的开发。

当时基本功能都做的差不多了也开始优化界面,没有UI设计怎么写界面?别问,问就是就是学(chao)习别人优秀的设计,当然也加入了一些自己的想法🤔,三个月时间里,虽然细节仍尚欠火候,然项目大致成型,psd解析也有,还爬了一些模板和资源,整个使用流程算是跑通:

2022-06-27 09.52.02.gif

转危为安的服务端生成图片方案

开发中遇到的问题已经数不清有多少了,但最大的问题还是莫过于图片的生成方案,想想在客户端一顿操作,以为自己画了只虎,结果下载一看却是只猫,那不是白搞了?

一开始思维局限于前端,我也做过不少分享海报的业务,都是采用html2canvas这个库,记得以前为了实现渐变色的支持,还有object-fit:cover(也就是图片等比居中)之类的效果,花了不少时间修改源码,知道了其原理是解析DOM并转化成Canvas语法重新绘制,也就明白这其中必定存在许多坑。但一开始没想那么多啊(主要也没时间多想),虽然用来做一般的页面截图倒也没什么问题,但是碰上文字特效等css属性、svg等场景,顿时头皮发麻,而且像html2canvas、dom2image这类库,最终生成的图片都不能保证跟你页面呈现是完全一致的,除非你的整个画布就是用canvas渲染,所有操作和效果都转化成canvas语法去做,那前端就可以直出图片了,但是抛开实现成本不谈,canvas对于处理复杂操作的能力本身就较弱,这样做出来的页面会很卡,而且许多高级的css语法也没法用上会比较可惜。

稿定设计有些效果也是用canvas标签绘制的,元素多的时候会明显卡顿,但已经是业界天花板了。比较特殊的是创客贴,画布是用svg渲染的,svg比canvas拥有更好的底层能力,所以比较流畅,它的产品是在页面直出图片的,但除了出图速度以外看起来没有其他优势,而且我觉得稿定设计也并不是不能在前端直出图片,从他们的吸色器功能上就可以看出,在前端应该已经具备了解析整张画布的能力(可能有自研的canvas解析器)。

搞不定图片生成,这项目还有做下去的必要吗?写一套DOM解析器?那得花多少时间?开发人员就我一个,能力上限就摆在这,即使硬着头皮去开发,也没有什么具体思路,没有最佳实践可以参考,如何保证今后迭代更多功能的时候不会推倒重写?当时想到这已经是直冒冷汗了,找前端组长聊了下,提了一嘴puppeteer,这个之前接触的时候只认为是做自动化测试和爬虫的工具,但从原理上讲似乎也适合解决目前的场景,当天晚上回去就写了demo测试,发现效果还不错,图片生成用浏览器截图的话也可以和前端解耦,前端可以尝试各种方法去实现效果,只要保持linux谷歌浏览器是最新版本兼容性便可以拉满,顿时又燃起了希望!不过组长并不建议我部署到服务器上,而是说让后端写什么轮询的接口,在本地用主机跑这个服务,因为当时公司的一个视频制作项目就是用这种方法搞的。但我觉得是ffmpeg对机器性能要求高,密集型运算的服务器又特别贵,所以可能才考虑用这种方案降低成本,我这只是个无头浏览器问题不大(当然我也有自己的服务器可以实践),最终部署的时候确实遇上些小波折,但那都是后话了。

2022-06-22 11.54.35.gif

飞龙探云手

为了弥补设计部产能不足的问题,领导示意我从网上采集些模板和素材过来,让设计可以在里面挑选/调整之后快速扩充模板数量:

image.png

其实说白了就是爬虫+分析数据结构、转成自己的模板结构、资源下载、入库。这个过程就好像后端写了接口却不写文档,你要去盲猜他每个字段是什么意思、用来干嘛,当然项目里也得支持相关的功能,所以并不是完全复制的概念。采集的资源会默认为“未激活”状态,由设计部门去修改和判断停启用。一开始边测试边录入数据,每天入库几十个模板,老板嫌速度太慢,我干脆就化身无情的模板搬运工,用公司电脑不舍昼夜地挂机了两天,最终入库将近3万个模板,把设计部几年的工作量都给安排了(这里偷偷说下,其实我也采集了稿定的,但是不敢给公司用,只敢把小厂的偷来😏稿定的只给自己消遣和研究,分析数据的时候也能学到不少东西)

话说我还稍微研究过字体版权的问题,收费字体可以单买使用权,或者买商业授权,一般一个字体几百到几千不等,授权是永久性的,像正常ToC的设计网站买下商业授权后,提供给用户下载的图片包含的字体也是可商用的了。但字体的授权形式目前还仅是一纸君子协议,只要下载到字体没有版权也可以使用,但是如果你公开商用并且被发现了的话,就会被版权方追究,产生巨额赔款。我们公司的项目通常是私有化部署到客户环境的,商用字体会“温馨提示”一下,风险由客户自己判断,当然我们自己生产的海报都是尽量使用免费字体,毕竟免费的字体其实也不少。

PS: 目前公司后台的未审核模板数还剩下2万个:

image.png

但设计部最近又经历了一波人员变动,如今产能是更加不足了😂。。

node服务与linux浏览器docker化部署

关于Node服务的部署,也是困难重重,首先是运维方面非常不认同NodeJs,说漏洞非常多,听到我要使用node+chrome的方案时更是强烈滴反对,说linux浏览器以前就用过,十分不稳定,还会搞崩服务器等等。但我寻思着自己1核1G小主机都不会崩,公司的服务器怕什么呢?于是还是坚持了自己的方案(前面说了纯Web绘制咱也真做不出来啊)。

最后我的服务总算是部署上去了,由于公司没有部署过Node的经验,周日我还在企业微信上和php技术经理来回对接,先在他的本地环境先跑通一个容器,配置好后导出镜像,处理完各种奇奇怪怪的报错之后,最终给到运维一个docker镜像和一条运行命令,代码目录则映射出来走CI/CD发布。原本我还以为这些事能全部抛给运维的,想多了。

运维这边则给了一个内网端口,由后端php再写一个接口调用,并且加了个url回调,当我截图任务完毕时再调用它,通知php去拿到图片。这样可以在url加串md5解决一个鉴权问题,关键外网也不能直接访问到Node服务(运维放下了手中的刀)。而前端下载则只能不停轮询php的接口,轮询到有结果时才拿到下载地址,比较的呆。

所以我就想问一句啊,前端开发什么时候才可以站起来😂

image.png

模板PSD解析上传

WX20220622-162402@2x.png

由于我们的项目并不针对C端用户,所以比起覆盖各行业场景的模板需求,垂直领域海报模板的下沉更有意义,这当然就离不开设计部的“添砖加瓦”,此时将平面设计师做好的psd上传到后台解析成可交互模板就很有必要,这块涉及到很多东西,包括各种字体特效、文本多行拆分样式、图片蒙层解析、分组多页面等功能——我都是没有实现的😂,只做到了基本够用的程度,所以也写了一些PSD设计规范给设计部,以免设计师辛苦做了图传上来却显示了个寂寞。

image.png

这块和稿定设计比起来就是班门弄斧了,稿定没有任何规范,因为99%的psd文件它都能近乎完美的解析,文件是上传到服务端解析的,不知道具体怎么实现,反正可以支持解析很大的文件,而我是在前端浏览器解析完再上传的,遇到超过200M的psd文件基本上页面就卡死在那摆烂了。

技术先行

由于自己是整个项目的owner,UI和产品介入后我开始有两套代码,一套是给公司开发的,另一套是自己的实验田,有些功能自己做了觉得可以,就git检出比较代码手动迁移到公司项目里,比如当产品告诉我他想加一个二维码功能的时候,我已经开发完一版了,直接截图给他,于是产品原型也不用画直接用截图给我提了个需求单😂。

| image.png | image.png | | --- | --- |

一些有趣的功能,但没上线

尝试了不少有趣的功能,但其实折腾多了,有点“面向谷歌浏览器开发”的感觉,因为浏览器之间的差异很难抹平,做到完美兼容对我来说几乎不可能,所以有很多都没上线,怕出什么bug,又有些实验性质的东西,就只是自己玩。

简易css点九图,不太好用,稿定是canvas实现的: 2022-06-22 11.50.13.gif

文字特效模块,有点拉跨,还在开发中: 2022-06-22 11.12.51.gif

svg,吸色器,图层等功能演示: 2022-06-22 11.39.33.gif

图片容器功能,有点bug还没修完: 2022-06-27 14.09.38.gif

也简单做了一下后台的模板与素材管理: | image.png | image.png | | --- | --- |

项目到这里介绍的也就差不多了,总之就是一个不停摸索又不停折腾的过程。其实互联网行业里大部分的产品我感觉都挺饱和的了,很难讲什么真正的创新,都是缝合一下就出来个产品,再按实际需求去做功能点。而像遇到这种非常规类型的项目,技术主导就显得尤为重要,一般的产品专员很难发挥效果,技术能力既决定了产品的上限,同时也是一道难以逾越的壁垒。我在做这个项目经常想的一类问题就是: 稿定这个功能到底是怎么做到的?当然偶尔也会想摆烂,那会和同事开玩笑说我是一个人的下水道对标百人前端的天花板,但是每当做出来新功能时,多少还是有些小兴奋,人在巨大落差感面前,也总会不断激起前进的欲望吧。

其他

由于公司的基础建设十分薄弱,我自己也花了不少时间在基建探索上面,试图找到一些改善开发的方法,从结果上讲都少有成效吧,就稍微提一下,有空还是会继续研究的。

一开始搭建过Vue2组件库、Vue3组件库,由于公司的前端项目基本都是使用Vue2技术栈的,所以我在4人前端小组里推过我做的这个组件库,当时我考虑的重点是怎么用起来舒服,所以编写了自动化脚本代替一些操作,而且我认为公共组件库就是给大家用的,使用文档很重要,所以组件文档也是要做到能根据代码和注释自动生成,降低开发成本。

image.png

但从结果上来讲,组件库这半年来除了我自己写的demo,就没有其他的提交,我总结了原因一个是生产力难以解放,首先开发时间比较紧凑大家都没有编写组件的时间,但是提炼组件就是为了减少重复开发时间以此释放部分生产力,那是不是需要有人指导,明确应该做些什么组件,再分工给到大家去做呢?但是这样势必就得量化出工作时间和产出。另一个问题是大家都不知道该怎么做公共组件,比如我做一个公共的“组织人员选择器”就是偏向业务的组件,把其中的列表选择树、弹窗等封装成起来就是偏向功能的组件,而功能类的组件其实大部分都有轮子存在,重新造一个轮子对生产效率没有任何提升,可能硬要写的话就是进行组件二次封装,所以综合考虑的话其实偏向业务的组件更能解放生产力,但是通常我们的项目都是基于收集甲方意见来做的,自身少有明确方向的产品指导和统一,很容易冒出来一些没考虑到的特殊定制化需求,这就导致组件很难抽象,我看到过后台一个文章抽屉的组件,很多页面都有引用,我有次需要使用到该组件,得去问负责的前端小伙伴才知道如何引入,且需要CV一些代码(其中细节都是这位小伙伴纯用脑子记的,这是要成为公司不可或缺的核心技术力了😂),本来是较有抽成公共组件的必要,但是里头写了几千行代码,由于迭代次数过多,业务逻辑也多,本身已经很难维护,可别提抽象成公共的组件有多难了。

这也让我开始思考,是不是其实单纯的组件库并不适合小团队,可能形成公司专有的UI库比较好?也就是需要UI设计师也参与进来,我们把一些功能类组件风格化,UI在做设计稿的时候则应该避免特殊设计,而是遵照已有风格化的组件来设计页面,这样在组件库覆盖度足够高的后期,甚至可以不用走查UI,因为大部分都定制在了组件库里,而且这样还能随时修改风格,将引用升级一下即可,不用一个个页面找出来改。不过这个想法也只能是项目开始之初就定下来,如果在已经成型的项目里,这么做可能就意味着大量旧代码的改造。而且大部分设计师难以克制其强烈的创新欲望,巴不得每个页面功能给你设计个不一样的出来,这就需要得到更高的授权,来规范统一,每一次对组件的样式改造,都要谨慎且小心。

我的组件库是基于monorepo模式并由lerna进行管理的,组件deploy会直接发到官网上面去,所以当然也有准备要部署私有npm的(是的我们公司项目都是淘宝镜像梭哈),但是碍于要去和运维申请服务器资源,可能还需要处理权限账号之类的对接,而且很奇葩的是我Gitlab连创建仓库的权限都没有,觉得限制太多懒得去搞了。总之我就是想问一句,前端开发到底什么时候才可以站。。算了,坐着吧。

image.png

公司项目太多,分支管理也有点混乱,经常需要来回横跳切换,发布有的是CI/CD,有的是本地编译后提交dist目录,觉得麻烦,写了个自动化脚本,通过交互式配置任务来自动处理提交发布,还有判断任务执行风险、代码冲突检测机制、任务热重启、自动跳转到pr合并等功能,个人觉得挺酷,但是我们公司操作Git都是“小乌龟”起手(php应该很熟悉),不像我喜欢用命令行。

WX20220622-183913@2x.png

对于前端团队规范,代码校验、提交规范都探索了一遍,产出了一篇文章,写的时候感觉到过程其实都是些依赖安装和配置修改,而且提交也麻烦(这个问题我以前就遇到过,那时候不懂,git死活提交不上去,还是rebase模式,组长还给我培训了一波,但我啥也没学到只觉得巨麻烦,连一个空格都不能打错,那么多类型记不住反正用的就是feat和fix),所以基于此我编写了一套自动化工具vue-cli-plugin-norm——自动给项目建立规范配置,基于配置大于约定的原则,默认自动校验代码风格,并且提交也简化了,变成了命令行交互式,还集成了一个小服务,可以把所有commit以网页形式快速查看,不过这个感觉比较的鸡肋。

| 安装效果 | 提交功能预览 | | --- | --- | | image.png | image.png |

由于当时也在学习怎么写vue的cli插件,就把这个工具写成了cli Plugin,不知道是不是这个原因,发布到npm后竟然有不少的自然下载量,直到目前已经有 20k+ download数据,不知道别人用着怎么样,反正我基本没在公司项目里使用😂因为提交规范原理是拦截git hooks,但是我们多数前端代码是没有独立仓库的,都放在了php仓库的目录下。。我忍不住就想问一句啊。。算了不问了。

image.png

最后

既然你都看到这了,我也说说我个人的情况吧。前端开发有四五个年头了,专科小透明,坐标广州。很惭愧,顶着高级的title却拿着初级工程师的薪资,一点没有夸张。大环境不好不是理由,这两年自己职业规划上确实也有问题,频繁跳槽还都是拿平薪,当然自身也还不够努力。看别人写总结开篇便是自我介绍,我放结尾写,实在是怕各路大佬刚进来就看了个笑话,而之所以还写到这些,也当是给后来人提个醒,职业道路要早做准备、多做打算,能力增长有快有慢,可能目标感才更能决定成败。技术不必急于求成,都是可以慢慢学的,但环境可能不会变好,或许努力去到更好的环境,才更能加速你的成长。

最后,希望本科考试顺利,然后要尽快把TypeScript和Canvas系统地学习一遍,要尽快能坚持每天练一下算法题,补足自身硬实力。就不立什么Flag了,要做的事情还有太多。就这样吧,保持思考,保持学习,平常心。