这篇杂谈是脑子里回荡了很久,觉得有必要说一下;
最近感觉工作起来,越来越没有激情了;
作为公司唯一的IOS开发,还要兼顾APP的一些进展,鉴于公司的现实,产品,项目改了需求,或者计划,我从来都是后知后觉,我很不喜欢这种感觉,快2年来,历来都是参照Android的APP开发,公司项目整体一再delay,从未改观;
幸运的是,公司管理层,正在积极通过一些制度来改善当前的问题;
说了这么多,跟规范有什么关系呢?废话,当然有关系,规范是基础,是让所有人的力量往一处使;
规范,什么是规范?为什么要有规范?
大家都听过，无规矩不成方圆，国有国法，家有家规，公司部门应该也要有规范.
什么是规范呢？
规：从字面意思就是规定，规则，更深层次的来源就是，看这个字，左边是丈夫的夫，右下是一个儿子，古代女子嫁夫从夫，夫死从子，不难看出，这个字就是，你来了，你就得遵循我这儿的规矩 范：从字面意思就是，范围，模范 这俩字合起来就是，大家按照约定，彼此遵循的一个示范，用来约束大家的一种东西； 简言之，规范就是次一点的标准； 我们不搞标准，因为标准的定义太高了，所以我希望我们大家把自己部门的规范做好 另外，规范是大家制定的，也是需要大家遵守的，要不然，不执行，规范就是一纸空文；
规范有哪些
规范有研发部门通用规范,比如会议纪要当天写当天发,周报等;
部门规范,比如代码gerrit提交规范,内测发布规范；
跨组规范: API文档规范等等；
代码提交规范
这里简单分享一下APP组的提交规范
总要求：多笔提交，养成好代码提交习惯；
格式规范：
- Bug修改类：
- (项目名称)-FixBug:#编号-描述
- 业务开发类：
- ADD:(项目名称)-#(需求编号)小的功能就提交，项目初始化；
- UPDATE:(项目名称)-(修改优化)描述
- DELETE:(项目名称)-需求改动导致删掉或者注释掉部分代码；
- OTHER：(项目名称)-（暂无）
为什么要考虑加一个项目名称?
因为每一笔代码提交都是你对公司的贡献,软件不像硬件或者其他部门,衡量软件开发的一个指标就是代码提交,可以不用很多,但是必须提交,并且每笔提交需要有对应的简述,让同伴知道你在做什么项目的什么功能;这很有必要;
为什么很有必要?
提交代码一般不写提交说明就提交上去了，我相信很多人都干过这事。比如这样的
有些人说，要说明好烦啊，我就不想写，不就是把代码存在服务器吗？然而，仅仅是这样吗？
设想一下，有一天,你发现你的代码错了，你想把之前的那段代码找回来，可是，当我看着代码提交历史的时候，你根本不知道你要恢复到那一笔,是不是很恐怖的事,为了解决,你说,我重写一下,假如功能小还好说,如果是很大的功能呢,还有,你恢复一下,比你重写花费的时间少多了,不是吗?
还有你年终总结的时候,翻一番自己的提交历史,就知道你完成了啥;
-
今年完成了什么项目?
-
修改了哪些bug;
-
哪些bug让你印象深刻;
是不是规范这东西,挺有用;
规范,就是用来约束你的行为准则,一旦公司有新成员进入,看看规范,立马就能融入到工作中,站在公司的角度,不会因为一个人的得失,而使得项目推进变得困难;
