10x 程序员工作法
郑晔
火币网首席架构师,前 ThoughtWorks 首席咨询师 ,TGO 鲲鹏会会员
52556 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 61 讲
思考框架 (1讲)
10x 程序员工作法
15
15
1.0x
00:00/00:00
登录|注册

15 | 一起练习:手把手带你分解任务

你好,我是郑晔。
前面在讨论 TDD 的时候,我们说任务分解是 TDD 的关键。但这依然是一种感性上的认识。今天,我们就来用一个更加具体的例子,让你看看任务分解到底可以做到什么程度。
这个例子就是最简单的用户登录。需求很简单,用户通过用户名密码登录。
我相信,实现这个功能对大家来说并不困难,估计在我给出这个题目的时候,很多人脑子里已经开始写代码了。今天主要就是为了带着大家体验一下任务分解的过程,看看怎样将一个待实现的需求一步步拆细,变成一个个具体可执行的任务。
要完成这个需求,最基本的任务是用户通过输入用户名和密码登录。
用户名和密码登录这个任务很简单,但我们在第一部分讲过沙盘推演,只要推演一下便不难发现,这不是一个完整的需求。
用户名和密码是哪来的呢?它们可能是用户设置的,也可能是由系统管理员设置的。这里我们就把它们简单设定成由用户设定。另外,有用户登录,一般情况下,还会有一个退出的功能。好了,这才是一个简单而完整的需求。我们就不做进一步的需求扩展。
所以,我们要完成的需求列表是下面这样的。
假设我们就是拿到这个需求列表的程序员,要进行开发。我们先要分析一下要做的事情有哪些,也就是任务分解。到这里,你可以先暂停一会,尝试自己分解任务,之后,再来对比我后面给出的分解结果,看看差异有多少。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《10x 程序员工作法》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(58)

  • 最新
  • 精选
  • desmond
    这篇文章就值这套课程的价钱,赚了!

    作者回复: 把文章转发给给朋友同事,赚更多!

    70
  • 北天魔狼
    今天第二遍读这篇文章,实践过三次以上。感觉并没有因为做了分解而时间紧,事实上开发、调试更加顺畅,测试更加自信。也跟同事做了分享,我很激动,但是他们不激动

    作者回复: 靠讲道理,只能说明白想提高的人,我开专栏也是为了那些想提高的人服务。

    48
  • 行与修
    老师的一条回复我觉得很有启发啊:“不忙的时候你知道该怎么做吗?” 首先是意识问题,其次就是执行了。我自己的经历来看,之前在项目型软件公司,粗放式的工作惯了,后来经历了一家产品型公司的洗礼,刚开始格格不入,后来逐渐习惯了,现在想快也快不起来了。我经常跟我团队兄弟们说,想透了再动手,客户公司那些事我来搞定,我只要扎实的可交付的成果就行,拒绝返工!

    作者回复: 忙,是做事不动脑的借口。

    6
    32
  • 红糖白糖
    分解的粒度跟个人的熟悉程度有关。比如一个登陆注册你写了很多次,很熟悉,拿来就知道有哪些事情需要做。就可以粒度偏粗,如果是一个全新的需求/复杂的需求,此时就应该偏细

    作者回复: 这个说法是对的,越是不熟悉的东西,越应该在前面下功夫。

    21
  • 划时代
    看了一些同学的评论,有感而发想表达一下自己的观点,并非是口诛笔伐。之前也听过一些如何做好软件开发的大牛讲座;有一部分听众反馈,项目周期很紧催促上线,哪有机会按照标准流程开发,保证高质量文档,保证高质量代码?这确实是客观的事实,是极端情况,然而很多时候仅仅是挂在嘴边的借口用来搪塞的,却忘了工程师本身的职责。我不太相信,一位工程师在一年的工作中,每一个项目,每一天的工作,都如十万火急一般,无法保证项目的质量。一年中有忙的时候,也有不忙的时候;一年中有急于上线的项目,也有井然有序的项目,往往不忙的时候多过忙的时候吧。在上升期很快的创业公司工作,也大概是这样子的。所以很多时候是考验个人执行力的问题,不断地实践和总结,掌握熟练之后得心应手。

    作者回复: 其实只要回答一个问题,当你不忙时,你知道该怎么做吗?

    20
  • Dawn
    建议:千万别上来就给表取名users。https://codewithoutrules.com/2018/09/21/users-considered-harmful/?utm_source=wanqu.co&utm_campaign=Wanqu+Daily&utm_medium=website

    作者回复: 这个观点我同意,这里是为了叙述方便。在沟通反馈部分,我会讲到写代码时,要区分概念。

    2
    15
  • CalanceHao
    😂我上来先考虑了一堆有的没的:密码的规则啦,加密储存啦(直觉MD5之类的,一搜索这些方案也早就过时了),注册步骤,手机邮箱校验,…… 然后一对答案…… Hmm…… 我都在想啥

    作者回复: 02的段子在你这出现了。

    10
  • sam
    这几天学习着老师的任务分解课程,工作中有一个功能需求交给一个不熟悉项目的新同事负责开发,我尝试让他先按照需求理解把开发任务拆分的细致一点,这样项目的老人可以在任务分解上把把关,避免出现大的偏差。 但结果是: 他说项目时间紧,要赶紧熟悉代码; 然后又说对代码不熟悉拆分不出来,需要花很多时间对项目熟悉了才能拆分; 最后的实际操作是,直接上手写代码了,边写边熟悉边梳理。至于事前的任务分解和思考,他承认那是很好的,但现实做不到。

    作者回复: 他思考的基础是代码,不是事情,他把二者混到了一起。你可以带着他做一次分解,让他知道,这是两件事。

    4
    9
  • 布衣骇客
    老师有个疑问,如果需要对即将要做的事情,没有经验,又不太了解的时候如何做任务分解呢,比如在限定的时间做一个之前没有接触的东西(我之前碰到过),麻烦解答,非常感谢

    作者回复: 赶紧补课,这个模块的答疑在不远处等着你。

    2
    8
  • 废材姑娘
    以前在thoughtworks时每次拿到一个story都会和pair一起把任务列出来,然后一个个做,现在换了公司,需求都是一坨坨的,刚开始不适应,久试着用任务拆解的方式一点点拆,有助于理解需求,也能更好的估算工作量,最重要的是能提前发现产品设计的漏洞,任务拆解真的是每个程序员必备的技能,应该是每个人必备的技能

    作者回复: 知道,进步一点,练习,再进步一点点,融会贯通,又进步一点点。

    2
    6
收起评论
显示
设置
留言
58
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部