V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
xuhaodong66
V2EX  ›  程序员

你们公司的代码规范是怎么严格执行的?

  •  2
     
  •   xuhaodong66 · 2019-05-14 23:31:14 +08:00 · 3118 次点击
    这是一个创建于 2031 天前的主题,其中的信息可能已经有所发展或是发生改变。

    目前打算这样子:

    公司基于 gitlab 开发,在 gitlab 中新建一个代码规范仓库,每周安排一个人去审查一个项目(非自己),将评审结果的表格提交到仓库中,评审结果指向审查项目的 issue, 在 issue 中指出不规范的地方和正确的示例。

    8 条回复    2019-05-15 10:09:29 +08:00
    windsage
        1
    windsage  
       2019-05-14 23:40:05 +08:00 via Android   ❤️ 1
    committer 机制
    xuhaodong66
        2
    xuhaodong66  
    OP
       2019-05-15 00:15:02 +08:00
    @windsage 可以详细点吗,不太明白
    lizhuoli
        3
    lizhuoli  
       2019-05-15 00:19:58 +08:00 via iPhone   ❤️ 1
    靠 clang-format 等严格的 lint 工具执行,外带一个静态代码扫描(基于 Clang AST 和正则搭配),基本就差不多了,不靠人力用技术手段约束
    feiyuanqiu
        4
    feiyuanqiu  
       2019-05-15 00:47:46 +08:00   ❤️ 3
    代码格式、简单的 bad smell 这类风格问题,本地用 intellij idea + Alibaba Java Coding Guidelines + google-java-format,gitlab 仓库用 gitlab-ci 集成 checkstyle、sonar 等自动化工具任务,绝对比人有效靠谱。

    code review 应该做剩下的自动化工具不擅长的部分,让熟悉业务的人检查代码对需求的实现是否正确合理; reviewer 能否仅凭代码和 commit 信息就看懂代码的逻辑和意图,有任何看不懂的地方就打回去让提交者改。

    另外提一点,code review 最好在代码合并时做,而不是等上线后再巴啦巴啦提一堆问题让别人改,除非 leader 有很大的决心一直推动,否则我不觉得能维持多久,你会一直被问这些问题:程序跑得好好的为什么要改?修改的限期是多久?修改与做新需求的优先级谁高,工作排期紧张时先做需求还是先改代码?代码改了要不要测试?这额外的测试工作量怎么说服测试接受?...
    ihainan
        5
    ihainan  
       2019-05-15 01:03:05 +08:00   ❤️ 1
    所有的新 Feature / Bug Fix 必须开 Issue 来记录,所有提交必须走 PR,PR 需要指向新建的 issue,每个 PR 都会触发 Travis 编译、跑 UT、检查风格( Scalastyle )和检查测试覆盖率( scoverage )。PR 需要指定两个 reviewer,直接用 GitHub 的 Review 功能来给 comment,除了代码逻辑还必须检查是否有测试覆盖新提交的代码,另外每日都有 Jenkins 重新部署环境和跑 FVT。
    lincanbin
        6
    lincanbin  
       2019-05-15 01:14:34 +08:00 via Android   ❤️ 1
    CI 自动化检测咯,出问题抄送 group 里所有成员。
    phobal
        7
    phobal  
       2019-05-15 09:59:55 +08:00   ❤️ 1
    正规开发流程应该是这样的

    1、在开发期检查。前端的话可以配置 ESLint 的代码里面,结合编辑器插件使用,可以在开发期对基础的错误进行检查。
    2、在 commit 期检查。结合 git hooks,可以在 git commit 的时候执行自定义的 hooks,你可以在 hooks 中定义检查规则,不符合规范的无法 commit。
    3、在 merge 之前 review。在 gitlab 中对开发人员配置角色,每个项目指定 2-3 个有 merge 权限的人,其他人没权限将代码提交到 主分支上。规定每一次代码改动必须提 merge request,经过 code review 才能进入第 4 步。
    4、在 merge 之前跑 pipeline。可以在 gitlab 配置 gitlab-ci,在里面集成单元测试、集成测试 等,只有这些都跑过了,才能进行 merge 到主分支。
    xw900812
        8
    xw900812  
       2019-05-15 10:09:29 +08:00   ❤️ 1
    @phobal 没错,我们就是这样的干的。。。尽量自动化,不需要人力来检测。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   4639 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 04:04 · PVG 12:04 · LAX 20:04 · JFK 23:04
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.