极客时间已完结课程限时免费阅读

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

划重点 | 关于“任务分解”，你要重点掌握哪些事？-极客时间

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

2019-02-15 郑晔 来自北京
《10x程序员工作法》
课程介绍

讲述：郑晔

时长00:48大小769.28K

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

重点复习

在这个模块中，我们学习到了一些最佳实践：
测试金字塔
-- 行业中测试组合的最佳实践。
-- 多写单元测试是关键。
测试驱动开发
-- 测试驱动开发的节奏是：红——绿——重构，重构是测试驱动开发区别于测试先行的关键。
-- 有人把测试驱动开发理解成测试驱动设计，它给行业带来的思维改变是，编写可测的代码。
艾森豪威尔矩阵（Eisenhower Matrix）
-- 将事情按照重要和紧急进行划分。
-- 重要且紧急的事情要立即做。重要但不紧急的事情应该是我们重点投入精力的地方。紧急但不重要的事情，可以委托别人做。不重要不紧急的事情，尽量少做。
最小可行产品
-- “刚刚好”满足客户需求的产品。
-- 在实践中，要用最小的代价找到一条可行的路径。
另外，我还提到了一些可以直接在工作中应用的做法和评判标准：
尽量不写 static 方法；
主分支开发模型是一种更好的开发分支模型；
好的用户故事应该符合 INVEST 原则；
估算是一个加深对需求理解的过程，好的估算是以任务分解为基础的；
好的测试应该符合 A-TRIP。
我也带你学习了一些重要的思想，帮你更好地改善自己的开发工作：
分而治之，是人类解决问题的基本手段；
软件变更成本，它会随着时间和开发阶段逐步增加；
测试框架把自动化测试作为一种最佳实践引入到开发过程中，使得测试动作可以通过标准化的手段固定下来；
极限编程之所以叫“极限”，它背后的理念就是把好的实践推向极限；
大师级程序员的工作秘笈是任务分解，分解到可以进行的微操作；
按照完整实现一个需求的顺序安排开发任务。

实战指南

在“任务分解”的板块，我也将每篇内容浓缩为“一句话”的实战指南，现在一起回顾一下。
动手做一个工作之前，请先对它进行任务分解。
—— 《11 | 向埃隆·马斯克学习任务分解》
多写单元测试。
——《12 | 测试也是程序员的事吗？》
我们应该编写可测的代码。
——《13 | 先写测试，就是测试驱动开发吗？》
将任务拆小，越小越好。
——《14 | 大师级程序员的工作秘笈》
按照完整实现一个需求的顺序去安排分解出来的任务。
——《15 | 一起练习：手把手带你拆任务》
要想写好测试，就要写简单的测试。
——《16 | 为什么你的测试不够好？》
想要管理好需求，先把需求拆小。
——《17 | 程序员也可以“砍”需求吗？》
尽量做最重要的事。
——《18 | 需求管理：太多人给你安排任务，怎么办？》
做好产品开发，最可行的方式是采用 MVP。
——《19 | 如何用最小的代价做产品？》

额外收获

在这个部分的最后，针对大家在学习过程中的热门问题，我也进行了回答，希望你懂得：
对不了解技术的任务，先要去了解技术，然后再做任务分解；
通过一次技术 Spike ，学习新技术；
丢弃掉在 Spike 过程中开发的原型代码；
分清目标与现状，用目标作为方向，指导现状的改变；
多个功能并行开发可以考虑使用 Feature Toggle；
在遗留系统上做改造可以考虑使用 Branch by Abstraction 。
——《答疑解惑 | 如何分解一个你不了解的技术任务？》

留言精选

