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