Algorithm

本周选择的算法题是：Unique Paths。

impl Solution {
    pub fn unique_paths(m: i32, n: i32) -> i32 {
        let mut current = vec![1; n as usize];
        for _ in 1..m {
            for j in 1..n as usize {
                current[j] += current[j - 1];
            }
        }
        current[n as usize - 1]
    }
}

Review

The 3 Stages of Failure in Life and Work (And How to Fix Them)

一篇 2018 年的旧文，在 Medium 上取得了 9.1K Claps，用黄金圈法则介绍了失败的几种类型和解决它们的策略。

作者花了较多的篇幅去讲策略，其实在策略之外，感觉还是需要一些感性层面的，比如心态，去对抗特别难搞的问题。之所以这么说，是我认为策略的陷阱在于它太关注怎么前进了，似乎 “后退” 是不可接受的，但 “后退” 也是 “坚持下去” 的一种方式，就像 DFS 算法，我们需要从一个根节点出发，不断的深度优先探索，遇到挫折了再试一试，实在不行就放弃这个节点，换条路径再搜索，回头思考和重新审视问题，有时也是一种前进的方式，我们真正不能放弃的是根节点，它代表着我们想成功的欲望，也是我们坚守的信仰和不断努力前行的动力源泉。

Tip

Grafana Kiosk，非常有用的功能，可以把 Grafana 分享的看板链接以信息亭的方式展示。

大家是否有过和其他人关于某个场景该用哪个设计模式的争论？

“我更倾向于用 MVVM”
“这个场景用 VIPER 更合适”
“MVC 就足够了”
“…”

这类讨论很难有一个完美的结束，这类讨论也永远不会停止。

同样的，我们也常在一些公共场合听到别人用这样的话语作为开场白：

“我们这个系统采用了 xxx 设计模式”
“它采用 xxx 架构”

似乎在系统初始阶段就做了很清晰、完备的设计，并沿用至今，其实这是一个很大的误区，程序本身也是有生命力的，它会不断演进，这意味着很难在初始阶段就知道什么模式会适合你的场景，同时如果你对模式本身太过于关注，可能会陷入模式的陷阱中：我的代码一定要遵守 xxx 模式，哪怕和现有的场景有点不贴合了。

那要如何避免这些问题呢？

每个模式都有自己的价值，它们都是为某种常见的场景提供了通用的解决方案，虽然不同，但是它们背后的原则是一致的，即：

模块化
可重用
易读
易修改

我们只需要在代码上应用这些原则，模式就会自然体现。我们不用太关注模式本身，因为模式热度会降低，而原则的生命力会很久；模块化，尽可能编写可重用的代码，维护合适的文档，就足以让我们写出出色的代码。

此外，真正理解代码是给人读的这一点很重要，不需要很 fancy，因为：

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
— Martin Fowler

当然，如果你的代码既 fancy 也很容易理解，你就很棒。

我们并不是说设计模式没用，而是希望能更进一步，了解「Why」，而不是只停留在「What」，真正理解你所使用的模式背后的原则，用好的编程设计原则去发现模式，因为原则才是每一个模式背后的底层基础。

Algorithm

Review

Tip

Share