在“任务分解”的模块中，有很多同学非常用心，将自己的学习心得和工作中的经验进行了分享，在此我挑选了一些同学的留言，与你一起学习。
在讲大师级程序员的工作秘笈时，西西弗与卡夫卡 同学提到：
最近在做战略拆解，都是一样的道理。战略飘在空中遥不可及，要落地就必须拆解。比如说达成目标有哪几个方面可以努力，各方面都需要做哪些事，这是路径。这些路径里哪些优先级最高，需要配置哪些组织资源。心里有数之后就是制订计划时间表。
另外，西西弗与卡夫卡 同学还为 Spike 给出了一个很生动的解释：
“技术 Spike”可以翻译成“技术撩”，就是撩妹的那个撩。试探下，有戏就继续，撩不动就算或者放一段时间再说。
针对分解的粒度问题，大彬 同学也分享了自己的心得：
我会的任务分解，不仅可执行，粒度还很细。比如说，我要修复一个 rpc 接口的 bug。我会列出每个代码的修改点，要修改的测试，要增加的测试，合并到哪个分支，修改 rpc 文档，文档中有哪些点要修改。
每一步都非常容易执行，看起来没多少必要，但在我当前的工作环境特别有用：（1）事前思考，不会造成遗漏；（2）任务实施过程中经常被打断，比如，测试有疑问和你讨论、主管找你谈事、紧急会议来了，这种“硬中断”完全打破了节奏，而任务列表，让我清楚知道当前做了多少，该从哪一步继续。
对于单元测试，树根 同学提到：
我的想法可以在复杂度高，重要核心的模块先开始写单元测试。特别是公用、底层的，因为这些靠功能测试很难覆盖。
单元测试难以推行主要是没有碰到质量的痛点，通常都依靠测试工程师来保证质量。我们之前就遇到过质量崩塌，倒逼着我们去做，以保证质量。
树根 同学还分享了自己的任务分解实践心得：
刚改了编程习惯，先在 notion 写出思路、需要用到的知识点，api 等，写出各个小任务，然后对应写出关键代码段。最后真正敲代码就花了 10 来分钟。
重新开始看极客时间就看到这篇，实践过来读，很认同。
我特别佩服国外的工程师写的代码，代码块很小，非常清晰易读。特别记得之前参加 infoq 会议，听 socketio 作者的分享，看他现场撸码，思路、代码结构都非常顺畅和清晰。
关于 TDD 的具体应用， 萧 同学提到了遇到的问题：
不久前第一次接触 TDD 时为它的思想而惊叹，感觉它能极大的提升编码效率，编码后期的大量重构，还能保障代码质量。后面自己在写代码的时候也注意使用它的思想，但说实话，理解是一回事，用起来就不是那么回事了，很多的东西还不是太熟练，前期说实话比较耗时间，有些拖进度。
由于也毕业不久，经验上有些欠缺，还不太熟练，有些测试还不知道怎么写。现在写多了一点，感受到的是代码质量上的提高，bug 比起以前少了，需求变更下改动，也不伤筋动骨了，但还是有许多感觉做的不够好的地方。看了这篇文章，补充了对 TDD 的认知，感受到如果和任务分解结合起来，TDD 会有更好的效果，期待后面的文章！
关于“任务分解”的执行问题，如明如月 同学分享了感悟：
对任务分解的体会非常深刻，刚入职的时候任务评估不准。现在想想主要是两个原因：（1）需求梳理的不清晰，还没清楚地搞明白需求就动手写代码，导致返工和一些“意想不到”的情况。（2）任务分解做的不好，没有将任务分解成非常清晰地可执行的单元，导致有些时候无从下手，而且任务时间评估不准确。
在讲到为什么很多人的测试不够好这个问题时， 毅 同学提到：
本节课我有以下几点体会：
（1）从开发者的视角看，编码和测试是不分家的，是可以通过重构形成良性生态圈的，类似之前课程中的反馈模型和红绿重构模型；
（2）A-TRIP 是个很好的总结和行动指南，在今后工作中应一以贯之，把工作做到扎实有成效；
（3）对文中提到的数据库依赖的问题，我也说说自己的浅见。我觉得在测试代码中，尽量避免与数据库打交道，测试更关注领域与业务，往往爆雷更多的是 resource 和 service，模型的变化往往牵动着表结构的变化，与其两头兼顾不如多聚焦模型。
我常用的做法是用例配合若干小文件 (数据忠实于模型)，保证库操作临门一脚前所有环节都是正确的，同时方便适应变化。一旦出现异常，也比较容易定位是否是数据库操作引发的问题。 (此点基于，我在工作中发现，项目型程序员大多是先急于把表结构定义出来，好像不这么做，写代码就不踏实)
针对需求的管理问题，WL 同学提到的点也非常关键：
程序员也应该更积极主动一些, 最好能推动事情发展, 当这件事情由你推动时，主动权就在你的手里了。
感谢同学们的精彩留言。在下一个模块中，我将为大家分享“沟通反馈”这个原则的具体应用。
感谢阅读，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给你的朋友。
分享给需要的人，Ta购买本课程，你将得20元
生成海报并分享

赞 22

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
答疑解惑 | 如何分解一个你不了解的技术任务？
下一篇
20 | 为什么世界和你的理解不一样？
unpreview
 写留言

精选留言(6)

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

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

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

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

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

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

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

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

    共 2 条评论
    1
  • ifelse
    2022-04-18
    酷，任务分解我正在练习中
  • Demon.Lee
    2020-06-18
    尽量不写 static 方法 ---老师，我们现在用的spring boot，经常对一些模型进行转换（比如VO转成Entity或反过来转换），用的就是静态方法，您有更好的建议么

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

    共 3 条评论