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
收起评论