SaaS行业的漏斗模型无非如下：
接触->注册->使用->留存->订阅->续费
现在流行的增长黑客方法是
度量每一步转化过程的转化概率
提出每一步可能提升转化的方案
使用A/B测试验证方案
上线经过验证的方案
重复以上循环
这种数据驱动的模式已经比过去依靠天才顶层设计和拍脑袋的方式成功率高出不少，但是能否进一步升级这种模式？我觉得这种模式最大的缺陷是，除了数据度量可以自动化之外，每一步都需要人工介入
人工介入存在以下问题
反馈迭代周期长
人工介入就不可避免认知偏误带来的问题
不可能给出太复杂的模型
最后一点重点解释一下。有没有想过为啥是以上6步转化呢？为什么不是60步呢？为什么是一条线型漏斗模型，而不是一个马尔可夫状态转移矩阵？事实上如果用户在应用内的每一次点击都算的话，肯定是远远不止6步，付费路径也肯定有无数种可能。说到底其实都是因为人脑容量有限，不可能给出过度复杂的模型。但做过机器学习的都知道太简单的模型不可能做出好的效果。
读书雷达by ThoughtWorks
序
作为一个技术人，我时常会感觉到自己有太多的书要读。但是事实果真是这样吗？ThoughtWorks出品的读书雷达正是想解决这样的问题，他们想罗列出市面上最少最精品的书，帮助每一个技术人抵达最无争议的前沿知识基础彼岸。目前读书雷达已经出到第三期，距离第一期已经过去了三年，可是他们却发现三年过去了并没有多少振奋人心知识或技能能够让编辑者心悦臣服地把它加入这个清单。也就是说只要我的读书速度比这个清单的更新速度更快，追上这个时代是一定能够实现的。有了这个清单，我可以花更少的时间金钱在其他知识来源，例如一些微信技术文章，在线课程等等。读书就应该在就精品的书上花时间深入钻研，亲身实践，内化成自己的思维模式，而不是用金钱购买大量书籍和课程，草草浏览之后束之高阁。
下面就按照六大分类罗列这个清单
思想领导力
《值得信赖的顾问》
《专业服务公司的管理》
《系统之美》
《成为技术领导者》
《奈飞文化手册》
《技术的本质》
《精益企业》
编程实践
《编码的奥秘》
《测试驱动开发：实战与模式解析》
《重构：改善既有代码的设计（第2版）》
《领域驱动设计》
《架构整洁之道》
《敏捷软件开发：原则、模式与实践（C#版）》
《数据密集型应用系统设计》
《深入理解计算机系统》
《演进式架构》
流程交付
《持续交付》
《凤凰项目：一个IT运维的传奇故事》
《代码大全》
《全程软件测试（第3版）》
《深入核心的敏捷开发–ThoughtWorks五大关键实践》
《Accelerate》
个人修炼
《演讲的技术》
《软技能-代码之外的生存技能》
《非暴力沟通》
《转行》
《你要如何衡量你的人生》
《正见：佛陀的证悟》
《深度工作》
认知提升
《技术垄断–文化向技术投降》
《智能时代》
《升维：争夺产品认知高地的战争》
《大教堂与集市》
《团队协作的五大障碍》
《论大战略》
《复杂》
新兴技术
《零信任网络：在不可信网络中构建安全系统》
《Mastering Bitcoin》
《深度学习》
《代码本色：用编程模拟自然系统》
Posted on Aug 5, 2021
架构特性必须满足三个条件
指出一种非领域设计考量
影响设计的一些结构方面
对应用成功至关重要
可用性：系统的可用性
连续性：灾后恢复能力
性能：压力测试，高峰分析，函数调用频率，能力要求和响应时间
恢复能力：业务连续性要求，灾难发生后多块可以重新上线，影响备份策略和冗余硬件
可靠性/安全性：评估系统是否需要安全地失败？是否它是性命攸关不容失败的？是否会导致公司损失一大笔钱
健壮性：当断电或硬件错误发生的时候处理错误和极限条件的能力
伸缩性：系统应对大量用户请求时候的能力
可配置性：终端用户是否能够通过有用的界面容易地改变软件的配置
可扩展性：插入新功能是否很重要
可安装性：在所有必要平台安装的容易程度
复用性
本地化能力：支持多语言，多字体
可维护性：系统变更有多容易
平台适配性：系统能够在各自平台上运行吗
支持能力：应用技术支持水平。需要怎样日志的水平来debug
可升级性：服务端或客户端可以快速从一个版本升级到新版本的能力
可访问性：能够被所有用户访问，包括色盲耳聋的失能人士
可归档性：数据需要在一段时间之后被归档或者删除吗
鉴权：验证用户身份的安全需求
授权：保证用户只能访问特定功能的需求
法律：法律对系统有什么法律约束
隐私：对内部员工隐藏事务的能力（加密事务以便使得即使是数据库管理员和网络架构师也无法看）
安全性：数据需要被加密吗？内部系统之间的沟通需要加密吗？
支持能力
可用性和可获得性：用户需要多少训练才能达成她们的目标
性能有效性：衡量在已知条件下，使用单位资源达成的性能。包括：
时间行为（响应时间，处理时间，吞吐量）
资源利用（使用资源的数量和类型）
能力（超出最大既定限制的程度）
兼容性：
系统和其他产品，系统或者模块能够交互信息的程度，
能够与其他系统在共享环境资源条件下共存的能力
可用性：用户可以有效，高效，满意地完成它的目标
可识别性：用户可以辨别系统是否适合他的需求
可学习性：用户可以轻松的学习如何使用软件
用户错误保护
可触达性：各自特征和能力的用户都能使用
可靠性
安全性
可维护性
可迁移性
永远不要瞄准最好的架构，要瞄准最不差的架构
把架构设计成可迭代的
识别架构特性《软件架构：架构模式、特征及实现指南》第五章
Posted on Aug 7, 2021
软件架构师要从以下三个方面识别架构特性：
领域关注点
领域需求
隐性领域知识
从领域关注点识别架构特性
一个常见的错误：尝试设计一种支撑所有架构特性的
一种比较好的方式是，先列出所有想到的架构特性在一个清单里，再让领域stakeholder挑选最重要的3个特性。
把领域关注点翻译成架构特性
并购和收购 -> 互通性、可伸缩性、适配性、扩展性
上市时间 -> 敏捷性、可测试性、易部署性
用户满意度 -> 性能、可用性、容错性、可测试性、敏捷性、安全性
竞争优势 -> 敏捷性、可测试性、易部署性、伸缩性、可用性、容错性
时间和预算 -> 简单性、可行性
一件重要的事：上市时间并不等于敏捷性，而是敏捷性+可测试性+易部署性
从需求中识别架构特性
显性架构特性
隐性架构特性
（没什么方法，只有靠经验了）
第三章：模块化
度量模块化
三个关键概念：
内聚性（cohesion）
耦合性（coupling）
共生性（connascence）
内聚性
内聚性是指一个模块的所有部分必须在一起的程度。换句话说就是度量各个模块必须在一起的程度。理想状态下，一个内聚的模块所有的部分都必须在一起，因为如果把它们分成更小的碎片，就会导致其他模块必须通过模块间调用来得到有用结果，从而使得模块间更加耦合。
内聚性度量，从最好到最差
功能内聚：模块的每个组件都互相关联，并且模块只包含对功能必要的模块
顺序内聚：两个模块互动，一个模块输出数据，成为另一个模块的输入
通讯内聚：两个模块形成一个通讯链，每个模块各自操作信息并且/或者产生一些产出。例如，添加一个记录到数据库并基于这些信息生成一个email
流程内聚：两个模块必须以一定顺序执行代码
时间内聚：模块在时间上依赖
逻辑内聚：模块内的数据逻辑上相关而非功能上相关。例如：有一个模块从文本，序列化对象或流中转化信息。操作是相关的但是功能是很不一样的。
意外耦合：模块中的要素除了在同一个源文件中以外互不相关。这是最糟糕的一种内聚
内聚性并不像耦合性一样有精确的度量指标。
一种度量方法
LCOM（Lack of Cohension in Methods)
没有共用字段的方法数量
耦合性
输入耦合：度量从外向内的连接数
输出耦合：度量从内向外的连接数
抽象性，不稳定性和主序列距离
抽象性是指抽象和实现的比例。度量抽象和实现的比例。例如：假如一个代码仓库只有一个main函数，这个代码仓的抽象度为0.另一个极端是，一个代码库有太多抽象，让开发者难以理解
不稳定性度量代码的易变性。例如，假如一个类调用了很多其他类的方法，那它就很不稳定
抽象的代码通常更稳定，但是更无用，更难理解。
当我们对代码做抽象的时候需要考虑它带来多少稳定性，否则付出的难以理解就是不值得的。
共生性（Connascence）
如果两个模块，其中一个的改变需要另一个也相应改变以保持系统整体的正确性，那么我们说这个两个模块是共生的
两类共生性
静态共生性
动态共生性
各种共生性按从优到差的顺序排列依次是：
静态共生性包括
命名共生性：模块之间必须约定实体命名
类型共生性：模块之间必须约定实体的类型
意义共生性：模块之间必须约定实体的意义
位置共生性：模块之间必须约定实体的顺序
算法共生性：模块之间必须约定算法
动态共生性包括
执行共生性：模块之间的执行顺序影响结果
时间共生性：多个模块的执行时间点影响结果。例如两个线程使用同一内存的同时执行
值共生生性：多个值必须同时更改。例如用四个顶点坐标来表示一个长方形，那么为了保持数据结构的完整性，就不能随意修改单独一个点的坐标
身份共生性：多个模块必须引用同一实体
代码重构时，要把差的共生关系改变成更好的共生关系
区域性
距离很远的模块有强共生性就意味着糟糕的耦合，而距离相近的代码具有共生性是可以的。
程度
共生的程度是指影响的规模。只是影响很少的类还是很多？假如你只有很少几个模块，那么有动态共生性也不是很可怕，但是，通常代码会随时间增长让问题越来越大
提升系统模块化的三个建议
通过把系统拆分成多个封装要素最小化整体共生性
最小化其他遗留的跨越封装边界的共生性
最大化封装边界内部的共生性
传奇的软件架构创新者Jim Weirich的两条建议：
影响法则：把影响大的共生性转化成弱的共生性
区域法则：软件要素之间的距离越远，越要使用更弱的共生性
以上是1990年代的共生性理论，它对于现代架构师面临的问题并没有给出解决方案
架构思维 《软件架构：架构模式、特征及实现指南》 第二章
Posted on Aug 4, 2021
第二章：架构思维
理解架构和设计的不同，并且知道如何与团队成员协作以便让架构落地
需要有技术知识的宽度并维持一定的技术深度，以便能够看到其他人看不到的解决方案和可能性
理解，分析，回溯各种解决方案和技术的取舍
理解业务驱动因素的重要性，以及如何把它们翻译成架构考量
架构VS设计
传统的工作方式如下：
架构师的任务是分析业务需求以便提取和定义架构特性，选择适合问题领域的架构模式和风格，并创建组件。
从这些活动里创造出来的产物会分发给开发团队，开发团队的职责是创建每个组件的类图，创建UI界面并开发和测试源代码。
但是这种方式通常会有问题。架构师的决策收不到开发者的反馈，开发者的设计得不到架构师的反馈
正确的工作方式：
架构师和开发者必须在同一个虚拟团队，架构师直接给开发者提供指导
技术广度
三种知识
你知道的
你知道你不知道的
你不知道你不知道的
你知道的：必须维持
作为架构师广度比深度更重要
分析架构取舍
不能只知道架构优点而不知道架构缺点
平衡架构和编码工作
避免瓶颈陷阱：不要承担项目关键路径上的代码
可以做非关键路径上的项目
可以做POC以验证架构决策
可以做技术债务
做bug修复
开发自动化工具帮助团队处理日常重复的事务
开发架构适应度函数
做代码评审
第一章：概述
软件架构的定义
软件架构包括四个部分：
系统结构
架构特性
架构决策
设计原则
系统结构
系统结构是指系统实现的架构风格，例如：
微服务
分层
微内核
架构特性
架构特性是指系统成功的标准，通常和系统功能是正交的。架构特性包括但不限于：
可用性
可靠性
可测试性
可伸缩性
安全性
灵活性
容错性
弹性
可恢复性
性能
可部署性
可学习性
架构决策
架构决策定义了系统构建的规则。例如前端不能越过服务层直接访问数据库。当出现违反这些规则的情况，成为架构不一致。架构不一致通常需要被架构委员会评审
设计原则
设计原则与架构决策不同，它只是一个指引，不是硬规则。例如：微服务之间的调用尽量使用异步消息以提高性能，这只能是一个设计原则，它不能覆盖所有情况
架构师的期待
架构师要有以下8种能力
做出架构决策
持续分析架构
保持与最新趋势同步
保证架构决策被执行
要有多种技术、框架、平台和环境的经验
拥有业务领域知识
拥有人际技能
理解并能玩弄政治
软件架构的法则
软件架构的第一定律
软件架构的任何事情都是取舍
软件架构的第二定律
为什么比如何做更重要
人工智能可能会导致大量人失去工作
人工智能可能会创造出来的新工作如人工智能的维护和运用
但是这些工作需要的知识技能不是短时间内能够学习得到的
成为人工智能的驾驭者半人马可能是一种思路
但是人类在半人马人机合作中可能会越来越不重要
政府可能需要给失业的个人提供更多协助
全民基本收入可能是一种社会制度
提供意义和社群将有可能比对工作的追求更有意义
生态危机，科技颠覆，