10x程序员工作法
郑晔
火币网首席架构师,前ThoughtWorks首席咨询师 ,TGO鲲鹏会会员
立即订阅
7975 人已学习
课程目录
已完结 56 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 程序员解决的问题,大多不是程序问题
免费
思考框架 (1讲)
01 | 10x程序员是如何思考的?
以终为始 (11讲)
02 | 以终为始:如何让你的努力不白费?
03 | DoD的价值:你完成了工作,为什么他们还不满意?
04 | 接到需求任务,你要先做哪件事?
05 | 持续集成:集成本身就是写代码的一个环节
06 | 精益创业:产品经理不靠谱,你该怎么办?
07 | 解决了很多技术问题,为什么你依然在“坑”里?
08 | 为什么说做事之前要先进行推演?
09 | 你的工作可以用数字衡量吗?
10 | 迭代0: 启动开发之前,你应该准备什么?
答疑解惑 | 如何管理你的上级?
划重点 | 关于“以终为始”,你要记住的9句话
任务分解 (11讲)
11 | 向埃隆·马斯克学习任务分解
12 | 测试也是程序员的事吗?
13 | 先写测试,就是测试驱动开发吗?
14 | 大师级程序员的工作秘笈
15 | 一起练习:手把手带你分解任务
16 | 为什么你的测试不够好?
17 | 程序员也可以“砍”需求吗?
18 | 需求管理:太多人给你安排任务,怎么办?
19 | 如何用最小的代价做产品?
答疑解惑 | 如何分解一个你不了解的技术任务?
划重点 | 关于“任务分解”,你要重点掌握哪些事?
沟通反馈 (12讲)
20 | 为什么世界和你的理解不一样
21 | 你的代码为谁而写?
22 | 轻量级沟通:你总是在开会吗?
23 | 可视化:一种更为直观的沟通方式
24 | 快速反馈:为什么你们公司总是做不好持续集成?
25 | 开发中的问题一再出现,应该怎么办?
26 | 作为程序员,你也应该聆听用户声音
用户故事 | 站在前人的肩膀上,领取属于你的高效工作秘籍
27 | 尽早暴露问题: 为什么被指责的总是你?
28 | 结构化:写文档也是一种学习方式
答疑解惑 | 持续集成,一条贯穿诸多实践的主线
划重点 | 一次关于“沟通反馈”主题内容的复盘
自动化 (12讲)
加餐 | 你真的了解重构吗?
29 | “懒惰”应该是所有程序员的骄傲
30 | 一个好的项目自动化应该是什么样子的?
31 | 程序员怎么学习运维知识?
32 | 持续交付:有持续集成就够了吗?
33 | 如何做好验收测试?
34 | 你的代码是怎么变混乱的?
35 | 总是在说MVC分层架构,但你真的理解分层吗?
36 | 为什么总有人觉得5万块钱可以做一个淘宝?
37 | 先做好DDD再谈微服务吧,那只是一种部署形式
答疑解惑 | 持续集成、持续交付,然后呢?
划重点 | “自动化”主题的重点内容回顾汇总
综合运用 (7讲)
38 | 新入职一家公司,怎么快速进入工作状态?
39 | 面对遗留系统,你应该这样做
40 | 我们应该如何保持竞争力?
答疑解惑 | 如何在实际工作中推行新观念?
划重点 | “综合运用”主题内容的全盘回顾
总复习 | 重新审视“最佳实践”
总复习 | 重新来“看书”
结束语 (1讲)
结束语 | 少做事,才能更有效地工作
10x程序员工作法
登录|注册

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

