10X程序员工作法
四个思考原则
- 为什么要做这个特性，它会个用户带来怎样的价值？
- 什么样的用户会用到这个特性，他们在什么场景下使用，他们又会怎样使用它？
- 达成这个目的是否有其他手段？是不是一定要开发一个系统？
- 这个特性上线之后，怎么衡量它的有效性？
以终为始 : 就是在工作的一开始就确定好自己的目标。
任务分解 : 将大目标拆分成一个一个可行的执行任务，工作分解得越细致，我们便越能更好地掌控工作
沟通反馈 :是为了疏通与其他人交互的渠道。一方面，我们保证信息能够传达出去，减少因为理解偏差造成的工作疏漏；另一方面，也要保证我们能够准确接收外部信息，以免因为自我感觉良好，阻碍了进步。
自动化 :将繁琐的工作通过自动化的方式交给机器执行，这是我们程序员本职工作的一部分，我们擅长的是为其他人打造自动化的服务，但自己的工作却应用的不够，这也是我们工作中最值得优化的部分。
思考问题：如果让你设计一个登陆功能，你会怎么做？ --引申出来的内容，需求是怎样的？
规划和发现
软件行业有很多英雄传说，一个人或者一个团队连续奋战一段时间，写好了一个软件，在上线前夜发现了一个问题，然后冒着“不成功便成仁”的风险，通宵达旦解决了问题，一战成名。
这种故事听起来让人热血沸腾，但仔细想想，为什么总在最后一刻发现问题？除了时间压力确实大的情况以外，大多数情况，他们还是一开始没有想好就动手了。
人类是一个擅长脑补的群体，一旦有人看到了这个文档，他就已经可以构想出这个平台已经存在的样子，进而给出各种各样的反馈：“我认为这个地方可以这样做”，“我觉得那个地方可以改改”
所有这些反馈都是真实的，因为他们已经“看到了”一个真实的东西。正是这些真实的反馈，让我们逐渐地锁定了目标。之后，我们才开始动手写代码。
最经常听到的一个问题就是，先做出来看看---这就是不知道终点的典型。
产经经理不靠谱，你该怎么办？
我们必须要有自己的独立思考，多问几个为什么，尽可能减少掉到“坑”里之后再求救的次数。
我们该怎么与产品经理交流呢？以终为始。我们是要做产品，那就需要倒着思考，这个产品会给谁用，在什么场景下怎么用呢？
默认所有需求都不做，直到弄清楚为什么要做这件事。
“砍”需求
评价用户故事有一个“INVEST原则”，分别是：
- Independent，独立的。一个用户故事应该完成一个独立的功能，尽可能不依赖于其它用户故事，因为彼此依赖的用户故事会让管理优先级、预估工作量都变得更加困难。如果真的有依赖，一种好的做法是，将依赖部分拆出来，重新调整。
- Negotiable，可协商的。有事大家商量是一起工作的前提，我们无法保证所有的细节都能100%落实到用户故事里，这个时候最好的办法是大家商量。它也是满足其他评判标准的前提，就像前面提到的，一个用户故事不独立，需要分解，这也需要大家一起商量的。
- Valuable，有价值的。一个用户故事都应该有其自身价值，这一项应该最容易理解，没有价值的事不做。但正如我们一直说的那样，做任何一个事情之前，先问问价值所在。
- Estimatable，可估算的。我们会利用用户故事估算的结果安排后续的工作计划。不能估算的用户故事，要么是因为有很多不确定的因素，要么是因为需求还是太大，这样的故事还没有一个能开发的状态，还需要产品经理进一步分析。
- Small，小。步子大了，不行。不能在一定时间内完成的用户故事只应该有一个结果，拆分。小的用户故事才方便调度，才好安排工作。
- Testable，可测试的。不能测试谁知道你做的对不对。这个是我们在前面已经强调过的内容，也就是验收标准，你得知道怎样才算是完成工作。
太多人给你安排任务，怎么办？
软件行业有个段子：做软件，最理想的交付日期是什么时候？答案是昨天，其次是尽快。所有提出业务需求的人都恨不得需求做就做好了。但事实总是那么不如意，所以，他们只能寄希望于需求尽快被实现。
为什么世界和你的理解不一样？
我们努力地学习各种知识，为的就是更好地理解这个世界的运作方式，而沟通反馈，就是我们与真实世界互动的最好方式。
"懒惰"应该是所有程序员的骄傲
优秀程序员应该有的三大美德：懒惰、急躁和傲慢。
懒惰，是一种品质，它会使你花很大力气去规避过度的精力消耗，促使你写出省体力的程序，别人也能很好地利用，你还会为此写出完善的文档，以免别人来问问题。
急躁，是计算机偷懒时，你会感到的一种愤怒。它会促使你写出超越预期的程序，而不只是响应需求。
傲慢，极度自信，写出（或维护）别人挑不出毛病的程序。
用简单技术解决问题，直到问题变复杂。
微服务
怎么划分微服务，也就是一个庞大的系统按照什么样的方式分解。
