研发效能 代码规范、版本控制等求知

Dawson · 2021年06月22日 · 最后由 陈恒捷 回复于 2021年06月24日 · 719 次阅读

寻求开发规范、代码规范、codereview、版本发布等管理的方向以及思路,希望大佬们可以多多发言,多多提点!!!膜拜各位大佬 ing

共收到 13 条回复 时间 点赞

这个问题好大,一时不知道从何说起。而且个人经验,这个东西必须因地制宜的,别人的经验你不一定适用。比如大公司代码规范会配套做 ide 扫描工具、持续集成的自动卡点等,小公司可能就一个文档和 leader 多看几眼代码。

可以简单说下你们的当前情况和主要问题点,这样大家比较好给建议?

如果是想了解那种通用型、讲概念型的,可以社区里搜索下,或者到微信公众号搜索下。

太多了。。。各种安全规范、sonar 指标,这些东西看团队规模和公司的要求。

突然想起了两个人的项目组被强迫搞敏捷的故事。。。

陈恒捷 回复

公司目前想对两个新的系统一个线上商城,一个订单平台,进行一个规范管理,由于一次迁云出现了比较大的规范问题导致迁云时间跨度拉长,比如:代码命名规则,分支管理等不规范,发布管理不规范,没有做好 codereview 等。个人也觉得这是一个很大的题,但是想从某个方面先切入开始进行改造,改造时间长一点也没关系

Ouroboros 回复

请问后续如何了。

Ouroboros 回复

sonar 这个搭建容易,安全的没有做过。请问还有其他的方向吗?不一定是技术层面,也可以是管理层面

Dawson 回复

感觉你的问题和原因有点对不上呀。迁云我理解更多是运维部署层面的,最多和发布管理有一些关系,前面的这些不规范和迁云有什么关系呢?比如代码命名不规范,主要影响其他人的阅读和理解,但不会直接造成缺陷的。建议要先复盘清楚,到底根本原因是在哪里,没有解决根因,其他改进都是吃力不讨好。

另外,要特别留意,这些规范,限制的不仅自己下面的测试团队,更多是开发、运维这些兄弟团队。先和大家沟通好达成共识,这个是大前提。

我按我经历过的大概写下吧:

  • 代码规范

阿里、google 这些大公司都有各个语言的代码规范白皮书这类文档分享出来的,各个语言自己也有自己的一些推荐规范(比如 idea 自带的规则基本是基于这些规范),可以基于这些来调整。我们之前具体的调整是由一些资深开发 + 测试组成的技术委员会来操刀,保障调整的有效性。而且这些人参与了制定过程,后面落地认同感也更强,更容易推进落地。

同时也可以搞一些 bad case 之类的文化活动,分享一下某些不规范的写法会导致什么样的 bug ;或者组织大家看看 clean code 这本书,对怎么写好代码有更好的认识。

  • 分支规范

这个核心就是分支模型了。一般主流就几个,主干开发 + 主干发布,分支开发 + 主干发布,主干开发 + 分支发布。一般需求并行比较多的,采用 分支开发 + 主干发布 会比较多。然后配合 gitlab 提供的 protect 分支特性,可以把主干保护起来,只有 master 权限才能合并,普通开发改不了,只能在自己的分支上修改,然后提 merge request(后面缩写为 MR)来申请合并。

master 一般由团队里对系统比较熟悉的人来做,这样在 MR 的时候做的 code review ,会更有效。同时 MR 也可以定制补充一些自动检查项(如前面大家提到的 sonar 、单测这类),检查结果直接呈现在 MR 中,作为 code review 的参考。

  • code review

这里面东西比较多,比如 review 的时机(赶早不赶晚,谁都无法认真 review 改动行数过千的改动),review 的方式(评审人和写代码的人一起的方式,如 review 会议、结对 review;不在一起的方式,如前面提到的用 MR review ),review 的限制程度(阻塞式,必须 review 通过才能合并和提测,节奏相对慢的用得比较多;非阻塞式,可以提测后再 review,节奏快的更适用)。这块建议微信公众号搜索下吧,以前看到过挺多好文章的。

我们实际落地更多是提测后测试去阅读代码(我们一般不叫 review ),有问题会和开发沟通确认。通过阅读代码可以了解实现逻辑,也能更直接的找到一些问题,比如空指针隐患、if else 的场景不够全、事务性操作没有包到一个事务里等。

  • 版本发布

不知道你们那边运维发布相关的基础设施做到什么程度,是已经做到了一个带审批流程的平台上,还是只是一个 jenkins job ,还是更人工的。如果想 QA 在这个层面上做很大的限制(比如二次确认开发有没有在最后时刻自己加料啥的),那需要在发布的审核流程里加上 QA 这个环节,QA 审核通过才能到实际部署这个步骤。

我们实际落地,审核流程会有 QA 环节,并且 QA 不能只是管审核,还需要在上线后和开发、产品一起通过线上测试/指标监控等手段,确认上线后没问题,为最终上线结果负责。

  • 最后

代码规范、分支规范、code review 这些,本质上更多是在开发阶段做的事情,如果本身开发都没这方面经验甚至想法,需要长期灌输慢慢接受。

要逐步落地,建议可以先从线上问题复盘改进开始,一方面都出事故了,大家容易配合推进;另一方面这些问题一般也是破坏性比较大,最需要解决的问题。

个人经验,任何规范都是约束,都是会产生额外成本的,而且落地最终要靠的还是人。所有的要推行的规范,一定要能解决某些目前存在的实际问题,并和大家取得共识。切勿为了规范而规范,最后变成一张废纸。

PS:正常一个稍微大一点的开发团队,分支规范应该是最基础的协作基础,不可能没有的。建议你先和开发团队沟通下,了解下对于一个新开发进入团队,他们会教些什么,这里面一般就会有代码规范、分支规范这些了。

文中道 回复

太 SB,反馈了一下,最终没搞。

Dawson 回复

上面恒捷回复已经很详细了。
我也建议你针对问题来切入。

规范这个东西,没整好就是束缚。而且这个很多时候会和考核牵扯上,初期往往弄得怨声载道的,需要从上到下的支持。

陈恒捷 回复

感谢大佬,可能我描述的不够准确,不过我确实要对整个团队的规范进行一个管理的分析应用

Dawson #10 · 2021年06月23日 Author
Ouroboros 回复

是的,就怕规范变成束缚,哎,领导任务下来了,难顶啊

陈恒捷 回复

人家说的没毛病,迁云部署,部署的啥?应用,应用服务,迭代,代码库,环境等,我部署时不得涉及到这些命名规范的问题,其中迭代部署中,就涉及到你讲的代码合并问题,什么环境阶段下,哪个代码分支合到什么分支,还有你说的发布管理规范也只是其中一项,其中还涉及到从研发到发布的整个研发流程规范,等等等,都是项目迁云需要考虑以及注意到点

Dawson 回复

你说的没毛病,不要怂

金主 回复

可能我表述也不够清晰。我不是说不涉及这些规范,而是这些规范并不像是导致 迁云时间跨度长 的根本原因。 “因为迁云时间跨度太长了,所以我们要落实代码规范/code review”,这个因果关系不够明确,也说服不了别人。

对于项目跨度时间长,因素会很多。而且很多时候这些地方缺少的不是规范或流程,而是大家的意识。好的程序员,并不会因为规范的缺失而写出很烂的代码,因为规范已经在他意识里面了,没规范他自己也会去制定规范。而改变意识成本是很高的,周期也比较长,需要找好节奏,循序渐进,并且每一步都找到合适切入点。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册