1.开篇
本质复杂度：解决一个问题，无论如何必须要做的事情。
偶然复杂度：选择的方法不当，要做很多事。
程序员忙碌主要是因为偶然复杂度导致，怎么解决，4个原则：以始为终，任务拆解，沟通反馈和自动化
2.一个思考框架
目标（以始为终）：我们为什么要做这个需求，有什么价值
现状：什么场景需要用到这个功能，用户会怎么用。
实现路径（任务分解）：达成目标的手段，是否一定要做系统
结果：如何衡量是否达到了效果
3.以始为终主题
1.遇到事，倒着想。比如亚马逊开发软件：写新闻稿，写FAQ，写用户文档，最后才写代码。先确定产品最终的样子（目标），最后才是具体落地。
2.DoD：完成的定义
做任何事情，先定义完成的标准：与人协作事情沟通层面，定义清楚每个事情完成的标准，避免各个团队之间发生误解和隔阂。
3.接到需求先做什么
在做任何需求或任务的时候，先定义验收标准。验收标准代表了要达成目标必须实现的功能，代表了这个需求实现需要依赖的功能。
4.持续集成
尽早提交代码去集成
5.产品经理不靠谱
默认所有需求都不做，直到弄清楚为什么要做这件事
6.解决了很多技术问题，为什么依然在坑里
扩大自己工作的上下文，别局限在程序员角色里。技术可以解决问题，但别手里有锤子哪里都是钉子。一个很棘手的技术问题，可能因为产品的一点细微改动就可以解决。从开发到认识整体软件的流转到认识公司的业务流转。
7.做事前先推演
动手之前，先推演一番。软件开发过程中，我们假设已经开发就绪。看看就绪后需要做哪些事情，比如如何上线，如何推广。避免摔倒在最后一公里。
8.工作用数字测量
你的工作是否可以用数字来测量，数字是准确的而不是一种感觉，数字反应出来的问题简单直观。做一件事情如果结果可以用数字测量，大家就有一个共同的目标，而不是各说各的感觉。
9.迭代0
开发前应该准备什么：需求细化到可执行程度（验收标准），前后端交互流程，技术选型，技术架构，数据库准备，集成测试，发布脚本。
4.任务分解
4.1动手之前先先进行任务拆解，拆解的粒度是可执行，如果你清楚知道工作接下来该怎么做，任务拆解就告一段落了。
4.2 多写单元测试，开发阶段能够解决的问题，不遗留到测试阶段去发现。类比需求阶段能够解决的问题，不遗留到开发或者测试阶段发现。因为越往后改造成本越大
4.3测试驱动开发（TDD）是先写测试，然后开发，最后重构代码（因为第二步开发只是为了让测试通过，重构消除代码坏味道，重构代码又可以依赖测试保障质量）。
4.4如何才能TDD：1.任务拆解，每一个任务足够小和独立且可测试，每个任务完成后代码可独立提交（这个要求想得非常清楚）。2.任务足够小，足够小的任务可以可以坚持下去，比如每天一个俯卧撑，你肯定可以坚持下去。一天100个，估计坚持不了几天。3.任务足够小，我们针对这个任务就可以把方方面面想清楚。4.按照完整实现一个需求的顺序去安排拆解的任务
4.5如何写好测试：写简单的测试，只测一个功能（前置准备，执行，断言，清理）。好的测试应该包含5个特性：自动化（断言），全面（覆盖率），可重复（每次执行一样），独立（不依赖任何东西）和专业（测试代码也是代码，跟写代码一样认真对待）
4.6砍需求：程序员可以进行需求拆解，拆解原则：独立，有价值，可估算耗时，可测试。需求拆解后，可以反问产品经理每一部分需求的价值和优先级。
4.7需求太多如何处理：重要紧急的先做，重要不紧急有序做，紧急不重要尽量不做，不重要不紧急不做
4.8最小代价做产品：包含2层含义，代价最小和可行。代价最小是指能不做就不做，能简化就简化。可行是指用户维度是一条完整的链路，比如贷款平台先做贷款后做还款，因为还款是1个月后。
5.沟通反馈
5.1 沟通是信息的传递，有编码（逻辑表达）和解码（自身的理解能力），只有提高自己的表达能力和理解能力才能更好的传递信息
5.2 代码为谁而写：1.任何人都可以写出计算机可以理解的代码，只有好程序员才能写出人能够理解的代码。2.人要负责把业务问题和机器执行连接起来，缺少了业务背景不可能写出好代码。3.想起好名字，需要用业务语言去写代码，尽可能多学业务知识，把业务领域的名字用在代码中。
5.3总是开会：1.开会只是信息同步，而不是会议中讨论，所有事项应该会议前沟通好。2.减少开会人数，讨论的话找人当面沟通。3.站会，做了什么确认（是否计划内），要做什么（同步协作人员），问题和求助（是否有问题需要帮助）
5.4多尝试用可视化工具沟通：1.技术雷达通过象限和圆环来表示技术的分类和所处阶段，一目了然。团队也可以采用技术雷达方式表示团队需要掌握和了解的各类技术。2.可视化沟通工具，看板
5.5持续集成快速反馈：1.本地小步测试提交，测试完成提交保证快速。2.及时反馈，持续集成工具引人注目的反馈。
5.6 开发中问题一再出现，如何解决：1.复盘，自己旁观者的身份过程还原，做得好的，做得欠佳的，问题或者建议。写事实，投票选出需要解决的问题，制定可执行的行动，定期review进度。2.问题根因可以采用5why分析法
5.7 多聆听用户声音：1.吃自家的狗粮，细细体会自家的产品。2.自己无法体会的时候，可以采访客户或者客服团队轮岗，理解用户需求，听到最前线的炮火。3.谁离用户近，谁有发言权，与产品经理构建共同语言，领域驱动设计中的通用语言
5.8 尽早暴露问题：事情往前做，尽早暴露问题。如果隐瞒问题，会导致更大的风险。程序里面就是尽早失败，所有的异常情况前面都拦截。
5.9 多输出，让知识更有结构：1.按照金字塔原理搭建结构，编写文档。2.输出无论是演进还是写作可以帮你把知识连接起来。3.写作和公开演进都是可以通过练习提高的
6.自动化
6.1优秀程序员3大美德：懒惰（自动化），急躁（不容忍计算机偷懒，追求极致性能），傲慢（极度自信，写出别人无法挑错的程序）。
6.2先说不自动化的点，哪些事情可以不做，能不做就不做。
6.3工作过程自动化，别把时间消耗在该机器干的活上
6.4测试验收自动化BDD模型
6.5 软件代码怎么变混乱的：参考《敏捷软件开发：原则、实践与模式》，学习设计原则solid：单一职责：一个模块只有一个原因修改。开放封闭原则：扩展开放，修改关闭。变的部分抽象一下。里式替换，接口隔离，依赖倒置
6.6分层架构：分层架构是设计上的分解，分层的意义：构建一个良好的抽象，前端会变，后端数据会变，只有领域对象不会变，构建好自己的领域模型
6.7 用简单技术解决问题，直到问题变复杂
6.8微服务：1.划分好微服务需要先学习DDD，学习DDD参考领域驱动设计精粹，DDD把你的视角从技术拉回业务。2.知道了限界上下文，也别轻易进行服务拆分，先在一个服务内部分模块孵化
7.应用
7.1新入职公司如何快速熟悉
7.2面对遗留系统，怎么做
1.找到遗留系统混乱的根因，架构或者领域混乱
2.确认修改方案，构建测试防护网保证新老功能一致，分成小块逐步替代，构建好领域模型，寻找行业中关于系统构建的最新理解。参考《修改代码的艺术》
7.3如何保持竞争力
设定一个目标，在学习区不停学习成长。成为T型人才，一专多能。
书籍推荐：代码整洁之道，实现模式，程序设计实践，卓有成效的程序员，敏捷软件开发：原则实践和模式，架构整洁之道，header first设计模式，企业应用架构模式，unix编程艺术，解析极限编程，重构第二版，测试驱动开发，持续交互2.0，修改代码的艺术，领域驱动设计精华，精益创业实战，人月神话，程序员的职业素养，高效人士的七个习惯，心流。
