password
tags
type
status
date
slug
summary
category
icon
day day up
通过公司面试，租好房子，忐忑、焦躁和期待的心情等入职。
进入公司，办理入职，办公电脑配环境，例如Git、VPN、IDE、Navicat配置，熟悉办公环境和认识同事。有些公司Git私有仓库不支持https方式拉取，需要配置ssh方式
产品老师派发需求文档给你并告知deadline，你基于这个需求开始熟悉公司的项目，分析需求涉及到的功能。
- 如果是新增接口那么需要和前端对接接口，确认好入参和回参，并和导师确认走的哪个项目或者可以参考别的相似接口。
- 如果是改造接口那么需要在客户端侧（浏览器）关注触发的请求，包括请求方式、地址和参数。看公司是否接入全链路追踪trace，接入过可以在阿里云/腾讯云日志根据traceid查询请求链路，在微服务架构下的今天，能快速定位到项目涉及到的代码项目。
经历上述选择，确认好本次需求涉及到的项目，就可以去公司代码仓库拉取代码了！
- 注意在拉取代码前，确保本地Git配置完成（SSH或账号密码形式）
- 拉取代码，点击clone，以https或ssh方式拉取，拉取项目的master分支到本地
拉取到本地后，IDE打开，浏览项目大致结构/层次，找到接口触发的方法。
代码拉到本地了，你可能由于配置/依赖问题导致本地项目还跑不起来，询问配置文件在哪里，这时候可以询问正式员工本地如何启动项目，项目可以正常启动后说明配置文件有效。
- Java SpringBoot项目，安装项目依赖一般使用maven，依赖导入后，运行main函数会加载yaml文件，启动参数-D优先级更高
- Go Gin项目，安装项目依赖一般使用go module，依赖导入后，运行main函数
- PHP Laravel项目，安装项目依赖一般使用composer，依赖导入后，可运行php artisan serve 进行项目启动，默认读取.env文件
此时开始编写技术方案了，需求背景，增加的功能，你的缓存设计和数据库设计，在设计技术方案时，需要注意下述原则：
- 尽量缩小改动的影响范围，避免对其他接口或功能造成不必要的影响
- 仔细评估修改可能带来的副作用(check细节)
- 考虑向后兼容性，确保现有功能不会因新的改动而出现问题
- 如果必须进行较大范围的修改，要充分测试并制定回滚计划
好了，此时技术方案写的差不多了，挑一个好日子，拉日程邀请后端、前端伙伴，探讨技术方案可行性，会议结束后基本上可以上手开发了。
你基于master分支，创建本次需求的开发分支
代码编写时，要注意提升程序的健壮性。以下是一些提高代码健壮性的关键点：
- 进行充分的错误处理和异常捕获，避免程序因未预期的错误而崩溃
- 对输入参数进行严格的校验，包括类型检查、边界值检查等
- 使用日志记录关键操作和错误信息，便于问题定位和调试
- 考虑并发情况下的数据一致性，使用适当的锁机制或事务控制
- 进行资源管理，确保资源（如数据库连接、文件句柄）在使用后被正确释放
- 使用配置文件管理可变参数，增强程序的灵活性
- 编写单元测试和集成测试，覆盖各种可能的场景
通过以上措施，可以大大提高代码的质量和可靠性，减少生产环境中出现意外问题的可能性。
开发完成后，编写测试用例，对自己的函数进行简单校验，断言
- Java中SpringBoot项目，使用Spring集成的SpringBootTest注解进行测试
- PHP中Laravel项目，在根目录tests目录下编写测试用例
- Go项目，默认在tests目录下进行编写测试用例
单元测试结束，开始本地调试接口，运行你分支的项目，使用postman/apifox等工具进行接口测试，入参和回参，观察接口是否正确。（ps：有些公司有内部的自动化测试平台）
此时本地测试完了，你想和前端哥们联合调试功能，但是他改动在他的电脑，你改动在你的电脑，你两个怎么关联起来？
在我们的软件开发的周期中，有多个环境
- dev：本地开发环境，一般由开发人员在本地进行调试使用，一般是feature/xxx分支
- staging：测试环境，由开发人员在线上环境测试，数据库、Redis走的是测试数据库，对应staging分支
- pre：预发布环境，由开发人员在线上环境测试，数据库、Redis现在是和生产数据库用的同一个，对应pre_master分支
- product：生产环境，真实用户使用的环境，对应master分支
所以，想要实现调试，那么你和前端哥们都需要把自己的代码合并到staging分支
代码提上去了，我要staging分支，这咋测？你应该也可能知道了，我要把该项目的staging分支重新部署！！我不会啊，此时刚到公司的你，询问一下同事或者运维老师，重新启动一下项目。如果用的是Jenkins，那么就简单了，让同事给你开个账号，搜索对应的项目，进行重新部署即可！然后就可以愉快的测试啦～
这里额外补充一下，像一些互联网公司（例如：得物、阿里巴巴），使用云原生技术，本地不测试，测试上云，怎么上？说一下大致逻辑，在CI/CD集成平台创建属于自己的染色环境，染色环境关联自己的分支代码，然后点击deploy进行部署（ps：甚至当你本地修改完push代码到远程就会自动帮你重新部署，非常便捷、高效！）还有一个问题，前端怎么走到你的分支环境代码，一般在请求头增加一个参数xxx，值是染色环境id，这样就可以“像调试本地代码一样调试”，非常优雅！
自测、联调差不多了！接下来由测试伙伴开始测试，在测试之前，一般会拉日程show case，也就是不同的测试场景，确认好case后，测试伙伴开始测试！
过了一会/半天，测试伙伴说你接口有问题，给你提缺陷，让你去排查，那咋了？排查呗，可能给你日志/报错信息提供给你，你去排查，看阿里云/腾讯云日志，排查好之后，自测，没问题，提交代码，告知测试可以了！
测试伙伴对所有场景测试通过后，需求开始上预发环境了，上预发环境一般都会在晚上用户活跃度低的时候进行重新部署，部署好之后，测试人员在此环境进行验证。
如果本次需求涉及数据库增加字段/增加索引，需要在公司内部的SQL审查平台提交工单，经过上级、运维审批通过后，在项目上预发布时执行SQL，并进行简单校验
预发布验证没问题，第二天上生产，发布时应编辑好确定的文案（例如上线项目、上线时间、涉及需求）。
生产上线，测试进行回归测试（对已验证通过的功能进行二次测试），全部通过后，本次需求算是完成了！
…重复新的需求，这就是大概的敏捷迭代的开发流程，也是大部分公司采用的。
敏捷开发是一种迭代式的软件开发方法，它强调灵活性、快速响应和持续改进。根据上下文，我们可以看到一个典型的敏捷开发流程包含以下几个主要阶段：
- 需求分析和设计
- 开发阶段
- 测试阶段，包括自测和联合调试
- 环境部署，如开发、测试、预发布和生产环境
- 代码版本控制和合并
- 持续集成和持续部署（CI/CD）
- 测试人员进行全面测试
- 预发布环境验证
- 生产环境上线和回归测试
这个过程是循环进行的，每次迭代都会重复这些步骤，不断地交付新功能和改进。敏捷开发方法允许团队快速适应变化，提高开发效率，并确保产品质量。
- Author:武帅祺
- URL:https://qqqi.top//article/c91f30f2-d8dd-4e02-8b86-56a3a05117c3
- Copyright:本文章为原创内容，版权归作者所有。如需转载，请联系我，谢谢！