阅读 2734

初创公司的前端团队如何更好的发展

前言

好久不见的掘友们,工作与生活的忙碌,已经大半年没输出过文章。借用难得的三天假期,与掘友们,一起分享及讨论前端团队的议题。

相信无论哪个行业,如果身处打工阶级,都会经历这么一个发展经历:

  • 入行时,想着如何去融入一个团队,时刻需要保持自己的步伐跟上节奏,以及做好自己的伶仃琐碎。
  • 再慢慢,逐渐成为团队的一个更重要组成部分,此时更是需要保持一份责任心,同时也需要自我能力的提升。
  • 再后来,可能面临着带新人,或是怎么去承担一个团队,此时可能做人,做事,为人,处世,各方面都需要学习与考虑。

那么作为传统或者是初创公司前端的我们,有什么好的方案,可以让团队更专业,更协调,以及更高的产出呢?

即是今日之主题,一起谈谈以及分享一下对初创前端团队的看法以及方案。一方面希望能帮到初带团队的您,另外一方面,希望留下您的宝贵意见,也帮忙笔者更好的成长。

初创公司是什么

在此之前不得不提什么是初创公司?

笔者的个人理解,如业务公司出身,企业面临互联网产业转型,开始对互联网开始自己投资,构建自己的互联网体系。或对互联网某个方向有自己的想法,开始部署自己的战略。这类公司通常不会有大的投资(相比成熟的互联网企业),开的薪资也远不及专业的互联网巨头。

它跟常见的互联网企业不同。互联网企业,特别是大厂,谈的是,高大上技术、谈架构,谈场景。而初创公司,更在于,如何把当前的业务落地,怎么更快的效率,与更低的成本,实现对应的想法。初创公司的团队,不仅人力资源紧缺,且学习资源也薄弱。遇到做不完的活,你得让你加班加点;遇到解决不了的难题,你得不断的试验,查找社区,或者是尝试另外的方案。

可能大厂的前端,属于航母上的螺丝钉。但初创公司的前端,却是小船上的双桨。

双桨的表层意义,首先他的确很重要,没有双桨,意味的小船就不在前进。的确,在传统公司或初创公司里边,他是这个部门的门面,最外边的一层皮。里边是什么,可能还没挖掘到或深层次的考虑到,但是表面功夫是要做好。

另外一方面,居然是双桨,就表示我们需要你不停划动,也意味着,你需要不停的工作, 这里的工作包含很多重复性工作,杂而琐碎。

我是掘金,逐步前行,下边谈谈我认知里,初创公司前端的弊端。

初创公司的前端劣势或痛点

以下仅为笔者的个人观点。

1) 话语权较低

前端曾经在行业有“切图仔”之称,言外之意,切好自己的图,写好自己的样式即可,其他逻辑与交互,你无需参与太多。

后续随着前端的发展,前后分离,前端的地位已经慢慢的权重比例增多。犹如大厂,基本已经分离管制,前端都有自己的负责人,也有着前端的架构师。

然后在这类创业公司,前端依然是没有说话权。根本谈不上什么架构不架构,甚至连评审会否没有叫上前端;页面如何交互的问题,服务端也有自己的想法,让其前端“按我想的来”即可。

这也是一些前端,有了几年的工作经验,逻辑思维还是偏差的原因。主要日常的情况,没有自己的施展空间,没有自己调配的战场。

2) 底层建设薄弱

笔者面试过很多中级的前端,经常会问到一个问题:如何完成项目的工程化?一部分人的回答,往往就是借用”vue-cli“或”umi“脚手架即可。

的确,初创公司,在前端领域,对底层的建设基本为0。一有项目,基本就是借用脚手架的已有功能,立即开工。用到什么,第三方库有什么,直接撸。

没有“基本组件库”的概念,也有“公用方法复用”的概念; 规范与风格,更是人均一版。甚至,连第三方库都可能存在多套,也没什么封装。

而你可能看到这里,可能会觉得,前端应该处理得更好。然而,事实是,这类公司,留给你的整理框架的时间,少之又少,更在意的是:你今天的业务代码写完了么?

3) 协助较混乱

协助,这里指的是在整个互联网部门的协助上。通常,由服务端,前端,设计,产品四个角色组成。

大一点的企业,都会有自己的任务流水线,且哪个环节出了问题,追责哪个环节。如开发过程中,设计图改版?为什么要改版?改版要走哪些流程?经过哪些岗位审批?改版后的工期如何评估?会对现有功能有何影响?

