工程提速,规则的意义
2024-12-09 11:13:16

为了让工程提速,我们制造了规则。

为了让工程提速,我们漠视了规则。

本文给新踏上开发之路的朋友,1~3年左右开发经验的朋友可以看看,虽然这不是实打实的开发技能,但这却是我这数年开发的实际心得,您看完了,或许会有所收获,也可能会莞尔一笑,不过无论如何,肯定都不算是耽误您人生中的些许时光。

正文

在早期单打独斗的时候,从来没有在意规则,一个人想怎么写就怎么写。

不过为了让未来的自己读代码没那么累,于是我开始在代码中写入注释,并且开始了简单的语义化,不再简单使用a,b,c,d这种临时变量。

这是最开始的简单规则,一直到团队开发的时候,我开发人生中第一套规则才开始正式诞生。

而数年之后,我为公司打造了一套低代码工具,将工程化发挥到了极致。

遥遥回想过往,简直感觉一切简直是不可思议。

开发规则

在早年前后端分离的思潮刚刚诞生的时候,我入职的前端开发团队大约两人左右,那时后端也仅一人。

很多时候商量着来,就能完成。

而后来,随着业务量的增加,前后端数量开始增加,三人以上的前端团队,对接三人以上的后端,在没有统一规则的指导下,开发进度一言难尽。

大部分的时间,前后端为了对接接口而费劲了心思。

情景复盘

三个人的后端,写出了三种风格的接口,大小写不统一,中英文混写,接口传参方式混乱,传参方式不同,且接口变动频繁导致前端根本无法稳定对接。

大家可能不能想象,那我就说一点,增删改查这一套流程中,有人同样一个字段居然写出了四种命名,有的是拼音,有的是小驼峰的单词,有的是大驼峰的单词,有的还用下划线方式命名,传参的code甚至都能出现字符串和数字两种类型,判定接口成功的code:200,20000,且这个过程中还有两种类型。

后端一团乱麻,而前端也没好到哪里去。

样式写法混乱,不用公用样式,非要自己改权重,写入样式覆盖公用样式。

接口写入方式不同,明明有着开源框架的标准方式,却偏偏要自己手动引入axios写接口,导致api接口文件非常不便管理。

而且,当时那个时间大约是2019年,那时候,前后端分离方式的思潮还很新,部分前端依旧是习惯于Jquery操作Dom的写法,然后你可以在vue的项目中看到有人引入了Jquery的在线链接,然后在框架内写代码操作表格。

这种思潮时至今日我居然还能在部分新手代码中遇到,有些时候我甚至可以在vue3中看到Jquery操作表格的代码,我也是不得不感叹,世界真是太大了,大到会发生任何不可思议的事。

整理问题

毫无疑问,不规范的问题极大拖累了开发速度,我们两周后复盘了一下,近乎7成以上的事件浪费在这种毫无意义的调试上。

我们当时在做的是一个系统的翻新,之所以接口会出现频繁变动,是因为大多数后端对业务不熟悉,进而导致接口频繁变动,而我们需要快速翻新出成果。

为了追求快,我们放弃了规则,这是管理上的隐患。

公司当时用的是非常好上手的Vue2,写过Vue2的朋友大概率应该知道,这是一个非常好上手的新手框架,但是我们那时候简直能用出一坨屎。

我将这个开发过程中犯的毛病整理一下,权当一篇避雷指南了。

如果您现在的项目中中了以下几条,那您就必须要反思一下,您做项目到底将多少精力花在这些无意义的调试上了?

  • 管理上追求快,不做标准要求,按照要求的时间点开始倒排开发日期,导致开发无限期加班,精力极大程度的消耗在对接空耗上了
  • UI风格不统一确定,很多时候出成品,经常会有样式上的变动
  • 前后端不做业务交流,双方都在一次会议之后,简单确认了任务,就毫无修正的朝着各自以为的目标推进
  • 后端接口标准不统一,数种不同风格的接口导致前端难以适配,即便写统一处理字段的方法也没法讲中文字段转换成英文字段,这极大的拖累的开发进度
  • 前后端未约定联调标准,导致传参方式适配难度极大,后端成功与失败的code都不统一,有的后端甚至不写接口报错捕获,所有的传参结果都是成功
  • 前端未使用公用样式,导致样式管理极度混乱,无法统一修改部分公用样式
  • 前端技术栈不统一,有人在项目中使用JQuery,加重了调试的心智负担
  • 前端语义化命名不明显,在样式中多处使用L1,R1,T1,B1这类风格,scss样式嵌套加深之后,阅读极为困难,变量中更是重量级,基本上不用ES6,狂用ES5的写法,几乎不用ES6的新特性来处理数组,导致代码阅读极为困难
  • 前端代码风格不同,导致不同格式化的代码风格经常冲突
  • 前端不用VueX存储的公共数据来读取一些数据字典,反而每次都要请求一次接口去读数据,每次页面都要拉取很多接口
  • 没有公共工具方法库,所有人判空,取整,时间格式化都是按照自己的想法来,八仙过海,各显神通

