10x程序员是如何思考的？| 1

【1】
思考框架：现状 - 目标 - 实现路径
四项原则：以终为始 - 任务分解 - 沟通反馈 - 自动化
减少偶然复杂度造成的消耗，将注意力放到本质复杂度上，我们的“真实”工作效率自然会得到大幅度提升。
【减少工作中的重复性部分。善于分析问题，找准目标，有清晰的实现方式。】

【2】
说到做软件，本质上是在构建一个“集体想象”。
任何事物都要经过两次创造：一次是在头脑中的创造，也就是智力上的或者第一次创造(Mental/First Creation)，然后才是付诸实践，也就是实际的构建或第二次创造(Physical/Second Creation）。
要给用户看产品的样子，可以用原型工具把它做出来，而不是非得把完整功能开发出来；要呈现服务接口的样子，可以用模拟服务器搭出一个服务，而不用等后端全部开发完毕；要让程序员知道要开发产品的细节，可以在任务上描述出软件各种场景给出的各种行为。
践行“以终为始”就是在做事之前，先考虑结果，根据结果来确定要做的事情。
【开发软件之前，需要集合所有参与者的意见和建议，开发人员不要把自己割裂开来，想当然。】

【3】
DoD(Definition of Done，完成的定义)
DoD 是一个清单，清单是由一个个的检查项组成的，用来检查我们的工作完成情况。
DoD 的检查项应该是实际可检查的。
DoD 是团队成员间彼此汇报的一种机制。
DoD 是一个思维模式，是一种尽可能消除不确定性，达成共识的方式。
【接到开发任务时，应该明确完成的标准，列出各个开发的功能项。】

【4】
用户故事：站在用户的角度来描述一个用户希望得到的功能，关注用户在系统中完成一个动作需要经过怎样的路径。
用户故事的关键点：验收标准，它可以清晰地定义出需求边界。
验收标准非常重要的一环是异常流程的描述。
验收标准给出了这个需求最基本的测试用例，它保证了开发人员完成需求最基本的质量。
BDD（Behavior-Driven Development，也就是“行为驱动开发”）
【清晰的需求说明和验收标准，是程序员的好帮手。】

【5】
持续集成一个关键的思维破局是，将原来分成两个阶段的开发与集成合二为一了，也就是一边开发一边集成。
一个好的做法是尽早把代码和已有代码集成到一起，而不应该等着所有代码都开发完了，再去做提交。
【尽早提交代码去集成，每天下班前都要记得提交代码到SVN/GIT！】

【6】
我们必须要有自己的独立思考，多问几个为什么，尽可能减少掉到“坑”里之后再求救的次数。
IT行业是一个有趣的行业，一旦一个问题变成一个通用问题，就有人尝试总结各种最佳实践，一旦最佳实践积累多了，就会形成一套新的方法论。敏捷开发的方法论就是如此诞生的。
精益创业提出一个非常重要的概念，最小可行产品，也就是许多人口中的MVP（Minimum Viable Product）。简言之，少花钱，多办事。
精益创业提供给我们的是一个做产品的思考框架，我们能够接触到的大多数产品都可以放在这个框架内思考。
【程序面对新需求的时候，要确定是否要做、优先级，不要无脑接需求，心里生闷气。】

【7】
技术是一把利刃，程序员相信技术可以改变世界，但并不是所有问题都要用技术解决。手里有了锤子，眼里都是钉子。花大力气去解决一个可能并不是问题的问题，常常是很多程序员的盲区。
多问几个为什么，交流一下是不是可以换个做法，许多困惑可能就烟消云散了。而能想到问这样的问题，前提就是要跳出程序员角色思维，扩大自己工作的上下文。
当你对软件开发的全生命周期都有了认识之后，你看到的就不再是一个点了，而是一条线。
【扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上。】

【8】
先从结果的角度入手，看看最终要考虑哪些因素。推演出一个可以一步一步执行的方案，用前面考虑到的因素作为衡量指标。根据推演出来的方案，总结要做的任务。
对比我们的工作，多数情况下，即使目标清晰，路径却是模糊的。有些人是走到哪算哪，然后在看；有些人则是先推演一下路径，看看能走到什么程度。这两种路径所带来的差异，一种是前期其乐融融，后期手忙脚乱；一种是前面思前想后，后面四平八稳。
【在动手做一件事之前，先推演一番。】

【9】
如果我们可以在一开始，就设计好测量工作有效性的指标，那么就可以更有目的性地去工作了。而如果我们习惯了用数字去思考，就可以在很多方面让数字帮助我们。
【问一下自己，我的工作是不是可以用数字衡量。】

【10】
迭代0清单：
1.细化过的迭代1需求
2.用户界面和用户交互
3.基本技术准备
4.发布准备
迭代0是在正式开发迭代开始之前，进行一些基础准备的实践。
【设计你的迭代0清单，给自己的项目做体检。】

【11】
当一个复杂问题摆在面前时，我们解决问题的一个主要思路是分而治之。
任务分解就是这样一个有趣的思想，一旦分解的结果出来，到了可执行的步骤，接下来的工作就会顺畅很多。
与很多实践相反，任务分解是一个知难行易的过程。不同的可执行定义差别在于，你是否能清楚地知道这个问题该怎么解决。
【动手做一个工作之前，请先对它进行任务分解。】

【12】
对于程序员来说，只有在开发阶段把代码和测试都写好，才有资格说，自己交付的是高质量的代码。
测试框架最大的价值，是把自动化测试作为一种最佳实践引入到开发过程中，使得测试动作可以通过标准化的手段固定下来。
我们可以按照不同的层次进行划分：将测试分成关注最小程序模块的单元测试、将多个模块组合在一起的继承测试、将整个系统组合在一个的系统测试。根据不同测试的配比，也就有了不同的测试模型。
【多写单元测试。】

【13】
先写测试，后写代码的实践指的是测试先行开发(Test First Development)。
测试驱动开发(Test Driven Development)，TDD，红-绿-重构循环。红，表示写了一个新的测试，还没有通过的状态；绿，表示写了功能代码，测试通过的状态；重构，表示完成基本功能后，调整代码的过程。
测试先行开发和测试驱动开发第一步和第二步是一样的，都是先写测试，然后写代码完成功能，区别在于测试驱动开发还有一个更重要的环节：重构。
在测试驱动开发中，重构和测试是相辅相成的：没有测试，你只能提心吊胆的重构；没有重构，代码的混乱程度是逐步增加的，测试也会变得越来越不好写。
因为重构和测试的相互配合，它会驱动你把代码写的越来越好，这是对“驱动”一词最粗浅的理解。
【我们应该编写可测的代码。】

【14】
极限编程之所以叫“极限”，它背后的理念就是把好的实践推向极限。
如果集成是好的，我们就尽早集成，推向极限就是每一次修改都集成，这就是持续集成。
如果开发者测试是好的，我们就尽早测试，推向极限就是先写测试，在根据测试调整代码，这就是测试驱动开发。
如果代码评审是好的，我们就多做评审，推向极限就是随时随地的代码评审，这就是结对编程。
如果客户交流是好的，我们就多和客户交流，推向极限就是客户与开发团队时时刻刻在一起，这就是现场客户。
【将任务拆小，越小越好。】

【15】
很多人可能更习惯一个类一个类的写，最好按照一个需求、一个需求的过程走，这
样，任务是可以随时停下来的。
检验每个任务项是否拆分到位，就是看你是否知道它应该怎么做了。即使你的技术能力很强，我依然建议你把任务分解到很细，观其大略人人行，细致入微见本事。
每做完一个任务，代码都是可以提交的。
【按照完整实现一个需求的顺序去安排分解出来的任务。】

【16】
只有将复杂的测试拆分成简单的测试，测试才有可能做好。
我们不可能无限递归地给测试写测试。只有一个办法：把测试写简单，简单到一目了然，不需要证明它的正确性。如果你见到哪个测试写得很复杂，它一定不是一个好的测试。
许多人总想在一个测试里做很多的事情，比如，出现了几个不同方法的调用。这个测试一旦出错，就需要把所有相关的几个方法都查看一遍，这无疑是增加了工作的复杂度。
怎样的测试算是好的测试呢：
Automatic，自动化，测试尽可能交给机器执行，人工参与的部分越少越好；
Thorough，全面的，尽可能用测试覆盖各种场景；
Repeatable，可重复的，每一个测试本身都不应该依赖于任何不在控制之下的环境；
Independent，独立的，测试和测试之间不应该有任何依赖，实在要依赖，每个测试自己负责前置准备和后续清理，多个测试有同样的准备和清理那不就是setup和teardown发挥作用的地方吗；
Professional，专业的，测试代码也是代码，要按照代码的标准去维护。
【要想写好测试，就要写简单的测试。】

【17】
大多数人脑海中的需求描述是主题(epic)，在敏捷开发中，有人称之为主用户故事(master story)。
比如，时间紧迫的时候，我想看需求，你问产品经理，不做登录行不行？你就等着被拒绝吧。但是，如果你说时间比较紧，我能不能把登录验证码或者邮件地址验证的功能放到后面做，这种建议产品经理是可以和你谈的。
绝大多数问题都是由于分解的粒度太大造成的，少有因为粒度太小而出问题的。
评价用户故事有一个“INVEST”原则：
Independent，独立的；
Negotiable，可协商的；
Valuable，有价值的；
Estimatable，可估算的；
Small，小；
Testable，可测试的。
【想要管理好需求，先把需求拆小。】

【18】
艾森豪威尔矩阵：

【尽量做最重要的事。】

【19】
MVP：Minimum Viable Product，最小可行产品。
我们要学会用最小的代价做产品。
能不做的事情就不做，能简化的事情就简化。
我们要做的是验证一个想法的可行性，甚至不是为了开发一个软件，开发软件只是一种验证手段。
开发软件是一件成本很高的事情。如果只是验证想法，无论是创业方向，还是产品设计，我们可以找到各种各样的手段，不用写代码。
当时间有限时，我们需要学会找到一条可行的路径，在完整用户体验和完整系统之间，找到一个平衡。
【做好产品开发，最可行的方式是采用MVP。】

【20】
欢迎来到真实世界，真实世界不是以美好愿望驱动的，它有着自己的运行规律。虽然我们都生活在同一个世界中，但每个人理解世界的方式确实是千差万别。
我们努力的学习各种知识，为的就是更好地理解这个世界的运行方式，而沟通反馈，就是我们与真实世界互动的最好方式。
因为每个人经历见识的差异，造成了各自编解码器的差异。世界是同一个世界，每个人看到的却是千姿百态。
想要在这个真实世界中生活得更幸福一些，需要我们不断地改善自己的编解码器。
改善编解码，需要从几个角度着手，分别是：编码器，让信息能输出更准确；解码器，减少信号过滤，改善解码能力；还有编解码算法，也就是各种来自行业的“最佳实践”，协调沟通的双方。
【通过沟通反馈，不断升级自己的编解码能力。】