而在初创公司,并没有这样的一个概念。基本就是口头一句话,解决了所有的流程!至于工期,或者最后的质量,不好意思,你得自己把控好。

该有的文档,为了提高“效率”,也少之又少。所以,经常出现,同一个问题,重复问多次的情况。的确,靠人脑,你需要去记参数,记录逻辑,一阵子没使用,后续的理解又重归于零。以致于,还是得重新沟通一遍。

4) 团队感薄弱

这也是上边提到的。团队感相对较差,毕竟每个人的责任,就是写好自己的业务。

如团队有技能稍稍突出者,情况还相对乐观一些。如团队成员水平差异不大,则很大的可能性是,出现N套不同的风格。

如class名称,将大小写驼峰,下划线,中划线,几分情况。可能还没有谁是谁非,每个人的方式,似乎都有自己的理解,且你还找不到否认他的理由。

5) 忙碌杂事多

这个可能不仅仅是前端的问题,基本初创公司,哪一个角色都处于这种状态。

一方面,追求“市场主流想法”,别人能做到,我们也要争取做出来。另一方面,负责人就这么几个,最终的结果就是一人当数人用。也许开发已经告一段落,回头维护时间得全部自己另外挤。也就出现了,“杂事多”。

如何突围

笔者简单分享一下,曾经遇到的难题与方案。也许方案欠缺,也喜欢留下您的宝贵意见。有未提及的地方,也可以留言补充。

1) 编码规范

编码规范,的确对一个团队十分重要。模块的划分,的确使效率高效点,各自维护自己的代码。其弊端就是,这个模块没有你,意味着"重构",这是非常可怕的一个事情。所以,让团队的每个人员都能看到懂你的代码,非常重要。必要的备注,目录,文件夹名称,都要提前去规划好。

如果团队没有技术过硬的角色,那也很简单,模仿egg框架的思维,奉行『约定优于配置』。即找一个官方,或是比较有名气的开源,约定好一切规范学着他走即可。

而在编码上,在有了自己团队的讨论结果后,难免有人会不适应。其实,有自己的检测工具最好,常见的方案有eslint,tslint,git限制等。

再往前一步,我们可以借助ide的自动格式化,来统一团队的编码。常见的webstorm,idea都有自己的自动化格式设置。而笔者更喜欢vscode,常用的方案,vuter,prettier的方案,更加灵活。

2) 设计规范

谈到设计,可能你会觉得不在前端的讨论范围内,这是UI的事情。然后事实是,如果前端没有自己规划好,最后辛苦的是自己。

如果你身在初创团队,我相信你经历过这份悲哀。

  • 第一份悲哀,每次验收,都有不如意的样式,往上1px,往下1px, 两边靠一下,文字没对齐;
  • 还有第二份悲哀,就是所有的按钮我要1px; 第二个星期,把所有的按钮的边框,帮我改成2px吧。

如何解决这里的问题,笔者能给出的建议:

  • scss/less底层基础库。

与设计人员,定制好,一个基础的规范。如字体,在你的项目,如果出现10px,11px,12px,13px等大小都有,显然项目的真实产出,将大小不一,且页面的验收,肯定是来回调整。 我们可以提前定制与商量好字体的大小,如小的字体10px, 正常14px, 偏大18px,标题22px。

这样,我们就可以开始构造自己的基础库了。 $font: zip(small normal large title, 10 14, 18, 22);

此时,每个字体将继承$font,这样就可以统一大小且方便日后全局调整。

  • 基础组件库

这里,完全写一套自己的组件库,对于初次公司是比较困难的。但是,如果二次封装呢?

那为什么要二次封装呢?如按钮大小,我们应该是由组件库控制,而不应该是全局样式,或是每个页面控制。这样就可以避免上述产生的悲哀。

3) 团队风格

有了编码的规范,那只是编码,架构上的统一。如果是两个差不多的表格页面,让多个彼此不了解的前端抒写,会有什么样的结果呢?

往往这就出现的不同的页面风格,如变量的取名,由编码的限制,以及统一为驼峰了,但是依然可以有不同的取名。

那如何让常用的页面,命名,方法名都差不多呢?的确是一个头疼的问题。

