规范杂谈

我所理解的规范-越简单的东西,越应该做好

Posted by 一之笔 on September 4, 2019



这篇杂谈是脑子里回荡了很久,觉得有必要说一下;

最近感觉工作起来,越来越没有激情了;

作为公司唯一的IOS开发,还要兼顾APP的一些进展,鉴于公司的现实,产品,项目改了需求,或者计划,我从来都是后知后觉,我很不喜欢这种感觉,快2年来,历来都是参照Android的APP开发,公司项目整体一再delay,从未改观;

幸运的是,公司管理层,正在积极通过一些制度来改善当前的问题;

说了这么多,跟规范有什么关系呢?废话,当然有关系,规范是基础,是让所有人的力量往一处使;

规范,什么是规范?为什么要有规范?

大家都听过,无规矩不成方圆,国有国法,家有家规,公司部门应该也要有规范.

什么是规范呢?

规:从字面意思就是规定,规则,更深层次的来源就是,看这个字,左边是丈夫的夫,右下是一个儿子,古代女子嫁夫从夫,夫死从子,不难看出,这个字就是,你来了,你就得遵循我这儿的规矩 范:从字面意思就是,范围,模范 这俩字合起来就是,大家按照约定,彼此遵循的一个示范,用来约束大家的一种东西; 简言之,规范就是次一点的标准; 我们不搞标准,因为标准的定义太高了,所以我希望我们大家把自己部门的规范做好 另外,规范是大家制定的,也是需要大家遵守的,要不然,不执行,规范就是一纸空文;

规范有哪些

规范有研发部门通用规范,比如会议纪要当天写当天发,周报等;

部门规范,比如代码gerrit提交规范,内测发布规范;

跨组规范: API文档规范等等;

代码提交规范

这里简单分享一下APP组的提交规范

总要求:多笔提交,养成好代码提交习惯;

格式规范:

  • Bug修改类:
    • (项目名称)-FixBug:#编号-描述
  • 业务开发类:
    • ADD:(项目名称)-#(需求编号)小的功能就提交,项目初始化;
    • UPDATE:(项目名称)-(修改优化)描述
    • DELETE:(项目名称)-需求改动导致删掉或者注释掉部分代码;
    • OTHER:(项目名称)-(暂无)

为什么要考虑加一个项目名称?

因为每一笔代码提交都是你对公司的贡献,软件不像硬件或者其他部门,衡量软件开发的一个指标就是代码提交,可以不用很多,但是必须提交,并且每笔提交需要有对应的简述,让同伴知道你在做什么项目的什么功能;这很有必要;

为什么很有必要?

提交代码一般不写提交说明就提交上去了,我相信很多人都干过这事。比如这样的

有些人说,要说明好烦啊,我就不想写,不就是把代码存在服务器吗?然而,仅仅是这样吗?

设想一下,有一天,你发现你的代码错了,你想把之前的那段代码找回来,可是,当我看着代码提交历史的时候,你根本不知道你要恢复到那一笔,是不是很恐怖的事,为了解决,你说,我重写一下,假如功能小还好说,如果是很大的功能呢,还有,你恢复一下,比你重写花费的时间少多了,不是吗?

还有你年终总结的时候,翻一番自己的提交历史,就知道你完成了啥;

  • 今年完成了什么项目?

  • 修改了哪些bug;

  • 哪些bug让你印象深刻;

是不是规范这东西,挺有用;

规范,就是用来约束你的行为准则,一旦公司有新成员进入,看看规范,立马就能融入到工作中,站在公司的角度,不会因为一个人的得失,而使得项目推进变得困难;


☛兄dei,请我喝杯茶☚
%