一、为什么要有开发流程做软件开发最怕的不是代码写不出来而是大家各做各的最后发现需求理解不一样、代码互相影响、上线之后问题一堆。所以我们需要一套基本流程。它不是为了增加麻烦也不是为了让大家填表走形式而是为了让事情更清楚谁负责什么、什么时候做什么、做完之后怎么检查、出问题了怎么处理。一个好的流程应该让开发更顺不应该让人觉得是在被流程拖着走。二、需求阶段先把事情说清楚开发之前最重要的是先搞清楚要做什么。产品、业务或客户提出需求后不能马上就开始写代码。开发人员需要先确认几个问题第一这个功能是为了解决什么问题。第二用户使用这个功能的场景是什么。第三这个功能做到什么程度算完成。第四有没有特殊限制比如时间、权限、数据、安全等。第五哪些内容这次不做避免后面不断加东西。如果需求比较简单可以用文字说明清楚如果需求比较复杂最好配上流程图、页面草图或示例数据。需求确认之后相关人员要达成一致。简单来说就是大家都知道这次要做什么不能开发做到一半才发现理解错了。三、评估阶段先估一下工作量需求清楚之后开发人员需要评估工作量。评估不是随便拍脑袋说几天而是要看这个功能涉及哪些地方比如前端页面、后端接口、数据库、第三方服务、测试工作、上线风险等。如果发现需求有问题要及时提出来。比如有的功能看起来简单但实际会影响很多老功能有的需求说得不够细开发起来容易出现争议。这些都应该在开始前说明白。评估完成后需要确定大概的开发时间、测试时间和上线时间。时间不一定要精确到小时但要有一个大家都认可的计划。四、设计阶段复杂功能要先想好方案不是所有功能都需要写很复杂的设计文档。小功能可以简单说明一下实现思路大功能则需要提前设计。设计阶段主要是为了避免边写边改。要提前想清楚数据怎么存、接口怎么传、页面怎么展示、异常情况怎么处理、以后好不好维护。如果一个功能会影响系统核心部分最好让团队里有经验的人一起看一下方案。这样可以提前发现问题减少返工。设计文档不需要写得特别花哨只要能让别人看懂就行。重点是清楚、实用、方便后面查阅。五、开发阶段按规范写代码进入开发阶段后开发人员要按照团队约定的代码规范来写。代码命名要清楚不要随便起一些别人看不懂的名字。一个方法尽量只做一件事不要把所有逻辑都塞在一起。重复的代码要尽量整理出来方便以后维护。开发过程中要注意保护已有功能。不能为了实现一个新功能把老功能搞坏了。涉及公共代码、数据库结构、核心逻辑时要特别小心。如果开发中发现需求有变化不能自己随便改。要及时和相关人员沟通确认之后再调整。六、自测阶段开发不能只写完就交功能写完以后开发人员要先自己测试一遍。自测不是简单点一下页面就结束而是要按照正常使用场景走一遍也要考虑一些异常情况。比如输入为空怎么办、数据不存在怎么办、权限不够怎么办、网络异常怎么办。如果是接口功能要检查接口返回是否正确。如果是页面功能要检查页面显示是否正常。如果涉及数据修改要确认数据有没有写错。如果影响老功能也要顺手回归一下相关功能。只有开发人员自己确认基本没问题后才应该交给测试人员。七、代码提交提交记录要写明白代码提交时要注意提交内容和提交说明。一次提交最好只处理一类问题不要把很多无关修改混在一起。这样以后查问题时比较容易定位。提交说明要写清楚本次改了什么比如“新增用户导出功能”“修复订单状态显示错误”“优化登录校验逻辑”。不要只写“修改”“提交代码”“fix”这种看不出内容的说明。如果团队要求代码合并前必须走审核流程就要按要求提交审核。八、代码审核不是挑刺是互相把关代码审核的目的不是为难别人而是帮团队减少问题。审核时主要看几个方面代码是否容易理解逻辑是否合理是否有明显漏洞是否影响老功能是否符合团队规范。审核人员提出意见时尽量说清楚原因不要只说“不行”。开发人员看到意见后也不要觉得是在被否定。大家的目标都是一样的就是把功能做好。重要功能最好不要一个人写完就直接上线至少要有人帮忙看一眼。九、测试阶段尽量在上线前发现问题测试人员拿到功能后要根据需求说明进行测试。测试时不仅要看功能是否能用还要看功能是否好用、边界情况是否正常、异常提示是否清楚、数据是否准确。发现问题后要记录清楚问题现象、操作步骤、测试环境、相关截图或日志。这样开发人员才能更快定位问题。开发修复后测试人员需要重新验证。不能只看开发说修好了就算结束。十、上线前准备不要临时手忙脚乱上线前要确认几件事。首先需求范围内的功能已经开发完成并测试通过。其次相关代码已经合并到正确分支。再次数据库脚本、配置文件、依赖服务等都已经准备好。另外如果上线失败要有回退方案。上线前最好列一个简单清单逐项确认。这样可以减少遗漏。如果是重要版本最好提前通知相关人员比如产品、测试、运维、客服等让大家知道什么时候上线、上线内容是什么、可能会影响哪些功能。十一、上线阶段按步骤操作上线时要按照既定步骤执行不要临时改来改去。上线过程中如果需要执行数据库脚本要先确认执行环境避免把测试库和正式库弄混。配置修改也要仔细检查不能少配、错配。上线完成后要进行简单验证确认核心功能正常。比如登录、主要页面、关键接口、主要业务流程等。如果上线后发现严重问题要及时评估是否回退。不要为了面子硬撑影响用户使用才是最大问题。十二、上线后跟进事情不是上线就结束功能上线后还需要观察一段时间。要关注系统日志、用户反馈、异常报警、数据变化等。如果发现问题要及时处理。对于上线后出现的问题要记录下来后面复盘时分析原因。是需求没说清楚还是开发没考虑到还是测试没覆盖到还是上线流程有遗漏。流程规范不是一成不变的。每次发现问题都可以把流程改得更好一点。十三、文档管理重要内容要留下记录开发过程中产生的重要信息要适当记录。比如需求说明、设计方案、接口文档、数据库变更、上线记录、问题处理记录等都应该保存到团队统一的位置。文档不需要写得很复杂但要方便别人查。尤其是以后有人接手项目时能通过文档快速了解系统情况。没有文档的项目时间一长就会变成“只有老员工知道”的项目这对团队很不利。十四、沟通要求有问题早点说软件开发不是一个人关起门来写代码。遇到问题要及时沟通。需求不清楚要问。时间不够要说。技术上有风险要提前提醒。影响其他人工作要提前通知。发现线上问题要及时同步。很多项目出问题不是因为技术不行而是因为沟通太晚。等问题已经很大了再说处理起来就会很被动。十五、基本原则整个开发流程可以总结成几句话需求先确认不要边猜边做。开发有计划不要想到哪写到哪。代码要清楚不要只让自己看懂。提交要规范不要乱合代码。测试要认真不要只测正常情况。上线要谨慎不要临时抱佛脚。问题要复盘不要同样的坑反复踩。十六、结语软件开发流程规范的目的不是让大家多做无意义的事情而是让项目更稳定、协作更顺畅、问题更少。流程不需要特别复杂但必须清楚、可执行。只要每个人都按照基本流程来做很多低级错误都可以提前避免项目质量也会慢慢提高。真正好的流程是让团队做事更省心而不是更累。
软件开发搞清楚这些避免踩坑！！！
一、为什么要有开发流程做软件开发最怕的不是代码写不出来而是大家各做各的最后发现需求理解不一样、代码互相影响、上线之后问题一堆。所以我们需要一套基本流程。它不是为了增加麻烦也不是为了让大家填表走形式而是为了让事情更清楚谁负责什么、什么时候做什么、做完之后怎么检查、出问题了怎么处理。一个好的流程应该让开发更顺不应该让人觉得是在被流程拖着走。二、需求阶段先把事情说清楚开发之前最重要的是先搞清楚要做什么。产品、业务或客户提出需求后不能马上就开始写代码。开发人员需要先确认几个问题第一这个功能是为了解决什么问题。第二用户使用这个功能的场景是什么。第三这个功能做到什么程度算完成。第四有没有特殊限制比如时间、权限、数据、安全等。第五哪些内容这次不做避免后面不断加东西。如果需求比较简单可以用文字说明清楚如果需求比较复杂最好配上流程图、页面草图或示例数据。需求确认之后相关人员要达成一致。简单来说就是大家都知道这次要做什么不能开发做到一半才发现理解错了。三、评估阶段先估一下工作量需求清楚之后开发人员需要评估工作量。评估不是随便拍脑袋说几天而是要看这个功能涉及哪些地方比如前端页面、后端接口、数据库、第三方服务、测试工作、上线风险等。如果发现需求有问题要及时提出来。比如有的功能看起来简单但实际会影响很多老功能有的需求说得不够细开发起来容易出现争议。这些都应该在开始前说明白。评估完成后需要确定大概的开发时间、测试时间和上线时间。时间不一定要精确到小时但要有一个大家都认可的计划。四、设计阶段复杂功能要先想好方案不是所有功能都需要写很复杂的设计文档。小功能可以简单说明一下实现思路大功能则需要提前设计。设计阶段主要是为了避免边写边改。要提前想清楚数据怎么存、接口怎么传、页面怎么展示、异常情况怎么处理、以后好不好维护。如果一个功能会影响系统核心部分最好让团队里有经验的人一起看一下方案。这样可以提前发现问题减少返工。设计文档不需要写得特别花哨只要能让别人看懂就行。重点是清楚、实用、方便后面查阅。五、开发阶段按规范写代码进入开发阶段后开发人员要按照团队约定的代码规范来写。代码命名要清楚不要随便起一些别人看不懂的名字。一个方法尽量只做一件事不要把所有逻辑都塞在一起。重复的代码要尽量整理出来方便以后维护。开发过程中要注意保护已有功能。不能为了实现一个新功能把老功能搞坏了。涉及公共代码、数据库结构、核心逻辑时要特别小心。如果开发中发现需求有变化不能自己随便改。要及时和相关人员沟通确认之后再调整。六、自测阶段开发不能只写完就交功能写完以后开发人员要先自己测试一遍。自测不是简单点一下页面就结束而是要按照正常使用场景走一遍也要考虑一些异常情况。比如输入为空怎么办、数据不存在怎么办、权限不够怎么办、网络异常怎么办。如果是接口功能要检查接口返回是否正确。如果是页面功能要检查页面显示是否正常。如果涉及数据修改要确认数据有没有写错。如果影响老功能也要顺手回归一下相关功能。只有开发人员自己确认基本没问题后才应该交给测试人员。七、代码提交提交记录要写明白代码提交时要注意提交内容和提交说明。一次提交最好只处理一类问题不要把很多无关修改混在一起。这样以后查问题时比较容易定位。提交说明要写清楚本次改了什么比如“新增用户导出功能”“修复订单状态显示错误”“优化登录校验逻辑”。不要只写“修改”“提交代码”“fix”这种看不出内容的说明。如果团队要求代码合并前必须走审核流程就要按要求提交审核。八、代码审核不是挑刺是互相把关代码审核的目的不是为难别人而是帮团队减少问题。审核时主要看几个方面代码是否容易理解逻辑是否合理是否有明显漏洞是否影响老功能是否符合团队规范。审核人员提出意见时尽量说清楚原因不要只说“不行”。开发人员看到意见后也不要觉得是在被否定。大家的目标都是一样的就是把功能做好。重要功能最好不要一个人写完就直接上线至少要有人帮忙看一眼。九、测试阶段尽量在上线前发现问题测试人员拿到功能后要根据需求说明进行测试。测试时不仅要看功能是否能用还要看功能是否好用、边界情况是否正常、异常提示是否清楚、数据是否准确。发现问题后要记录清楚问题现象、操作步骤、测试环境、相关截图或日志。这样开发人员才能更快定位问题。开发修复后测试人员需要重新验证。不能只看开发说修好了就算结束。十、上线前准备不要临时手忙脚乱上线前要确认几件事。首先需求范围内的功能已经开发完成并测试通过。其次相关代码已经合并到正确分支。再次数据库脚本、配置文件、依赖服务等都已经准备好。另外如果上线失败要有回退方案。上线前最好列一个简单清单逐项确认。这样可以减少遗漏。如果是重要版本最好提前通知相关人员比如产品、测试、运维、客服等让大家知道什么时候上线、上线内容是什么、可能会影响哪些功能。十一、上线阶段按步骤操作上线时要按照既定步骤执行不要临时改来改去。上线过程中如果需要执行数据库脚本要先确认执行环境避免把测试库和正式库弄混。配置修改也要仔细检查不能少配、错配。上线完成后要进行简单验证确认核心功能正常。比如登录、主要页面、关键接口、主要业务流程等。如果上线后发现严重问题要及时评估是否回退。不要为了面子硬撑影响用户使用才是最大问题。十二、上线后跟进事情不是上线就结束功能上线后还需要观察一段时间。要关注系统日志、用户反馈、异常报警、数据变化等。如果发现问题要及时处理。对于上线后出现的问题要记录下来后面复盘时分析原因。是需求没说清楚还是开发没考虑到还是测试没覆盖到还是上线流程有遗漏。流程规范不是一成不变的。每次发现问题都可以把流程改得更好一点。十三、文档管理重要内容要留下记录开发过程中产生的重要信息要适当记录。比如需求说明、设计方案、接口文档、数据库变更、上线记录、问题处理记录等都应该保存到团队统一的位置。文档不需要写得很复杂但要方便别人查。尤其是以后有人接手项目时能通过文档快速了解系统情况。没有文档的项目时间一长就会变成“只有老员工知道”的项目这对团队很不利。十四、沟通要求有问题早点说软件开发不是一个人关起门来写代码。遇到问题要及时沟通。需求不清楚要问。时间不够要说。技术上有风险要提前提醒。影响其他人工作要提前通知。发现线上问题要及时同步。很多项目出问题不是因为技术不行而是因为沟通太晚。等问题已经很大了再说处理起来就会很被动。十五、基本原则整个开发流程可以总结成几句话需求先确认不要边猜边做。开发有计划不要想到哪写到哪。代码要清楚不要只让自己看懂。提交要规范不要乱合代码。测试要认真不要只测正常情况。上线要谨慎不要临时抱佛脚。问题要复盘不要同样的坑反复踩。十六、结语软件开发流程规范的目的不是让大家多做无意义的事情而是让项目更稳定、协作更顺畅、问题更少。流程不需要特别复杂但必须清楚、可执行。只要每个人都按照基本流程来做很多低级错误都可以提前避免项目质量也会慢慢提高。真正好的流程是让团队做事更省心而不是更累。