笔者来回的思考,当前能提供的建议只有如下:

  • 公用文档的输出。可模仿微信小程序文档,把所有api的封装,组件化的封装,都整理为文档,且及时通知他人。常用的框架,包括vuepress,react-markdown,都是不错的选择。
  • 讨论好复用率高的页面或组件,写成模板。利用快捷键的快速生成。如vscode的code-snippets,我们可以利用他快速的生成代码。这样大家在基础上的修改,团队写的代码,就能避免风格的不一致。
  • 及时的复盘,下方会提及。

4) 协助文档

上述曾提到,前端必要时,需要自己的内部的文档。如组件库文档,公用api文档等。包括vuepress,react-markdown,都是不错的选择。

规范文档应当是整个基建中的灵魂,达成共识后的收益,肯定是巨大的。

这里笔者想提的是,必要的时,前端还需要自己的流程图协助理解。特别一些销售类的活动,可能有几十种的营销方案,从代码的角度,如前期不规划好,可能后续就会出现,if中还有N个if,else后边还有N个if。此时,如果有图解,我们就可以更快速去理解代码的入口的意义。

至于图怎么画,我们可能不像产品使用专门的工具。个人觉得在线的processon是不错的,此外,vscode-drawio也是个不错的选择。这里更于快速上手为准。

5) 项目基建

关于项目基建,该方面貌似只有中厂或者是大厂,才有自己的项目基建。初创企业的确很少。笔者了解到的项目基建,如脚手架,微服务,本地仓库,可视化等。

可视化,微服务,初创企业的话,毕竟是一项大工程,相对实用性也不高,初创企业可能用不上。

但是脚手架,本地仓库,如果公司的业务走sass模式,或是项目特别多的情况,还是可以一试的。

笔者就遇到一套组件库,4~5个项目同时使用的情况。如添加一点api,那可是要同步5个项目。这是多么可怕的事情。so,后续有时间,也会规划内部的脚手架,以及本地仓库等。相信一旦处理好,对不同项目的兼容性,那是大大的提高。

6) 协作流程

关于部门协作问题,这里就不再细说。毕竟,每个企业或者公司都有自己的定义,且流程是也不是前端能决定的事情。

笔者想说是,一定要借助好第三方工具。能在工具写明白的,就不要口头传达。一旦打上流程的,就不轻易修改。这对问题的分析定位,任务的质量进展,都可大大的提高。

常用的流程系统: tapd, teambition,禅道等。

常见的接口文档: swagger,easyapi,eolinker,yapi等

7) 部门建设

避免掉线

所谓的掉线,指团队的成员的离开,或者是工作上的调动,是原来的模块,出现了死胡同。这点,如果公司有个几年历史,相信都无可避免。所以,在日常的部门建设中,还是得注意互相打通的问题,让团队的每个成员,在时间允许的范围内,参与到各个项目中来,免得回头一个“烂摊子”。

定时复盘

如果真的一个团队要融一起,相信少不了一个重要环节:吐槽大会。

毕竟,每个人的项目经验不一致,且学习能力也不一致。且,三人行,必有我师焉,总比独裁自己一人撸的强。经过团队讨论后的方案,才是最适合团队方案。

营造氛围

技术分享会,以及博客,都是个不错的选择。当然,初创公司基本忙成g,这个结合实际出发。

  • 技术分享会,如何定制自己的代码,如何使用新的框架等,这些都是很好的议题。
  • 博客的话,类似掘金,都有企业模式。类似我一个同学所在的团队,拿到去年的掘金年度最佳团队。也许没什么难度,我觉得就很不错,至少团队可以提高一下逼格。

8) 测试规范

项目大了,公用方法就多了。可能由阿猫阿狗的方法,此时还要兼容张三李四。这时候出现一个问题,谁来维护呢?总不能永远找一个人来维护。那么动到该方法时。如何确认前面的人不受影响呢?

小的团队往往,需要把所有的流程再跑一遍。的确,这样是最稳的,但人力资源消耗也相对多一些。

当前框架,无论vue,react,小程序,都自带测试框架,如Vue Test Utils。

笔者该方面实践不多,暂不提供建议。只是,这个后续势在必行。

招聘

号外,最近有广州科学城附近,中级工程师找工作,可以留言聊聊。

结语

初创公司的前端团队,问题重重,如何去提高自己,欢迎留下你的意见。我是掘金,逐步前行,共勉!

文章分类
前端
文章标签