目录
前言：
本篇博客内容来源自：极客时间课程《10x程序员工作法》处于学习记录。将个人认为比较重要的知识点进行摘抄记录。有兴趣的同学去极客时间学习完整课程。
一、为什么你的测试不够好？
为什么你的测试不够好呢？
主要是因为这些测试不够简单。只有将复杂的测试拆分成简单的测试，测试才有可能做好。
既然无法用写程序的方式保证测试的正确性，我们只有一个办法：把测试写简单，简单到一目了然，不需要证明它的正确性。
我把这段代码分成了四段，分别是前置准备、执行、断言和清理，这也是一般测试要具备的四段。
前置准备，就是准备执行部分所需的依赖。比如，一个类所依赖的组件，或是调用方法所需要的参数。在这个测试里面，我们准备了一个 HTTP 请求，设置了它的方法是一个 GET 方法，这里面还用到了之前提到的 Mock 框架，因为完整地设置一个 HTTP 请求很麻烦，而且与这个测试也没什么关系。
断言是我们的预期，就是这段代码执行出来怎么算是对的。这里我们判断了提取出来的方法是否是 GET 方法。另外补充一点，断言并不仅仅是 assert，如果你用 Mock 框架的话，用以校验 mock 对象行为的 verify 也是一种断言。
清理是一个可能会有的部分，如果你的测试用到任何资源，都可以在这里释放掉。不过，如果你利用好现有的测试基础设施（比如，JUnit 的 Rule），遵循好测试规范的话，很多情况下，这个部分就会省掉了。
常见的测试“坏味道”：做了太多事的测试，没有断言的测试，还有一种看一眼就知道有问题的“坏味道”，测试里有判断语句。
怎么衡量测试是否做好了呢？有一个标准：A-TRIP，这是五个单词的缩写，分别是 Automatic（自动化）、Thorough（全面）、Repeatable（可重复的）、Independent（独立的）和 Professional（专业的）。
一句话总结：
要想写好测试，就要写简单的测试
二、程序员也可以砍需求吗？
绝大多数问题都是由于分解的粒度太大造成的，少有因为粒度太小而出问题的。所以，需求分解的一个原则是，粒度越小越好。
评价用户故事有一个“ INVEST 原则”，这是六个单词的缩写，分别是：
Independent，独立的。一个用户故事应该完成一个独立的功能，尽可能不依赖于其它用户故事，因为彼此依赖的用户故事会让管理优先级、预估工作量都变得更加困难。如果真的有依赖，一种好的做法是，将依赖部分拆出来，重新调整。
Negotiable，可协商的。有事大家商量是一起工作的前提，我们无法保证所有的细节都能 100% 落实到用户故事里，这个时候最好的办法是大家商量。它也是满足其它评判标准的前提，就像前面提到的，一个用户故事不独立，需要分解，这也需要大家一起商量的。
Valuable，有价值的。一个用户故事都应该有其自身价值，这一项应该最容易理解，没有价值的事不做。但正如我们一直在说的那样，做任何一个事情之前，先问问价值所在。
Estimatable，可估算的。我们会利用用户故事估算的结果安排后续的工作计划。不能估算的用户故事，要么是因为有很多不确定的因素，要么是因为需求还是太大，这样的故事还没有到一个能开发的状态，还需要产品经理进一步分析。
Small，小。步子大了，不行。不能在一定时间内完成的用户故事只应该有一个结果，拆分。小的用户故事才方便调度，才好安排工作。
Testable，可测试的。不能测试谁知道你做得对不对。这个是我们在前面已经强调过的内容，也就是验收标准，你得知道怎样才算是工作完成。
“INVEST 原则”的说法是为了方便记忆。
一句话总结：
想要管理好需求，先把需求拆小。
三、需求管理：太多人给你安排任务，怎么办？
《高效能人士的七个习惯》
它将事情按照重要和紧急两个维度进行划分，也就形成了四个部分：
重要且紧急，重要不紧急，不重要且紧急，不重要不紧急。
用几个程序员生活中的例子帮你理解一下。
让系统不能正常运行的线上故障，就属于重要且紧急事情，不赶紧解决，就影响公司的正常运营。
团队对系统升级改造就属于重要不紧急：改造好，性能也好，可维护性也得到提升；不改造，一时半会也能用。
一些临时任务都属于紧急不重要，
而刷朋友圈则属于既不紧急也不重要。
按照时间管理的理念，重要且紧急的事情要立即做。重要但不紧急的事情应该是我们重点投入精力的地方。紧急但不重要的事情，可以委托别人做。不重要不紧急的事情，尽量少做。
这个矩阵带给我们思维上最大的改变是，让人意识到事情和事情不是等价的。如果不把精力放在重要的事情上，到最后可能都变成紧急的事情。
需求分解之后，最重要的是，排列需求的优先级。优先级的排列方式有很多，我们可以借鉴时间管理的方法，把事情按照重要和紧急的维度进行划分，得到了四个象限。我们要尽可能把精力放在重要的事情上，而不是把紧急的事情当成优先级排序的方式。
需求分解成一个个小块，其实也分解了原本合一的上下文。如果想要有效地管理需求，尤其是确定事情的重要程度，一种方式是找回丢失的上下文。如果我们自己无法判断上下文，一种好的办法是，引入外部更大的上下文。
一句话总结：
尽量做最重要的事情。
四、如何用最小的代价做产品？
产品经理的想法层出不穷，但是，如果我们一味闷着头实现产品经理的想法，无论你有多大的开发团队都是不够用的。我们要学会用最小的代价做产品。
精益创业就是通过不断地尝试在真实世界中验证产品想法，其中一个重要的实践是最小可行产品（Minimum Viable Product，MVP），我们这次就把这个实践展开讨论一下。
首先，我们必须清楚一件事，我们要做的是验证一个想法的可行性，甚至不是为了开发一个软件，开发软件只是一种验证手段。
主要是想破除大家对于一个“完整”系统概念的认识。当时间有限时，我们需要学会找到一条可行的路径，在完整用户体验和完整系统之间，找到一个平衡。
站在开发团队的角度，我们怎样把 MVP 理念运用在自己的工作中呢？当产品经理有一大堆要实现的功能时，我们就可以根据 MVP 理念，从这些产品功能中找出一条最小的可行路径，重新安排一个合理的开发计划。
想要在实践中运用好最小可行产品的理念，就是要用最小的代价找到一条可行的路径。最小的代价就是能不做的事就不做，能简化的事情就简化。
程序员通常愿意用自己的代码解决问题，而写代码通常是代价非常高的解决方案，它应该成为最后的产品解决方案。
可行的路径，是一条完整的用户体验路径，至少在用户眼中是这样的。我们常常会想给客户一个完整的系统，但在时间有限的情况下，我们必须学会分解。
一句话总结：
做好产品开发，最可行的方式就是采用MVP
问题答疑与设计
问题1：面对不了解的技术，我该如何分解任务？
如果不了解这项技术呢？答案很简单，先把它变成你熟悉的技术。一旦变成了你熟悉的技术，你就可以应用在这个模块中学到的，面对确定性技术的分解方案。
这里强调的重点在于，要做一次技术 Spike。Spike 的作用就在于消除不确定性，让项目经理知道这里要用到一项全团队没有人懂的技术，需要花时间弄清楚。
我们要确定两件事：这项技术在项目中应用场景和我们的关注点。
问题2、项目时间紧，我该怎么办？
这是一个非常典型的问题，我在之前做咨询的时候，经常会遇到很多团队说，项目时间紧，所以，他们没有时间做测试。
这里面有一个非常经典误区：混淆了目标与现状。目标是应该怎么做，现状是我们正在怎么做。我们都知道现状是什么样的，问题是，你对现状满意吗？如果每个人都对现状是满意的，就不会有人探索更好的做法。假设现在不忙了，你知道该怎么改进吗？
总结：
测试金字塔
-- 行业中测试组合的最佳实践。
-- 多写单元测试是关键。
测试驱动开发
-- 测试驱动开发的节奏是：红——绿——重构，重构是测试驱动开发区别于测试先行的关键。
-- 有人把测试驱动开发理解成测试驱动设计，它给行业带来的思维改变是，编写可测的代码。
艾森豪威尔矩阵（Eisenhower Matrix）
-- 将事情按照重要和紧急进行划分。
-- 重要且紧急的事情要立即做。重要但不紧急的事情应该是我们重点投入精力的地方。紧急但不重要的事情，可以委托别人做。不重要不紧急的事情，尽量少做。
最小可行产品
-- “刚刚好”满足客户需求的产品。
-- 在实践中，要用最小的代价找到一条可行的路径。
另外，我还提到了一些可以直接在工作中应用的做法和评判标准：
- 尽量不写 static 方法；
- 主分支开发模型是一种更好的开发分支模型；
- 好的用户故事应该符合 INVEST 原则；
- 估算是一个加深对需求理解的过程，好的估算是以任务分解为基础的；
- 好的测试应该符合 A-TRIP。
我也带你学习了一些重要的思想，帮你更好地改善自己的开发工作：
- 分而治之，是人类解决问题的基本手段；
- 软件变更成本，它会随着时间和开发阶段逐步增加；
- 测试框架把自动化测试作为一种最佳实践引入到开发过程中，使得测试动作可以通过标准化的手段固定下来；
- 极限编程之所以叫“极限”，它背后的理念就是把好的实践推向极限；
- 大师级程序员的工作秘笈是任务分解，分解到可以进行的微操作；
- 按照完整实现一个需求的顺序安排开发任务。
1478
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
