ARTS - Week 3

Algorithm

Leetcode 70 climbing stairs

典型的递归题，不过直接用递归会超时，因为涉及大量重复计算。所以两种解

1. 递归加记忆化，抹除重复计算

2. 动态规划

Review

来自 Medium 的一篇文章 You don’t need Feature Branches anymore…

老外的一些文章总是给我一种文不对题的感觉。比如这一篇，咋一看题目感觉是在讲 Git 分支管理。实际上却是讲的开发管理。

他以反对多特性分支开发模式为切入点，阐述了自己的开发管理理念。主要观点无非是：

• code review

• 结对编程

• 快速迭代

说实话，我发现外国的开发者大多都是再鼓吹这三个观点。我个人是非常认同这中开发模式的。但是国内的公司有多少是实现这种模式的，就不得而知了。

就个人经历来说，我认为中国的大部分开发人员对“什么是好的代码”没有一个统一的标准，甚至大部分人都不知道怎么衡量“什么是好的代码”，所以以上提到的三点就无发实施。

• 没有人能说服别人什么是好的代码，只能定一系列死的规矩，例如大括号不准新起一行（逃～）

• 更不用提什么结对编程，“four eyes principle”等等

• 代码质量没有保障，就不可能实现代码 merge 到 master 分支就自动上线，必须等测试同事测完才能上线

Tips

利用 Slf4j MDC 优雅的给日志加上 traceId

在日常的生产环境排查故障是，我们免不了要去追踪日志来定位问题，在基础设施比较完善的公司，会有分布式链路监控，能够完整的看到一个请求的整个生命周期，通常一个请求会绑定一个 traceId。以此来追溯整个请求过程中产生的日志。

对于一个微服务自身，可以通过给日志增加 traceId 的方式，来追踪本机上一个请求相关联的所有日志信息。

通过 AOP + Slf4j MDC 的方式，即可优雅的给日志加上 traceId。

例如，给所有的 controller 方法进行 AOP 代理，在请求进入具体方法前，调用 slf4j 的 MDC 类的 put 方法，设置一组 key，value。例如 key=traceId，value=时间戳。然后在 logback 等配置文件的 pattern 里配置相应的占位符。

之后所有业务代码中打的日志都会带上 traceId。

Share

王争《数据结构与算法之美》 动态规划理论

动态规划学了 n 遍，忘了 n 遍，这篇文章总算给我聊明白了动态规划的几个关键点

适合动态规划求解的问题 —— 一个模型三个特征

1. 多阶段决策最优解模型，说人话就是解决的问题需要经历多个决策阶段（决策这两个字很关键），每个决策阶段对应一个状态，最终就会得到一组组的决策序列，然后从这些决策序列中的出最优解的这么一个问题模型

2. 特征一：最优子结构，即可以通过子问题的最优解推出最终问题的最优解

3. 特征二：无后效性，em。。。太学院派，没啥用的特征

4. 特征三：重复子问题，在不同的决策序列里，会出现重复的子问题。

写动态规划代码的几个套路

1. 状态表转移法

画一个表，通常对应代码里的二维数组，每一个坑位能同时表示 3 种状态，横坐标，纵坐标，数组值，比较容易思考，但是不适合维度太多的问题

1. 状态转移方程法

说白了就说状态表不好处理的问题，只能用这种方法来思考——想办法写出问题的状态转移方程