15 | 一起练习：手把手带你分解任务
郑晔
该思维导图由 AI 生成，仅供参考
你好，我是郑晔。
前面在讨论 TDD 的时候，我们说任务分解是 TDD 的关键。但这依然是一种感性上的认识。今天，我们就来用一个更加具体的例子，让你看看任务分解到底可以做到什么程度。
这个例子就是最简单的用户登录。需求很简单，用户通过用户名密码登录。
我相信，实现这个功能对大家来说并不困难，估计在我给出这个题目的时候，很多人脑子里已经开始写代码了。今天主要就是为了带着大家体验一下任务分解的过程，看看怎样将一个待实现的需求一步步拆细，变成一个个具体可执行的任务。
要完成这个需求，最基本的任务是用户通过输入用户名和密码登录。
用户名和密码登录这个任务很简单，但我们在第一部分讲过沙盘推演，只要推演一下便不难发现，这不是一个完整的需求。
用户名和密码是哪来的呢？它们可能是用户设置的，也可能是由系统管理员设置的。这里我们就把它们简单设定成由用户设定。另外，有用户登录，一般情况下，还会有一个退出的功能。好了，这才是一个简单而完整的需求。我们就不做进一步的需求扩展。
所以，我们要完成的需求列表是下面这样的。
假设我们就是拿到这个需求列表的程序员，要进行开发。我们先要分析一下要做的事情有哪些，也就是任务分解。到这里，你可以先暂停一会，尝试自己分解任务，之后，再来对比我后面给出的分解结果，看看差异有多少。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
手把手带你分解任务 在本文中，作者通过一个用户登录的简单需求，详细讲解了任务分解的过程和重要性。文章首先强调了任务分解对于TDD的关键性，随后以用户登录需求为例，逐步分解成具体可执行的任务。作者提出了按照需求的方式安排任务的观点，强调了任务分解的细致性和独立性。同时，还介绍了技术方案的选择和任务执行顺序的调整。最后，作者鼓励读者分享自己的任务清单，并强调了按照完整实现一个需求的顺序去安排分解出来的任务的重要性。通过本文，读者可以深入了解任务分解的重要性和实际操作方法，对于技术开发和项目管理具有一定的指导意义。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《10x 程序员工作法》，新⼈⾸单¥68
《10x 程序员工作法》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(59)
- 最新
- 精选
- desmond这篇文章就值这套课程的价钱，赚了！
作者回复: 把文章转发给给朋友同事，赚更多！
2019-02-0173 
北天魔狼今天第二遍读这篇文章，实践过三次以上。感觉并没有因为做了分解而时间紧，事实上开发、调试更加顺畅，测试更加自信。也跟同事做了分享，我很激动，但是他们不激动作者回复: 靠讲道理，只能说明白想提高的人，我开专栏也是为了那些想提高的人服务。
2019-04-0150
行与修老师的一条回复我觉得很有启发啊：“不忙的时候你知道该怎么做吗？” 首先是意识问题，其次就是执行了。我自己的经历来看，之前在项目型软件公司，粗放式的工作惯了，后来经历了一家产品型公司的洗礼，刚开始格格不入，后来逐渐习惯了，现在想快也快不起来了。我经常跟我团队兄弟们说，想透了再动手，客户公司那些事我来搞定，我只要扎实的可交付的成果就行，拒绝返工！作者回复: 忙，是做事不动脑的借口。
2019-02-01634
红糖白糖分解的粒度跟个人的熟悉程度有关。比如一个登陆注册你写了很多次，很熟悉，拿来就知道有哪些事情需要做。就可以粒度偏粗，如果是一个全新的需求/复杂的需求，此时就应该偏细作者回复: 这个说法是对的，越是不熟悉的东西，越应该在前面下功夫。
2019-03-1022- 划时代看了一些同学的评论，有感而发想表达一下自己的观点，并非是口诛笔伐。之前也听过一些如何做好软件开发的大牛讲座；有一部分听众反馈，项目周期很紧催促上线，哪有机会按照标准流程开发，保证高质量文档，保证高质量代码？这确实是客观的事实，是极端情况，然而很多时候仅仅是挂在嘴边的借口用来搪塞的，却忘了工程师本身的职责。我不太相信，一位工程师在一年的工作中，每一个项目，每一天的工作，都如十万火急一般，无法保证项目的质量。一年中有忙的时候，也有不忙的时候；一年中有急于上线的项目，也有井然有序的项目，往往不忙的时候多过忙的时候吧。在上升期很快的创业公司工作，也大概是这样子的。所以很多时候是考验个人执行力的问题，不断地实践和总结，掌握熟练之后得心应手。
作者回复: 其实只要回答一个问题，当你不忙时，你知道该怎么做吗？
2019-02-0121 
Dawn建议：千万别上来就给表取名users。https://codewithoutrules.com/2018/09/21/users-considered-harmful/?utm_source=wanqu.co&utm_campaign=Wanqu+Daily&utm_medium=website作者回复: 这个观点我同意，这里是为了叙述方便。在沟通反馈部分，我会讲到写代码时，要区分概念。
2019-02-17216
sam这几天学习着老师的任务分解课程，工作中有一个功能需求交给一个不熟悉项目的新同事负责开发，我尝试让他先按照需求理解把开发任务拆分的细致一点，这样项目的老人可以在任务分解上把把关，避免出现大的偏差。 但结果是： 他说项目时间紧，要赶紧熟悉代码; 然后又说对代码不熟悉拆分不出来，需要花很多时间对项目熟悉了才能拆分; 最后的实际操作是，直接上手写代码了，边写边熟悉边梳理。至于事前的任务分解和思考，他承认那是很好的，但现实做不到。作者回复: 他思考的基础是代码，不是事情，他把二者混到了一起。你可以带着他做一次分解，让他知道，这是两件事。
2020-07-10411
CalanceHao😂我上来先考虑了一堆有的没的：密码的规则啦，加密储存啦(直觉MD5之类的，一搜索这些方案也早就过时了)，注册步骤，手机邮箱校验，…… 然后一对答案…… Hmm…… 我都在想啥作者回复: 02的段子在你这出现了。
2019-04-27210
布衣骇客老师有个疑问，如果需要对即将要做的事情，没有经验，又不太了解的时候如何做任务分解呢，比如在限定的时间做一个之前没有接触的东西（我之前碰到过），麻烦解答，非常感谢作者回复: 赶紧补课，这个模块的答疑在不远处等着你。
2019-02-2129
Jxin
任务分解，想清楚再写。这些观点都认可。但公司实际工作，存在时间根本不够的情况。需求下来，确定上线日期，往前推几天提测，其他时间开发。 比较遗憾的事情是包括以终为始在内，大部分套路大家都懂，也认可哪怕时间不足也不能跳过这些步奏。然而真正面对时间不足，而且连续不足，而且势必的线上bug与需求冲突场景日益增多。真的就一边不认可一边就这么做了。对于稳定的系统，需求真的很难砍。而在人员调动频繁的团队中去接手稳定的系统，真的，每个需求的实际工作量double几倍都不是不可能的。作者回复: 我在答疑中说了，我们得有目标，然后结合自己的工作实际，找到一条适合自己的改进路径，别想一步到位的完全改善。
2019-02-017
收起评论
