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

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

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

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

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

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

请问后续如何了。

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

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

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

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

• 代码规范

阿里、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，反馈了一下，最终没搞。

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

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

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

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

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

你说的没毛病,不要怂

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

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