CODING DevOps 线下沙龙回顾一:DevOps 代码质量实战

腾讯云CODING举办的DevOps技术沙龙聚焦代码质量和效能,分享了如何通过代码规范、Lint工具、持续集成以及自动化测试来确保和提高软件质量。建议采用IDE、Git commit hook和服务端检查结合的方式强制执行代码规范,并利用持续集成进行质量内建。此外,提倡开发人员自测并编写测试代码以增强代码信心,提倡尽早引入自动化测试以应对业务增长和回归测试挑战。

11 月 22 日,由 CODING 主办的 DevOps 技术沙龙系列「质量」专场在上海圆满结束。在活动现场,四位来自腾讯等知名企业的技术大咖们分享了研发质量与效能的实战经验,与观众们共同探讨如何采取有效手段以保证和提高软件质量。

在这里插入图片描述

本期沙龙回顾为大家带来的,是来自腾讯云 CODING 布道师杨周的议题——《DevOps 代码质量实战》

问题:人越来越多,代码越来越乱

在这里插入图片描述

随着团队成员增多,每个人在缩进、换行、空格以及大小写方面有不同的习惯,导致代码越来越乱。代码风格问题尚且不致命,更严重的是这些问题:

  • Hard code:在代码中书写各种环境配置、链接、密钥,导致安全风险
  • 魔法数字(Magic Number):难以理解和维护
  • 代码行数过多:难以维护,违反面向对象的 SOLID 原则

不少业界大厂公布了代码规范,推荐大家直接采用,因为自己发明规范往往不够全面,很难服众。

代码规范不只是缩进换行问题,通过强制约束圈复杂度、文件行数和方法行数,可促使大家按照面向对象的方式设计。

如何强制执行代码规范

有了代码规范,但怎么落地?是很多团队面临的问题。Lint 程序用来检查代码规范,各个语言(比如 Kotlin、Java、PHP)都有自己的规范和 Lint。

自动检查代码规范有三个时机:

  • IDE:最实时方便的,但需要所有人进行配置、某些 IDE 可能不支持
  • Git commit Hook:提交时,会调用命令行工具强制检查,优点是非常及时,然而存在可被删除的风险
  • 服务端:在 Git push 之后,在服务端进行检查,很可靠,但缺点是不够实时
    因此,建议同时使用这三种方式。

在这里插入图片描述

在代码检查之后,如何处理?老项目有成千上万处不规范,很显然不能一次清理干净,让所有人停下老项目去清理老代码并不现实,而且一次改动太多文件的风险也很高。因此建议使用增量检查,尤其是 Java 增量检查方案比较复杂,详情可识别下图二维码阅读 CODING 文档

在这里插入图片描述

服务端检查:建议使用持续集成(持续不断地把代码集成到主干,实现质量内建)。流程为:锁定 Git 主干,所有人开发功能拉取小分支,小分支提交后触发持续集成进行代码规范检查,通过之后再通知同事进行代码评审,通过这套流程来提高代码质量。CODING 持续集成兼容 Jenkins,图形化界面易上手,如果项目已经在用 Jenkins 可平滑迁移。

在这里插入图片描述

代码整洁了,但结果正确吗?

很多项目到最后面临的困境——没有人敢改老代码。比如开发人员会把已有函数如get() 复制一份再修改,变成了 get1()、get2(),这种做法导致项目逐渐溃烂。根源在于没有人知道修改老代码会不会导致其他地方调用出错。

在开发和测试分离的团队架构中,一个负责任的开发者在写了代码之后要自测,然后提测给测试人员。但是后期大家逐渐会变得不耐烦,从自测 10 种情况到 5 种情况,再到只测一种,最后到完全不自测直接提测,所有的压力都慢慢转移到了测试人员身上。负责任的开发逐渐变成不负责任的开发,问题还是出在机制上。

国外十几年前就开始这个方案:测试人员转岗学编程开发,仅保留少部分的人工测试。开发人员自己写测试代码,测试覆盖率不达标(比如 80%)则禁止合并。

开发人员如何对自己的代码有信心?不是靠聪明才智,因为人总会百密一疏,即使顶尖的程序员也可能会犯最初级的问题,因此自己写测试代码才是最可靠的方案,测试代码覆盖了多种边界情况,即使其他人来改写代码也无需担心挂掉。

最晚什么时候开始自动化测试?

自动化测试很好,但是也面临困境:业务太忙,没有时间写测试代码。

从个人职业发展的角度,把手动操作 Postman 自测的时间用来写自动化测试代码,这样一来,自己的水平得到了提高,后续改代码的时候重测时间也得到了节省,不再是一直堆业务代码,难以成长。

以前中国的大公司项目质量普遍十分糟糕,因为前 20 年是 2C 的红利期,大家在快速抢占市场,但现在到了守地盘的时候,这两年大公司开始重视代码质量问题,建议大家为这个机遇早做准备。

从公司角度,主要看时机。比如 2C 项目逐渐成熟,用户量变大,线上的故障损失已经大于多招开发人员的成本,或者随着项目功能逐渐增加,回归测试时间越来越长,如果一个网站一天上线多次,一天把整个网站所有功能测过来是不实际的,因此自动化测试才能保障持续的高上线频率。而 ToB 项目初期出现了严重 bug 可能就要赔偿客户,因此初期就需要自动化测试。