综上,这是开发中问题,至于发布测试等方面的问题,这里先按住不表,因为后续更是重量级。

由于以上的问题,我们开发页面过程极度缓慢,翻新进度简直慢的发指。

四个简单的增删改查页面,前端后端6人,每天工作12小时以上,而且是时刻有交流条件的情况下,大家根本不交流。

然后,居然在一周内没有完成两个单表的增删改查。

而后续一个复杂的多字段表单,更是整整耗时一周,才勉强调通,且不能保证全流程完全走通。

是的,这就是我们的开发进度,6个人,做成这样,肉眼可见的丢人,但这就是那时的开发进度。

我们放弃了规矩,但是我们并未追求到进度。

在复数人员的开发情况下,一个混沌的开发体系,进度便是如此的可笑。

解决方法

幸亏管理也算是技术出身,且技术功底扎实,简单的商量之后,我们制定了以下的简单方案

  • 后端接口由管理负责,定好统一格式,后端全员按照接口格式开发
  • 在正式确认业务之前,前后端都要过一遍业务,彼此确认业务的大致流程,同时后端在没有给定正式业务之前,要先给出确定字段的接口,便于双方确认(那时候我们还不会Mock数据)
  • 制定统一风格,由管理人员确定一套风格,然后开发出最初的模板,之后尽可能使用element-ui框架来实现功能,避免前端使用自己手写的样式覆盖,如果一定要调整全局样式,那么需要报备,除非必须要求改动,否则就放弃修改
  • 技术栈统一,放弃JQuery,全面拥抱Vue2的写法,每晚定期进行代码审查(草草检查,主要确认没有jquery)
  • 公共接口抽离,将一些公用方法抽离出来,如上传,部分复杂的业务数据字典,
  • 公共方法本地化封装,将一些判空之类的方法写在工具类中,省去每人手写工具方法的时间
  • 命名语义化,尽可能减少无意义的变量命名
  • 代码格式化插件统一,开发工具统一,保证所有人调试起来方便(笔者并不太会用webstorm的格式化,当时也没时间去研究,只能禁了那位组员的webstorm,让他用vscode)

经过这些小手段,效果立竿见影。

开发进度确实有了些许提升,但是页面功能的稳定性显而易见的上升,同时每人的工作量大幅下降,勉强可以8点下班,至少不用彻夜彻夜的加班了(在这之前巅峰时间甚至能达到每天14小时以上的工作强度)。

可能大家会觉得,这并未提升多少,但是于那时的我们来说,在这之前,团队几乎是肉眼可见要崩塌,所有人都不觉得这样的团队能做成这个项目。

但是这些简单的规定做下来之后,虽然强度还在,但是工作目标至少可以量化了,同时任务终于可以拆解了,不再是将所有人都堆在任务中。

而团队工程化的路,就是从那时候开始的。

运维发布

因为团队一开始并不大,所以很多时候都是开发运维一把抓,然后在这个过程中,又诞生了一堆混乱至极的问题。

情景复盘

那时,我们用的仍然是SVN进行版本管理,相对于git的分布式版本管理,SVN的集中管理有个弱势点,那就是版本管控必须要将代码文件提交到中心服务器。

而这就有个隐患,如果有人没有将自己的逻辑走完,那么为了版本管控,他也只能将代码提交到SVN,而客户几乎每天都会过来看一下进度。

如果有经验的人,想必此时已经发现哪里有隐患了。

因为有人会将未完成的功能提交到线上,那么发布到线上的时候,碰到演示这种未完成的功能时候,免不了会被客户一顿痛批。

部分公司为了解决这种问题,会选择再买个服务器,做一个测试版本,但我们当时是内网开发,客户表示只有这一个服务器,然后结果就很尴尬了。

这个过程,开发流程管理也很混乱,客户会经常在我们开发过程中插入一些新的要求,导致我们项目需求翻新的进度极度拖延。

整理问题

在我们刚解决了开发上的规范问题之后,我们就遇到了这种运维及需求沟通的问题上的问题。