郑晔 2019-02-01
前面在讨论 TDD 的时候,我们说任务分解是 TDD 的关键。但这种认识依然是一种感性上的认识。今天,我们就来用一个更加具体的例子,让你看看任务分解到底可以做到什么程度。
这个例子就是最简单的用户登录。需求很简单,用户通过用户名密码登录。
我相信,实现这个功能对大家来说并不困难,估计在我给出这个题目的时候,很多人脑子里已经开始写代码了。今天主要就是为了带着大家体验一下任务分解的过程,看看怎样将一个待实现的需求一步步拆细,变成一个个具体可执行的任务。
要完成这个需求,最基本的任务是用户通过输入用户名和密码登录。
用户名和密码登录这个任务很简单,但我们在第一部分讲过沙盘推演,只要推演一下便不难发现,这不是一个完整的需求。
用户名和密码是哪来的呢?它们可能是用户设置的,也可能是由系统管理员设置的。这里我们就把它们简单设定成由用户设定。另外,有用户登录,一般情况下,还会有一个退出的功能。好了,这才是一个简单而完整的需求。我们就不做进一步的需求扩展。
所以,我们要完成的需求列表是下面这样的。
假设我们就是拿到这个需求列表的程序员,要进行开发。我们先要分析一下要做的事情有哪些,也就是任务分解。到这里,你可以先暂停一会,尝试自己分解任务,之后,再来对比我后面给出分解的结果,看看差异有多少。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(31)

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

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

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

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

    2019-02-01
    7
  • 你的笑犹如初夏的阳光
    没有把事情想透,就直接进去开发。发现自己会踩很多坑。而且在开发的过程中会遇到各种各样的麻烦。
    2019-02-01
    1
    7
  • 北天魔狼
    今天第二遍读这篇文章,实践过三次以上。感觉并没有因为做了分解而时间紧,事实上开发、调试更加顺畅,测试更加自信。也跟同事做了分享,我很激动,但是他们不激动

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

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

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

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

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

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

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

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

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

    2019-04-27
    1
  • 赫伯伯
    这就是程序员和工程师的区别
    2019-03-27
    1
  • shniu
    想请问一下老师面对探索型的需求,调研型的需求如何做任务分解呢。大部分情况下,都会面临要做一些探索型的工作,一些新的架构,新的业务尝试,新的技术尝试,要面对很多自己并没有接触过的知识。举个实际的例子,最近在研究一些健值存储数据库,读了一些paper,一些设计实现,这可能都是要做的一些任务清单中的一些项,但是我想去实现一个kv存储的时候就会感觉有些无从下手,实际落地到代码层面和读paper读博客还是有很大差别的,落地代码更关注细节,关注写的每一行代码,在这方面老师能否给些建议

    作者回复: 答疑见!

    2019-02-02
    1
  • John
    请教,UserService 和 UserResource 的职能划分?我做的项目只有 Repository 和 Service 两层,故有此疑问。谢谢!

    作者回复: 这里的Resource相当于一些项目的Controller,因为这里用的是Rest,对应资源的概念,所以,用了Resource。

    2019-02-01
    1
  • 7侠
    自己分解的任务和郑大的主要差别:1、没写Respository层的任务,感觉就是基本的新增、查询、更新方法,而这些框架都能自动生成 2、Service层区分了接口和实现类的任务 3、Resource/Controller层多了API数据格式定义的任务(目前是写在postman里,为了前后端分离开发)。
        按需求拆分任务、每个任务完成后都可提交这两点感觉是拆分任务的指导原则,还应注意任务间的依赖关系及先后顺序,特别是新任务加进来后,这个感觉和project排任务都有些类似了:)
    2019-12-12
  • 丁丁历险记
    笔记
    1 分解到单步可写
    2 按需求路径调代码。

    练习(部分叫法不一样,生产中会直接在github 上先找一个,以下仅为个人练手yy)
    开始前需求梳理。
    做啥
    注册 (真实手机号,短信验证)
    登录 (单点 先later)
    退出
    (找回,扫码登录 绑定,受限篇幅,略)
    1 建user model ,使用model save 方法。(usermodel 和user rp先融在一起,后期再拆)
    1.1 umodel save 方法时支持validate(),支持rules 配置。 (第一个轮子,一定要有)
    2  service  提供获取验证码接口
    2.1  service  公用函数编写。response  (code ,msg ,data = [])
    2.2  验手机号,验证后 ,发现是第二次验手机号了,马上重构,正则抽取至公公配置项 ,1.1 同时重构验证(dry 原则是灵魂)
    2.3  实现发送验证码(调接口),和session  存验证码。
    2.3.1  调接口,走通后转mock   dev  模式下,vcode 直接响应出来
    2.3.2  存验证码有效期测试,引入redis   用好setex
    2.3.3  重构, 请求验频,超频后上策略,先直接拒绝(后端不可能相信前端,这是原则)
    3 service  实现注册
    3.1  验证码
    3.2 调用1 保存数据。
    3.2.2   usermodel里面提供的rules  使用.  第一组测试用例来了
    4 实现登陆4.1 实现userModel -> auth( $username , $password) 接口。
    4.2 生成 token ,并设置token 有效时长。 (这里用redis 实现) 所以会顺带ttl看一下
    4.3 有条件下,开始实现单点登录。
    (可以先实现个简单的,服务端登录时,存token 内容时,把机器码mcode(标识)也编进去,并在redis 一个 (username: mcode) ),新的登录成功后,更新 (username: mcode)
    继续重构,redis 是基于内存型的,容易各种小毛病,换zookeeper . (当然,初期mvp 时,这里直接挂起,后期处理)
    5 退出
    6 在实现1 之前,向前端提供mock接口,别人前端傻等。
    备注: 以上内容仅为yy ,真实项目,会有很大的差别。如作者所说,很多细节,早就在dp 时潜移默化了,没必要罗里吧嗦的全写出来。【凡事都有开销,包括磨刀】
    但是在一些决策点上,会不断沟通。(例如,验频策略,是否单点登录,密码强度究竟是如何) 别让产品说了算,特别是公司有不靠谱的产品的时候。 你再怎么大神,也不可能写得比人家拍脑袋还快的。
    2019-11-08
  • 行者
    以前做敏捷开发拆分任务功能点,基本上是按照可观测的方式拆分的,没有根据从研发的角度独立去拆分这么细致,不做在做一个功能的时候会把步骤写好,然后在动手。
    2019-08-23
  • 马男
    忙的时候有借口,但是没有日常的总结,不忙的时候你知道要做什么吗?
    2019-07-22
  • 二康
    文章非常好,这种任务分解方法和思路能够在开发前就能把需要做的内容梳理清楚,避免最后一公里多的问题。
    2019-06-12
  • qingsong
    豁然开朗,把确定下来的项目需求,把需求颗粒化分解,也就是14节讲到的每一个小的任务都可以提交代码,这样的话,整体思路比较清晰明了,同事可以方便的看出自己完成了那些功能需求,还有那些没有完成。这是一个循序渐进的过程。
    2019-06-02
  • butterfly
    老师,我想问下 任务分解的粒度问题. 我工作中会分解到接口的下一层, 从MVC+db的方式进行分解. 比如,要实现注册接口,需要
    1. 注册页面;2.model层(数据校验+逻辑处理),3.数据库表设计.
    如果细分到函数和类这一次是不是太细了?

    作者回复: 参考第14讲,再理解一下微操作。

    2019-05-22
  • kyo
    我把任务分解的颗粒度按是否能给出明确的实现时间判断. 这更有利于预估实现整个需求所需要的时间.
    2019-05-09
  • 了@事@牵
    最终的目的是拆分出最小可执行单元
    2019-05-03
收起评论
31
返回
顶部