10x 程序员工作法
郑晔
开源项目 Moco 作者
53432 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 63 讲
思考框架 (1讲)
10x 程序员工作法
15
15
1.0x
00:00/00:00
登录|注册

划重点 | 关于“任务分解”,你要重点掌握哪些事?

程序员推动事情发展
测试代码中避免与数据库打交道
任务分解的执行问题
TDD的应用问题
任务分解实践心得
单元测试的重要性
任务分解的粒度问题
生动解释技术 Spike
战略拆解与任务分解
在遗留系统上做改造可考虑使用 Branch by Abstraction
多功能并行开发可考虑使用 Feature Toggle
用目标指导现状的改变
丢弃 Spike 过程中的原型代码
通过技术 Spike 学习新技术
对不了解技术的任务,先了解技术再做任务分解
采用 MVP
尽量做最重要的事
管理需求,先把需求拆小
写简单的测试
安排分解出来的任务顺序
将任务拆小
编写可测的代码
多写单元测试
动手做任务前进行任务分解
安排开发任务顺序
大师级程序员的工作秘笈是任务分解
极限编程推向极限
测试框架引入自动化测试
软件变更成本
分而治之
好的测试符合 A-TRIP
估算以任务分解为基础
好的用户故事符合 INVEST 原则
主分支开发模型
不写 static 方法
最小可行产品
艾森豪威尔矩阵
测试驱动开发
测试金字塔
留言精选
额外收获
实战指南
重要思想
可直接应用的做法和评判标准
重点复习
任务分解

该思维导图由 AI 生成,仅供参考

你好,我是郑晔,恭喜你,又完成了一个模块的学习。
在这个模块中,我主要讲解的是“任务分解”这个知易行难的工作原则。普通人与高手之间的差异,很大程度上取决于任务分解的粒度大小。但真正理解并应用好“任务分解”的原则并不容易,希望你能勤于练习,将知识内化成为你的能力。

重点复习

在这个模块中,我们学习到了一些最佳实践:
测试金字塔
-- 行业中测试组合的最佳实践。
-- 多写单元测试是关键。
测试驱动开发
-- 测试驱动开发的节奏是:红——绿——重构,重构是测试驱动开发区别于测试先行的关键。
-- 有人把测试驱动开发理解成测试驱动设计,它给行业带来的思维改变是,编写可测的代码。
艾森豪威尔矩阵(Eisenhower Matrix)
-- 将事情按照重要和紧急进行划分。
-- 重要且紧急的事情要立即做。重要但不紧急的事情应该是我们重点投入精力的地方。紧急但不重要的事情,可以委托别人做。不重要不紧急的事情,尽量少做。
最小可行产品
-- “刚刚好”满足客户需求的产品。
-- 在实践中,要用最小的代价找到一条可行的路径。
另外,我还提到了一些可以直接在工作中应用的做法和评判标准:
尽量不写 static 方法;
主分支开发模型是一种更好的开发分支模型;
好的用户故事应该符合 INVEST 原则;
估算是一个加深对需求理解的过程,好的估算是以任务分解为基础的;
好的测试应该符合 A-TRIP。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

这篇文章深入探讨了“任务分解”这一工作原则的重要性和实际应用。作者强调了任务分解对于提高工作效率和质量的关键作用,并提供了一些最佳实践和实战指南,如测试金字塔、测试驱动开发、艾森豪威尔矩阵、最小可行产品等概念和方法。此外,文章还涉及了一些重要的思想,如分而治之、软件变更成本、测试框架等。读者可以从中获得丰富的知识内容和实用的工作指导,有助于提升工作效率和质量。同时,文章还包括了一些同学的留言,分享了他们在任务分解实践中的心得体会,为读者提供了额外的学习收获。整体而言,这篇文章为读者提供了深入的技术内容和实用的经验分享,对于工作中的任务分解和执行具有重要的指导意义。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《10x 程序员工作法》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(7)

  • 最新
  • 精选
  • 西西弗与卡夫卡
    任务分解,我觉得应该是四大原则(其余三个是以终为始、沟通反馈、自动化)里最关键一环。怎么分解,分解到什么程度,怎么根据当前情况选择合适路径,怎么确定轻重缓急,更进一步说,怎么在压力之下依然能稳住心神坚持自己的路径,都很吃功夫。是一门学到老的功夫

    作者回复: 工匠功夫,慢慢练

    2019-02-15
    14
  • lionel
    作为一个小公司的前端开发+赶鸭子上架的项目经理,花了两天追完了正文。感觉两个身份的收获都很大。 另外自己对这个专栏做了一些笔记和摘抄,以便记忆,请问是否可以分享到自己的小圈子。链接如下: https://www.yuque.com/lionel-6od7c/js/kwtfda

    作者回复: 很赞的总结!你可以自己决定怎么做。你也可以邀请朋友订阅专栏,加入到我们的学习中。

    2019-02-17
    13
  • Demon.Lee
    谢谢老师。前一条下面留言,您可能看不到,我这里再发一条新的。1. 您说的在对象上加一个方法做转换,是指在VO里面加一个方法转成Entity吗,那这样的话,这两个类不就耦合了么?2. 我们现在用的就是一个单独的类,里面写静态方法,把VO传进去,返回Enitity,或把Entity传进去,返回VO,不知道是不是您说的转换类?

    作者回复: 1. 只有 VO 依赖于 Entity,所以,转换方法都在 VO 里。Entity 不知道 VO。 2.单独的类没问题,不要写静态方法,写成普通的方法就好。

    2020-06-19
    2
    3
  • 丁丁历险记
    老师的梳理能力不错。 个人这个能力应该是大量实践带来的,很多时候深度理解了,记忆也就不多了,几个点一串,就自成一小体系了。不知猜对了没

    作者回复: 知识成体系很重要

    2019-11-12
    3
  • Demon.Lee
    尽量不写 static 方法 ---老师,我们现在用的spring boot,经常对一些模型进行转换(比如VO转成Entity或反过来转换),用的就是静态方法,您有更好的建议么

    作者回复: 一种做法是,在对象上加一个方法做转换,一种方法是,做转换类。

    2020-06-18
    3
  • 6点无痛早起学习的和尚
    其实看到这里突然想到了,很多时候我们给不了一个需求的排期,那是因为我们对这个需求不完全理解和不会任务分解。 如果对需求理解,并且再对需求进行任务分解。 1. 首先分出来模型 2. 再分功能点 3. 对模型和功能点再分 4. 分到你认为可以预估时间了,然后再把所有时间加起来=开发人力。 因为我平常有时候就不会估算开发人力,交给我的需求,我就是拍脑袋一想,最后有时候就把自己坑了
    2023-05-19归属地:北京
    2
  • ifelse
    酷,任务分解我正在练习中
    2022-04-18
收起评论
显示
设置
留言
7
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部