持续交付

瀑布式的软件工程方法将整个项目的周期划分为分析、设计、开发、测试，这样造成的困难是：一方面，在测试中返回的产品与用户实际需求的差异的责任将上溯到分析、设计和开发的各个环节，这种责任如果溯源到分析环节或者设计环节，将推翻已经投入的整个——或者是大部分开发周期，造成资源浪费；另一方面，这种重量级的开发模式从产品的分析到部署往往需要耗时长达一两年之久，而信息产业面临着非常快速的市场机会变化、技术方法革新等不可控外部因素，这就导致客户在一年前提出的需求已经完全不再适用于当下的市场，造成项目烂尾。

持续交付是一种轻量级的开发模式。持续交付将项目需求做详细的拆分，分解为能在较短时间内完成的细小任务，团队在短时间内完成细小任务的分析、设计、开发、测试，并向及时用户交付，得到用户的反馈意见。对应于瀑布模型的两个困难，持续交付这样做解决了两方面的问题：（1）对于单个细小任务的用户验收失败，无论原因发生在哪个环节，修复或者重构所需的成本较小；（2）将整个项目的分析、设计环节分散到了每一个细小任务，这样对于用户需求随外部因素的变化，产品可以实时调整方向，使产品始终瞄准客户当下的实际需求，以至于长期地为用户提供该产品的升级服务。

持续交付优于传统软件工程方法的原理在于它在组织上的革新，这是一些区别于机器工业的、针对信息产业的组织形式优化。

一方面是对资源投入的组织优化，与机器工业生产的成本主要来自原材料、能源和机器不同，软件开发的成本主要来自人员费，所以应该主要考虑如何减少人月量的浪费，而不是像机器工业生产中那样主要考虑减少原料成本，这是机器工业生产中选择瀑布模型的主要原因；而软件工业原始需求不稳定的特点是它选择持续交付的主要原因。

另一方面是对人员关系的组织优化，持续交付非常强调各个项目环节之间的交流沟通、以及开发人员与客户之间的沟通，这些沟通的引入，直接减少了由于内部信息不畅造成的资源浪费，相当于消除了一部分原本存在的风险因素。对交流沟通的强调，是持续交付得以提高生产效率的关键原理。

持续集成

持续集成考虑的是开发人员完成了代码后立即提交，然后立即开始测试，通过测试后就部署，并尽早得到用户的反馈。持续集成强调测试、部署的自动化。

微服务

微服务区别于单件产品的模式，主要考虑把产品的各个功能从“模块”转为“服务”。各个服务可以独立地上线、更新、重启，而不会影响到产品的其他部分以及产品整体。

为了达到这个目的，涉及到的一些技术细节包括：多个相同的微服务并发（分担访问负载），负载均衡（流量均衡），进程间通信的性能问题，微服务向索引服务器注册自己（类似于花生壳做动态DNS），微服务掉线时的处理等问题。

关于职场新人的第一天

虽然时常冒充00后以小鲜肉自居，但毕竟年龄日月穿梭催人老，终于当完了二十年学生。第一天职场生活很糗，前一天晚上竟然正赶上了地震，偏偏刚弄了这么高个房子，唐老师不敢回家睡觉要在小区院里睡瑜伽垫，我也只好跟着在旁边伺候了一夜没合眼，各种赶虫子打蚊子扇扇子掖被子递杯子奶孩子，于是第一天职场生活就在大脑极度疲乏中愉快地度过了。

唯一美中不足的是下班回家晚了，又被唐老师数落一顿，昨晚算是白白伺候了一夜，囧