代码质量评级标准:从下图中可以看到,“优”级别的代码质量标准圈复杂度最多允许 5,类行数不能超过 50,函数行数不能超过 10,测试覆盖率需达到 90%。CODING的合作伙伴优普丰提供了 CSD 认证培训,能够帮助开发者们达到相应的标准,可识别二维码了解详情。

在这里插入图片描述

那么本次的分享就到这里,大家可以前往 B 站观看演讲视频并获取完整 PPT,或者前往 CODING 了解更多。

<think>嗯,用户想了解腾讯云原生服务器支持工程师的工作内容和招聘要求。这个问题很具体,应该是求职或转行前的职业调研。 从用户提问方式看,ta可能已经有技术基础,但不确定云原生支持岗位的具体职责。需要区分几个概念:"原生服务器"可能指腾讯云自研的星星海服务器,而"支持工程师"属于售后技术服务岗。 先拆解工作内容部分。这类岗位通常需要:处理客户关于云服务器产品的问题(如配置、部署、故障),这需要熟悉IaaS层技术栈;具备容器化和微服务支持能力,因为云原生客户多用Kubernetes;参与自动化运维工具链建设,这点从引用[4]提到的腾讯云技术生态可见斑。 招聘要求方面,用户可能更关心硬性条件。根据行业惯例,这类岗位通常要求:计算机相关专业本科(参考引用[2]的数据库专家背景);2年以上云平台运维经验;至少精通种编排工具(如TKE);网络知识必须扎实(VPC/负载均衡等)。证书不是必须但CKA/腾讯云认证会是加分项。 注意到引用[3][5]提到腾讯云在直播、AI场景的应用,建议补充应用场景案例,这样用户能更直观理解工作价值。不过引用[1]的开发者活动信息时效性较强,可能不适合作为招聘要求的参考。 需要提醒用户注意:不同级别岗位要求差异较大。例如初级岗可能侧重故障排查(如引用[3]的时间戳同步这类具体问题),而高级岗会涉及架构优化(类似引用[2]的数据库规划经验)。最后生成的三个问题中,职业发展路径可能对用户最有价值。</think>以下是关于**腾讯云原生服务器支持工程师**的工作内容与招聘要求的综合说明(基于行业标准及腾讯云技术体系特点): --- ### **、核心工作内容** 1. **云产品技术支持** - 处理客户关于腾讯云服务器(CVM)、容器服务(TKE)、Serverless(SCF)等IaaS/PaaS产品的技术咨询与故障排查,涉及网络配置(VPC/CLB)、存储(CBS)、安全组等模块。 - 解决操作系统(Linux/Windows)、容器化应用(Docker/Kubernetes)及微服务架构的部署、性能优化问题。 2. **云原生生态支持** - 协助客户在腾讯云上落地云原生方案,包括容器编排(TKE)、服务网格(TCM)、持续集成(CODING DevOps)等,提供架构设计建议与最佳实践指导[^3]。 - 对无服务器架构(SCF)及微信小程序云开发场景提供深度支持[^1][^4]。 3. **运维自动化与工具链** - 推动自动化运维体系建设,利用腾讯云监控(Cloud Monitor)、日志服务(CLS)等工具实现故障预警与根因分析。 - 编写技术文档与解决方案案例,沉淀知识库(参考腾讯云专家文档体系[^2])。 4. **客户协作与反馈闭环** - 联动产品经理与研发团队,推动产品优化(如直播答题方案中的时间戳同步机制[^3])。 --- ### **二、典型招聘要求** #### **硬性技能** 1. **技术基础** - 精通Linux系统管理、网络协议(TCP/IP/HTTP)及Shell/Python脚本开发。 - 熟悉Kubernetes、Docker等容器技术,具备云原生应用运维经验。 - 了解主流云服务模型(IaaS/PaaS/SaaS)及腾讯云核心产品体系。 2. **云平台实操能力** - 具备腾讯云/AWS/Aliyun等公有云平台运维认证(如腾讯云TCA/TCP证书)。 - 熟悉自动化运维工具(Ansible/Terraform)及监控系统(Prometheus/Zabbix)。 #### **软性素质** 1. 强技术沟通能力,能向非技术人员解释复杂问题(参考客户支持场景[^4])。 2. 系统性思维,擅长从海量日志中定位问题(借鉴大数据分析经验[^2][^5])。 3. 快速学习能力,跟进云原生技术演进(如Service Mesh、Serverless)。 #### **优先条件** - 熟悉Go/Java微服务开发或微信生态集成[^4]。 - 有大型分布式系统运维经验(参考腾讯数据库专家背景[^2])。 - 具备开发者社区支持经验(如参与技术沙龙[^1])。 --- ### **三、职业发展路径** ```mermaid graph LR A[初级支持工程师] --> B[云原生专项支持] B --> C{技术方向} C --> D[架构师/解决方案专家] C --> E[运维开发工程师] B --> F{管理方向} F --> G[技术支持团队负责人] ``` ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值