需求混乱
  • 翻新需求不明确,做无用功,很多旧版本的功能,在旧版时候明确不用了,但是项目Leader没有细细筛过需要翻新的功能,导致经常做了无用功
  • 客户需求不评审,因为客户可以直接到现场催稿,导致经常会插入一些客户优先的功能,延误了正常工期排序
  • 对业务不熟悉,导致返工。这个是最常见的事情,很多时候,我们评审业务,项目Leader没有说明白业务,进而导致开发者对业务的理解南辕北辙,不停翻新做无用功。

针对这些问题,我们项目Leader只能将自己从开发序列中抽离,自己去整理业务对接客户。

因为他最懂这块的业务,所以只有他自己可以去,他将需求承接完成后,顶住客户的需求压力,按照排期给我们捋顺业务和开发进度。

之后,由他来作为团队大核,指导对业务不熟悉的我们,由我们负责具体的开发内容。

这之后的效果,也算是立竿见影,虽然项目Leader不用实际开发了,但我们的进度却并未落下,甚至质量再次提升,做无用功的情况越来越少,随着大家对业务的逐渐熟悉,所有人甚至可以对业务中不合理的地方及时预警。

混乱发布

这是在需求没有整理之前的情况,我们的发布突出一个随心所欲,几乎所有小团队中能犯的错,我们这里都犯过。

  • 版本不指定,我们没有既定的版本,只是按照大致的感觉和客户的催命程度来发布,这时候我们和上版本相比有了什么进步只有项目Leader知道
  • 功能不自测,因为经常翻新,为了追求演示效果,我们经常赶时间发布,这导致演示的时候经常翻车
  • 人员不指定,所有人都可以发布,然后我们经常在发布的时候撞车(趁没有测出BUG悄悄发布,小团队这种事想必很多)
  • 项目现场不指定,当时翻新的这个项目部分源码涉及到另一个项目现场,手动发布必然会有失误,经常忘记改配置,导致项目现场读取的内容错乱
  • 日期不指定,因为没有固定的发布时间,所以客户经常回来催我们(后来由项目Leader去抗这个压力了)

综上,我们提出了一系列的解决方案。

  • 定好版本发布规则,确认需求后,固化发布日期。除非客户强烈要求,否则不会加入新功能排期,按照周为单位进行迭代。
  • 指定专门的运维人员,其他人不能碰发布服务器
  • 前端开发打包版本插件,让代码可以根据时间自动生成版本,并抽离配置,减少手动发包导致项目现场错配的问题
  • 安排运维人员书写运维文档,保证客户和开发人员都能明白我们要改什么,接下来要做什么

提速方向

讲到这里,时间基本上挺接近现在了,我这里没有接触过更高标准的团队,但是就我打听的情况来看,大厂似乎也将工程化的流程走到顶点了。

我在面试过程中,发现很多团队实际上基本就是前者的形态了,很少有进入到这一步的,以下提到的这些需求,几乎是只有大型团队才会出现的需求。

这一步几乎是工程化的高标准状态了,大多数草创的开发团队,甚至是一些较为成熟的团队,他们几乎没有到这一步的意识和需求。

到了这一步,公司业务几乎固定,因为业务线的固定,也逐渐衍生出产品化的概念,自然也就有了产品迭代的需求。

于是,工程提速的玩法再次发生了改变。

  • 自动化发布
  • 代码管控,自动生成发布日志
  • 组件库
  • 工具包
  • 脚手架
  • 前后端约定统一,技术栈固化

集成以上方式之后,便有了终极形态,低代码。

在那时,我们几乎可以将一个两月交付的项目在一周内迭代出原型,供客户参考,然后在那基础上修改。

同时极大程度节约人力,不过受限于篇幅,这里就不展开说了,后续会随着自己的要求,逐步解释我们项目中为什么进行这些操作。

结语

开发规则的诞生,是一个几乎必然的过程,人人都在骂这种制度化,但是一旦走向了大型团队化,我们又不可避免的制度化。

有些时候,人真是有趣,讨厌一件事,理解一件事,融入一件事,成为这件事。

制度化,团队化,似乎是人类群体的必然性,这种过程似乎是大型团队的必然答案,也是一种趋同进化的趋势。

当然,扯远了,我们仅仅说的是工程,一个工程想要做的正常,并非一定要上大型工程的规则。

最后,给自己的掘金引个流:工程提速,规则的意义 - 掘金 (juejin.cn)

希望大家能关注我,多多点赞,谢谢!

参考

Prev
2024-12-09 11:13:16
Next