架构拾遗（1）——新手必看！白话拆解开发模型方法论
在之前的文章里，我们从计算机的发展唠起，聊了聊软件开发模型那些事儿。不管是老派但经典的瀑布模型、V模型，还是现在互联网公司几乎都在用地Scrum、DevOps模型，都简单过了一遍。
后台有不少刚入行的朋友私信我，说自己刚毕业小半年，干软件开发也才摸门儿，看着这些“方法论”总觉得飘在天上，太空洞了，完全对应不上自己每天写代码、改bug、开小会的具体工作，越看越懵，甚至怀疑这些模型是不是纸上谈兵。
其实真不怪大家，不是我们理解能力不够，是很多讲解都太官方，没结合咱们实际干活的场景。
所以本篇文章，我就彻底放下专业术语，结合咱们实际工作中的角色、每天要做的活儿、要扛的责任，把开发模型和咱们的日常工作绑在一起讲，保证新手也能看明白、用得上，再也不觉得这些方法论是“废话”。
先从最常用的V模型入手，一步步拆明白
咱们先从大家最容易混淆、也最常用的V模型说起。毕竟很多公司，尤其是传统软件公司、刚起步的小团队，都在用这个模型，新手接触最多。
先给大家划个重点，V模型的核心就是先想清楚、设计好，再动手干，干完再一步步测。整个流程像个V字，一边是分析设计，一边是测试验证，对应得明明白白。
具体流程分为：需求分析、系统设计、详细设计、编码、单元测试、集成测试、系统测试、验收测试。
第一步：需求分析——先搞懂用户到底想要啥
V模型的第一步，是需求分析。说句实在的，不管你用哪种开发模型，第一步基本都是干这个，就像盖房子先定图纸，总不能没搞清楚要盖平房还是楼房，就直接挖地基吧？
在标准一点的团队里，这活儿一般是需求工程师来干。收到客户的需求，比如客户说“我要一个能统计销量的系统”，或者公司内部的需求，比如产品说“咱们得加个用户登录的功能”，先坐下来琢磨琢磨。
这个需求到底要做啥、范围有多大，是只统计销量，还是还要生成报表？能不能实现，技术上有没有坑？要花多少功夫，几个人干多久能做完？琢磨完了，会写一份“需求分析文档”存起来，相当于给后续所有工作定个“总规矩”。
这一步的核心，就俩字：搞懂。搞懂用户到底想要啥。
很多时候你会发现，用户自己都没搞懂自己想要啥！比如客户说“我要一个好用的APP”，“好用”到底是啥意思？加载快？界面简单？还是功能多？他也说不清楚。
这也是为啥会有原型模型，这个模型本质就是先画个简单的界面、做个半成品，让客户先看看，看完再改，避免后期返工。
这里给新手一个小建议，用比较直白的话来说：把客户，或者提需求的产品经理，当成“不懂技术的傻子”。别跟他说“接口”“表结构”“逻辑”这些专业词，就用最接地气的话聊。
比如客户说要“统计销量”，你就问：“是只看每天的总销量，还是要分产品、分区域看？要不要导出Excel？能不能手动修改数据？”
多问几句，把模糊的需求变具体，后期能少走很多弯路。
当然，需求工程师也不是万能的。要是碰到涉及开发范围的疑问，比如“这个统计功能要对接第三方接口，能不能实现？”，就会喊研发工程师过来一起评估。要是团队比较小，没专门的需求工程师，这活儿就会落到研发负责人或者老工程师身上。毕竟他们懂技术，能判断可行性。
总结一下，需求分析做完，一定要输出三个核心结论：能不能实现（可行性）、要花多少功夫（多少人做多久）、最后要做成啥样（交付件），缺一不可。
关键提醒：开发模型≠管理模型，别死套理论
按V模型的理论来说，需求评估完，确认能做，就该进入设计阶段了。但新手一定要记住一个关键，V模型只是开发模型，管的是“怎么开发”，不是“怎么管理”。也就是说，理论归理论，实际干活的时候，还得看进度、看资源。
举个你们肯定碰到过的例子，需求评估完，预估要两个研发干一个月，但现在你们团队正在赶当前版本的其他需求，天天加班都忙不完，哪有精力搞新需求的设计？所以这种情况下，就不会马上进入设计阶段，得等当前版本的需求开发完、测试通过，腾出人手了，才会开始新需求的设计。
这也是很多新手困惑的地方，为啥我照着开发模型干活，总觉得不对劲、不顺畅？不是模型没用，是你忽略了一个软件产品的开发，不只有“开发”这一件事，还有产品管理、资源分配、进度把控这些杂事。
比如UP模型(统一过程模型)，就专门加了发布里程碑的环节，把产品管理的内容融入进去了，比V模型更贴近咱们实际的开发生命周期。不过这个模型相对复杂，小团队一般用不上，新手先吃透V模型就够了。
设计阶段：先搭骨架（系统设计），再填肉（详细设计）
闲话说完，咱们接着聊设计阶段。这一步是新手最容易忽略，但最影响后续开发的环节，千万别觉得“设计麻烦，不如直接写代码”。前期设计不到位，后期改bug能改到你怀疑人生。
系统设计，说白了就是“搭骨架”，是架构层面、粗粒度的设计，一般由系统工程师或者系统架构师来干。
核心是想清楚，要实现这个需求，需要用到哪些硬件、软件？内部的组件怎么配合，比如后端的服务和前端的页面怎么联动？外部要对接哪些东西，比如第三方接口、数据库？
这里要区分两种情况。如果是全新开发一个软件产品，或者要加一个新组件、用新架构，那系统设计就非常重要。相当于盖房子先搭框架，框架搭歪了，后续再怎么砌墙都没用。
但如果是在现有产品上加一个小需求，比如“给登录页面加个‘忘记密码’的按钮”，基本不涉及系统架构的变更，这一步就可以简化，不用写复杂的文档。
但新手要注意，哪怕是小需求，系统设计这一步也不能完全跳过。因为V模型里，后续的系统测试，就是照着系统设计文档来测的。
你得写清楚，这个小需求在架构层面要实现啥功能、有啥约束，比如“忘记密码按钮只能点击3次，超过3次锁定”。不然测试人员不知道怎么测，后续很容易出现分歧。
系统设计搞定后，就进入详细设计阶段。这一步就轮到咱们研发人员上场了，也是和新手日常工作最相关的一步。
详细设计就是填肉，把系统设计的“骨架”填满。
比如设计接口怎么写，接口地址、请求方式、返回参数；数据库的表结构，要建哪些表、每个字段是什么类型；具体的实现逻辑，比如“忘记密码后，验证码有效期10分钟”；界面长啥样，按钮放哪里、字体多大。每一个细节都要想清楚、写明白。
后续的编码工作，全靠这份详细设计文档。你照着文档写代码，就不会跑偏；要是文 档写得模糊，你写着写着就会发现，自己不知道该怎么继续，甚至写出来的代码和别人的对接不上。所以新手刚开始干活，一定要养成“先设计、再编码”的习惯，别急于求成。
设计评审：别自己瞎琢磨，多找别人看看
这里插一句，需求分析、系统设计、详细设计做完后，输出的文档都要做“评审”。说白了就是找几个人看看，有没有问题、要不要调整。评审没有固定的标准，全看团队大小和需求复杂度。
小团队、简单需求，几个人凑在一起，面对面看文档。比如研发、产品、测试各来一个，你说你的设计思路，别人提提意见，比如“这个接口设计得太复杂，不如简化一下”，改一改就完事了，不用搞太复杂。
大团队、复杂需求，就会比较正式。QA会全程监督，发起好几轮评审流程，每个人都要在系统上提交意见，改完还要再评审，直到所有人都认可。这也是为了避免后期出现大问题，毕竟人多力量大，能发现很多你自己忽略的细节。
编码+测试：写完代码不算完，测通才是硬道理
设计评审通过，确认可以开工了，研发人员就可以着手编码了。这就是咱们每天最核心的工作：写代码。
编码的时候，有两个小提醒给新手。
第一，遵守团队的规矩，比如代码规范，变量怎么命名、注释怎么写；Git规范，提交代码的时候怎么写备注、怎么分支管理。别自己随心所欲写，不然别人接手你的代码会崩溃，你自己后期维护也麻烦。
第二，别光顾着写代码，抽空写单元测试。单元测试就是你自己测自己写的代码，比如你写了一个“计算销量”的函数，就写个测试用例，看看输入100、输出是不是100，有没有bug。
说到单元测试，这里要吐槽一句。国内很多公司为了“赶进度、提效率”，不强制研发写单元测试，导致很多新手都不知道单元测试是啥。编码写完直接提交，跳过单元测试，直接进入集成测试。这种做法短期看是快，长期来看，很容易留下隐藏的bug，后期排查起来更费时间。
新手最好养成写单元测试的习惯，哪怕简单写几个，也能减少后期的返工。
集成测试：和同事联调，确保代码能配合运行
编码完成，或者大体完成后，就进入集成测试阶段。说白了，就是“联调”，属于编码的后期工作。
你一个人写的代码没问题，不代表和别人的代码配合起来没问题。比如你写的后端接口，和前端页面对接的时候，能不能正常返回数据？和其他同事写的组件联动的时候，会不会报错？这些都要在集成测试阶段验证。
集成测试很灵活，一般是研发人员之间自己联调。比如后端找前端，“我接口写好了，你那边测测能不能调通”，测的时候发现问题，当场改，不用写复杂的文档、不用提问题单，怎么高效怎么来。
系统测试vs集成测试：别搞混这两个环节
很多新手分不清集成测试和系统测试，觉得两者差不多。其实差别很大，我用大白话给大家分清楚。
集成测试：研发人员自己搞的，不讲究形式，不用写测试用例，核心是“联调通、能运行”，只要和其他组件配合起来没问题就行。
系统测试：要正式很多，研发人员得先写“系统测试用例”，比如“输入正确的账号密码，能登录成功”“输入错误的密码，会提示‘密码错误’”。然后研发人员照着用例一步步测，发现bug要提问题单，研发修复后，刷新版本，再重新测，直到所有用例都通过，才算完成。
简单说，集成测试是自己人内部验收，系统测试是按规矩正式验证，两者缺一不可。
验收测试：最后一关，等着测试人员“挑错”
系统测试通过后，就进入最后一步：验收测试。这一步，真正的测试人员，TC，才会正式介入。
测试人员会参考研发写的系统测试用例，再结合需求分析文档，写一份“验收测试用例”。然后发布一个“验收版本”，部署到专门的测试环境，一步步验证功能。
是不是符合需求？有没有bug？界面是不是和约定的一样？发现bug，就提问题单，研发修复，刷新版本，再测，反复几轮，直到所有验收测试用例都通过，才算验收合格。
验收合格后，这个需求就算开发完成了。要么直接发布给客户用，要么合入主线版本，和其他需求一起发布。
讲到这里，大家应该能发现，测试工作不是“等研发写完代码再干”，而是贯穿整个开发过程的。
从需求分析、设计评审，到编码、联调，都有测试的影子。很多新手觉得“测试是测试人员的事，和我没关系”，其实不然。你写的代码质量越高，测试阶段的bug就越少，后期返工就越少，自己也能少加班。
再聊热门的Scrum：不是模型，是高效干活的框架
聊完V模型，咱们再聊聊现在最火的Scrum。很多互联网公司都在说“我们用敏捷开发”，其实大多时候，他们用的就是Scrum框架。
先给新手澄清一个误区，在之前的文章中我们也提到过，Scrum不是一个“开发模型”，而是一个“工作框架”。
说白了，它不规定你“先设计再编码”，还是“先编码再设计”，而是给你一套工作方法，让团队能高效协作、快速交付功能。
核心就是快、灵活、能及时调整。换成大白话，跟着Scrum的规矩干活，能快速开发、快速交付，不用等所有东西都设计完美再动手，边做边改，效率更高。
Scrum核心角色：搞懂自己该干啥
Scrum框架里，有四个核心角色，新手一定要认清楚，不然很容易搞混自己的定位。
开发团队（Dev Team）：核心中的核心，就是咱们所有研发人员，加上测试人员（TC）。负责具体的开发、测试工作，比如写代码、改bug、联调。产品负责人（PO）：对接需求的人，相当于“需求代言人”。负责接收客户、公司的需求，给需求排序，比如“这个需求紧急，先做；那个需求不紧急，往后放”。然后安排给每个“迭代”，告诉团队“这一轮要做啥”。Scrum Master（SM）：相当于“管家”，不写代码、不提需求。核心工作就是保证Scrum框架能正常落地，比如组织会议、协调资源、解决团队遇到的问题。比如团队有人请假，没人接手工作，SM就去协调。确保团队能按时完成迭代任务。
关键概念：迭代（Sprint）——固定时间内搞定一批需求
这里再解释一个新手常听到的词，迭代（Sprint）。
简单说，迭代就是“一个固定的时间段”，比如两周、一个月。团队在这个时间段内，集中精力完成一批固定的需求，时间一到，就交付成果。
不管有没有做完，都要停下来总结，然后开始下一个迭代。比如团队定了两周一个迭代，这两周就只做PO分配的3个需求，做完就交付，没做完的就放到下一个迭代。
Scrum里不用专门设计？真相是这样
聊到这里，新手可能会有疑问，和V模型比起来，Scrum里好像没有专门的系统设计、详细设计步骤，难道不用设计吗？
不是不用设计，而是Scrum的核心假设和V模型不一样。
V模型认为要先把所有东西设计完美，再动手开发，而Scrum认为没人能一开始就把所有东西设计完美，设计应该跟着需求、代码、用户反馈，一点点进化。
具体怎么操作？给大家讲一个真实的场景，新手一看就懂。
迭代开始前，PO会先梳理“产品待办列表”，就是所有要做的需求。明确这一轮迭代要做哪些需求，然后做一个“概要设计”。
不用写复杂的文档，大概说说每个需求要怎么做、拆分多少个小任务。比如“用户登录功能，拆成‘账号密码验证’‘验证码发送’‘忘记密码’3个小任务”，不用涉及具体的接口、表结构。
然后SM会组织迭代计划会，研发团队、PO、SM都参加。确认这一轮迭代的目标，比如“完成3个核心需求，交付可运行的版本”，还有每个人的工作任务。
比如“A负责登录接口，B负责前端页面，C负责测试”。这个时候，研发团队会提前沟通好系统设计的核心思路，比如“登录接口用POST请求，对接MySQL数据库”，在会议上确认一下，没有问题就开工。
迭代开始后，研发人员才会慢慢做详细设计。比如写接口文档、设计表结构，然后开始编码。编码的同时，测试人员也会同步准备测试用例，不用等编码完全完成再动手。
Scrum日常流程：每天10分钟站会，高效不啰嗦
编码完成后，研发人员自己先测一测，自验证。没问题就交给测试人员做验收测试。
迭代期间，每天都会开一个“每日站会”，时间很短，一般10-15分钟，大家都站着说。目的就是不让你说废话，每个人只说三句话：“昨天做了啥”“今天要做啥”“遇到 了啥问题”。
比如你说“我昨天写完了登录接口，今天要对接前端，遇到的问题是第三方接口调不通”，SM就会协调人帮你解决，确保大家进度一致，没有隐藏问题。
迭代时间一到，不管需求有没有做完，都会停下来开迭代评审会。展示这一轮的成果。
比如“我们完成了登录、注册两个功能，大家可以看看”，收集PO、测试人员的意见。比如“登录界面太丑，要改一改”。然后再开“迭代回顾会”，总结这一轮的问题。比如“需求拆分太粗，导致后期返工”“每日站会开得太久，浪费时间”，商量下一轮怎么改进。
避坑提醒：别把Scrum搞成“中华田园敏捷”
这里要给新手提个醒，Scrum看起来很灵活、很高效，但对团队的要求很高。全靠PO和SM把控节奏，这两个角色必须有足够的经验和能力。
团队成员也要有很强的自律性，比如分配的任务要按时完成，遇到问题要及时说，不能藏着掖着。如果是大型团队，还会引入QA全程监控，确保流程不跑偏。
尤其是在国内，很多团队用Scrum，最后都变成了中华田园敏捷。这是咱们行业内的自嘲，说白了就是“伪敏捷”，只学了Scrum的“形”，丢了它的“神”。
比如，老板拍板说“这个需求必须下周上线”，不管团队能不能完成，强制加班；每天开站会，开成了“汇报会”，每个人滔滔不绝说半天，浪费时间；只模仿“迭代”“站会”这些 形式，却不注重质量。
比如不做设计、不写测试用例，只求快，上线后一堆bug，然后甩锅给研发“你们代码写得差”。
这种中华田园敏捷，本质就是披着敏捷的外衣，干着赶工、甩锅、失控的活儿。
管理粗放，外行指挥内行，最后受伤的还是咱们研发人员，天天加班改bug，却看不到成果。
所以新手找工作的时候，也可以留意一下。如果公司说我们用敏捷开发，但连迭代计划会、迭代回顾会都不开，只知道让你加班赶进度，那大概率就是中华田园敏捷，慎重选择。
国内很多真正用敏捷的团队，为了避免这种失控的情况，SM都会由实职人员来担任。比如部门领导担任部门级SM，团队经理担任团队SM。毕竟他们有话语权，能协调资源、把控节奏，才能避免流程失控。
新手总结：开发模型是工具，别死记硬背，灵活用就好
说到最后，只给大家介绍了两个经典的模型，其他模型还需要大家自己去进一步的学习、运用。
给新手们一个核心总结，也是咱们这篇文章的重点。开发模型（或框架）不是“纸上谈兵”，而是用来解决实际问题的工具。你不用死记硬背每个步骤的定义，也不用纠结“哪个模型更好”，关键是结合自己的工作场景，灵活运用。
比如你在小团队，需求变化少，那就用V模型的思路，先 搞懂需求、做好设计，再编码测试，稳扎稳打；如果你在互联网公司，需求天天变，那就跟着Scrum的节奏，迭代交付、快速调整。
另外，新手不用急于求成，刚开始可能还是会分不清步骤、用不好模型，没关系。多结合自己的工作，比如你今天写了一段代码，就回头想想，这段代码对应的是哪个阶段（编码阶段）？前期有没有做详细设计？后期有没有做测试？慢慢对应、慢慢总结，你就会发现，这些方法论其实就在你身边，能帮你少走很多弯路、提高工作效率。
后续文章，我们还会在学习系统架构的基础，不断通过拾遗的形式，继续用大白话拆解大家没搞懂的东西，帮大家彻底吃透架构相关的方法论，再也不被专业术语搞懵。大家如果有更多的问题，欢迎后台留言。
在此也奉上我们最美好的祝愿：
🧨🏮🧧🍊 愿新的一年，0 Error 0 Warning，更要 0 病痛 0 疲惫。祝各位同行键盘敲得响亮，腰颈挺得笔直，发量与体能同在，代码和健康双全。🧨🏮🧧🍊