最近公司的一个大项目进入了收尾阶段,于是乎抽?#22351;?#26102;间来写些东西,也许这篇文章中的一些点,你也曾经历过?也许你正在经历,又或者你也在做着同样的事儿,不管如何,希望能对大家有?#22351;?#30340;帮助。

项目概况

项目是一个资管类的平台,重构的一个版本,全部都是新代码,整个项目投入了大概10个前端,20个后端左右的资源,工程量还是蛮大的,前后做了大概3个月。前后比率大概是1:2。

人员状况

据小呆了解,团队成员的平均工作年限在5-8年左右,最低也是3年的工作年限。按理来说,这样的配置,应该算是中高配了,可是项目开始之后发生的事情,让小呆开始怀疑人生。

问题暴露

1.项目结构

搭建过项目的小伙伴一定知道,项目的结构一定程度上决定着代码文件的层次度和清晰度。可是在这一开始的地基上面,就让小呆大吃一惊。由于项目采用vue-cli生成,所以只需要在生成项目的结构上面稍加梳理,就是一个比较完善清晰的目录。可是我们的结构愣是让小呆惊掉了下巴。

├── src
│   ├── components  ---组件目录
│        ├── base ---基础组件库
│        ├── bpm ---项目文件夹组件库
│             ├── list --- 列表页组件
│                  ├── card --- card组件目录
│                  ├── card.vue --- card组件文件
│   ├── view --- 页面目录
│        ├── bpm ---项目页面目录
│             ├── list --- 列表页目录
│                  ├── style --- 列表页样式目录
│                  ├── list.vue --- 列表页文件

小呆提出的目录结构如上图所示,组件与页面一一对应,比较容易找。大家也欣然接受,可是大家在建各种负责的模块目录时,变成了这样(因为没有统?#22351;?#21069;端负责人)。

├── src
│   ├── components  ---组件目录
│        ├── metaData ---项目文件夹组件库
│             ├── list --- 列表页组件
│                  ├── components --- 已经不知道是什么了(下面还有好多层)
│        ├── bpm ---项目文件夹组件库
│             ├── list --- 列表页组件
│                  ├── card --- card组件目录
│                  ├── card.vue --- card组件文件
│   ├── view --- 页面目录
│        ├── bpm ---项目页面目录
│             ├── list --- 列表页目录
│                  ├── components --- 已经不知道是什么了(下面还有好多层)
│                  ├── style --- 列表页样式目录
│                  ├── list.vue --- 列表页文件

这还仅仅是页面与组件的关系,就已经让人摸不着头脑了,别提其他的模块了。每个人都在按照自己的想法随意的建立目录,也为后来的开发挖了大坑。

注释问题

关于注释的问题,长久以来都争论不休,有人说写注释,方便自己,也方便他人,有人说,写注释占用大量资源,没有注释的代码才是好代码。于是乎,我们的代码变成了如下两派:

注?#22242;桑?#23567;呆属于这一派)
注?#22242;? /></p>
<p>无注?#22242;?br />
<img src=

而这个项目的接口文档是这样的:
非正常的
非正常的

更有甚者,直接贴了一段Java代码,让我看着Java代码自己写,这里就不贴了。

你告诉我怎么调,后端美其名曰开发任务重,没时间写接口文档,自己猜+试去吧,掀桌(╯°Д°)╯︵ ┻━┻,这样的后果也导致了对接+调试接口时,花费了大量的时间(我们JAVA架构师,改一个查询列表的接口,改了3天,后续这位大佬在接口已经调试完?#24076;?#27979;试完毕之后,把接口返回数据和接口传参又先后改了7遍,前后用时半个月)导致之后每次小呆跟这位大佬调试接口都瑟瑟发抖。

?#20302;?#20132;流

如果以上几点,你都能接受的话,那么最后这?#22351;悖?#25105;觉得你可能会改变你的看法。小呆在跟一个后端妹子对接接口的时候,接口报错,并且小呆已经确定是后端的问题了,钉钉对方,一直不回消息。等小呆把其他功能都做完,就差这个接口之后,跑到妹子面前说,你这个接口报错,发你消息也没回,帮忙看看呗,调试一下。

妹子冷冷的看了我一眼,然后?#31181;?#22312;键盘上敲了几下,回了我一句?#20309;?#26412;地没问题,然后就视我为空气了。最后找了他组长,他组长帮她改了代码,直接跟他组长对接了…

复盘

其实这些问题,在小呆看来根本就不是什么大问题,都是坏习惯所导致的。只不过小呆之前的公司,同事配合和写代码都有比较好的习惯,而且大家都很自觉,所以一直以为这些都应该是?#21040;?#26631;配,从来没发生过这种情况。结果来了这个项目当中,才让小呆知道什么叫惊呆了下巴。

项目结构和代码注释的问题,完全可以通过自觉和强制的形式避免掉,可能大家之前在各自的公司配合的比较少,所以导致在这种多人协作的项目中,依旧?#26377;?#20102;之前独树一帜的习惯,导致项目变得乱七八糟。

而后端依赖程序自动生成接口文档本来是一件高效省时的方式,但是因为比较懒,又不愿意写注释,导致浪费了前端大量的开发时间。这种开发方式,万万不可取,极易产生口头及肢体冲突。

?#20302;?#20132;流本来是促进协作的一件事,结果因为本地环境是好的,就不管测?#26352;?#22659;和开发环境的好坏,说白了还是懒在作祟。

虽然接下来的很长一段时间里,小呆都会处在这种状态下工作(总监离职,群龙无首),但是还是希望看到这篇文章的小伙伴们,能够严于律己,方便他人,养成良好的写代码和?#20302;?#30340;习惯。