公司最近来了个实习生——我要哭了,同学们请收好你们的代码规范!!!!!代码不规范,亲人两行泪

最近公司来了个实习生,我看来一下它提交的代码。整个人都不好了

希望大家引以为戒,不要让自己的代码堆成屎山!

一、代码规范问题

首先我们来看我们的前端部分

如果不去做代码的规范,那么会出现生命问题呢?

以下代码规范出自阿里前端团队项目开发规范

我们发现在项目中,有很多的地方都是存在代码不规范的问题,要知道,如果代码或者项目的风格不同意,代码不规范,就会导致凉凉,特别是后续改代码 ,改需求的时候就凉凉了,会导致工作量暴涨

–现在我们来看看,目前项目中存在的问题

目录结构不清晰

代码风格不统一

总结
你不觉得,如果我们后期需要维护,那么这种代码的维护成本,还有找bug的成本将会非常非常的高吗?,这些就是传说中的屎山

HTML部分的代码规范问题

这里我们主要来研究,我们的HTML部分还有CSS部分的相关问题,

JS部分的代码规范问题

Vue部分的代码规范问题

以上的代规范,是比较通俗,且易懂的规范,请大家好好遵守,这样,以后面试官你看你代码,就知道你是工作的过的人,所以啊,千万不要让你的代码风格堆成“屎山”

文档的规范地址,这一套文档基于阿里团队的开发规范,所以啊,你值得拥有,这样不是我定,对标大公司,希望各位对自己的要求高一些
//github.com/BM-laoli/smart-admin

小程序/APP部分的代码规范问题

这个部分我们后面再说吧,基本上和vue等框架中的约定是一样的。

二、项目版本控制问题

代码不规范,亲人两行泪血淋淋的教训

下面就是我们两个人的垃圾git提交,你可以想想一下,这仅仅是两个人的项目,如果是四五个人的,七八个人的项目,git版本控制会乱成什么样子!!!

严格控制master分支

不要去改别人分支上的东西,你自己的怎么折腾怎么冲突,都请在你自己的分支倒腾

严格控制控制分支代码提交的流程

如何规范?

这里我收藏了两个主要git规范

下面的主要是两个方面来管理我们的GIT项目,前者从面的角度出发,后者从点的角度出发

  1. 对分支版本的控制管理规范
    //blog.csdn.net/weixin_38809962/article/details/79814308?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.nonecase

  2. 一线大厂的commit代码提交规范
    //blog.csdn.net/DevolperFront/article/details/104624183/

三、关于团队协作的问题

误区

不要不敢问,这有啥的,问就是,提要求就是!

要知道,我们开发是前后端一起配合的团队,有需求的变化,就要和后台的说,必须说,不要自己想着在前端自己写东西解决,说不定,后端就你加几个字段就能解决,你一天的开发量的问题。所以说,和后端的开发协调沟通是非常非常非常的重要的

‘对于假数据’的问题

你的假数据千万不要自己,想怎么写,就怎么写,那样就很蛋疼,而且会白白的增加你的工作量,如果你的功能确确实实需要数据才能实现,那么你需要和后台协调好,看看开发文档,数据到底是什么样的,再去写好吧,不要自己想着,这样定义数据结构就很容易实现这样的功能,然后就去写,到时候接口一出来,如果大面积不对,那么你就老老实实加班把!!!血的经验!

技术公司的选人标准

如果有A /B两个人,做了同一个项目 ,都拿去面试,A做不是很全,但是它负责的功能 完美度85%,做得非常非常的好, 而B大面积的完成了整项目,对于用人单位来说,跟愿意录取A,而不是B

总结经验就是:‘有时会深度是非常的重要的’,因为我们前端首要考虑的就是用户的体验!细节要到位,功能要Nice,要漂亮

进行沟通协调的工具

禅道,icafe…..

接口的测试工具

虽然我们是前端,但是也是需要懂得一部分的后端的业务逻辑,有时间有精力的同学可以去学习一些Pyhton还有java方面的知识

推荐使用ApiPost国产版的PostMan

如果想使用轻量级的东西,就可以使用VS提供的REST插件(非常好用)