【Incident Review】Debate about Leetcode NO.799

Before

这文档或许可以称为一篇复盘文档吧。

Cause

首先看起因。

799. 香槟塔

我们把玻璃杯摆成金字塔的形状，其中 第一层 有 1 个玻璃杯， 第二层 有 2 个，依次类推到第 100 层，每个玻璃杯 (250ml) 将盛有香槟。

从顶层的第一个玻璃杯开始倾倒一些香槟，当顶层的杯子满了，任何溢出的香槟都会立刻等流量的流向左右两侧的玻璃杯。当左右两边的杯子也满了，就会等流量的流向它们左右两边的杯子，依次类推。（当最底层的玻璃杯满了，香槟会流到地板上）

例如，在倾倒一杯香槟后，最顶层的玻璃杯满了。倾倒了两杯香槟后，第二层的两个玻璃杯各自盛放一半的香槟。在倒三杯香槟后，第二层的香槟满了 - 此时总共有三个满的玻璃杯。在倒第四杯后，第三层中间的玻璃杯盛放了一半的香槟，他两边的玻璃杯各自盛放了四分之一的香槟，如下图所示。

现在当倾倒了非负整数杯香槟后，返回第 i 行 j 个玻璃杯所盛放的香槟占玻璃杯容积的比例（ i 和 j 都从0开始）。

示例 1:
输入: poured(倾倒香槟总杯数) = 1, query_glass(杯子的位置数) = 1, query_row(行数) = 1
输出: 0.00000
解释: 我们在顶层（下标是（0，0））倒了一杯香槟后，没有溢出，因此所有在顶层以下的玻璃杯都是空的。

示例 2:
输入: poured(倾倒香槟总杯数) = 2, query_glass(杯子的位置数) = 1, query_row(行数) = 1
输出: 0.50000
解释: 我们在顶层（下标是（0，0）倒了两杯香槟后，有一杯量的香槟将从顶层溢出，位于（1，0）的玻璃杯和（1，1）的玻璃杯平分了这一杯香槟，所以每个玻璃杯有一半的香槟。

题目也比较简单，动规+模拟即可解决。一开始想着除了模拟外，能不能推出数学公式来解决这道题，不过后来发现是我想多了。题目是杨辉三角的变种，但公式推不出来，老实模拟就好。下面是解答。

public double champagneTower(int poured, int query_row, int query_glass) {
    double[][] ca = new double[102][102];
    ca[0][0] = (double)poured;
    for(int l = 0; l <= query_row; l++){
        for(int r = 0; r <= l; r++){
            double d = (ca[l][r] - 1.0) / 2;
            if(d > 0){
                ca[l+1][r] += d;
                ca[l+1][r+1] +=d;  
            } 
        }
    }
    return Math.min(1.0, ca[query_row][query_glass]);
}

Detail

直接放聊天记录。

Result

结局自然是以我被踢出群聊结束。

Thinking

很多思考的内容在傍晚的椭圆机上已经思考过了，现在也不大能保证还原当时的想法。

首先就是我为什么会“急了”。

现在想来，不外乎是以下几点：

1. 讨厌被不熟的人说教。就有那么一种感觉“你在教我做事？”我985计算机出身，两段大厂经历，至于被一个互联网的上臭鱼烂虾指指点点？尤其是对面可能还没毕业，或者才毕业2个月的情况。你寄吧谁啊。

2. 无法理解的脑回路。面向过程的算法题能扯到面对对象，aop，执行效率高，易读性好，太好为人师了。

3. 面对互联网常用语“急了”没有做到很好的应对。当下互联网上的争论很多是无意义的争论，面对这种没有意义的“急了”，万能解答“典”，“典中典”就可以怼回去了，而不是先自认“急了”，在继续在原问题上争辩，没有意义。

网络君子六艺：典、孝、急、乐、蚌、赢

1. 好为人师，说教闭口不谈，实质性的内容也没谈多少，只谈谜语。OOP，AOP也没说出个所以然来。更有一种“刚学了一个概念，就出来装逼”的感觉。

来自taisa的良言

不熟的人和他来回3个回合就算我输了

Others

写这篇复盘文档更多不是为了看这道题，或者这件事怎么怎么，更关心的是自己的思考。（虽然这里有的思考说一个月以前的了，hhhh）

交付价值，不是交付需求(业务)

在交付需求的时候，有自己的思考or判断吗？对于一个需求，交到研发手上，为什么要做，要怎么做好，要做成怎样，这些其实还是值得我去思考的。但是或许是由于时间的原因，导致我没有很好的去履行有关方案，仅仅是接到需求，拿到手就去做了，其实还是可以更多的去思考要怎么做的更好。

这里的做的更好可以再补充一下，性能（各种耗时），交互（各种体验）。

时间忙是客观因素，需求A刚提测就来了需求B，疲于奔命忙着各种需求，带来了一系列问题，比如[没成长]，[心累时间忙]等。

那我在空闲之余，有完成我自己的承诺吗？现状梳理，文档沉淀，技术规划，性能or体验优化，很多事情都没有达成。

从理想倒推，从现实延伸

持续打磨产品，体验优化。

体验竞品，学习优秀。

我所负责的模块要达到一个怎样的水平，达成一个怎样的目标？

个人成长，未来规划

对不起，目前还没有什么规划。

接下来一年能做成怎样？

这里还是写一下吧。总归还是要用到的。不过也只是把文档上的内容搬了过来。

技术能力:

1. 可拓展
2. 健壮
3. 可复用：低耦合，高内聚，热插拔，面向接口编程
4. 稳定

业务能力：

1. 熟悉业务，无需多说
2. 协调推动
3. 判断力与优先级

控制情绪，坦诚清晰

心平气和，理性沟通

更多的时候还是善意假设，换位思考吧。不以恶意揣测他人。

想起一个badcase，在排查问题时对.remake过火了些。是的，资源包有问题，但这是从经验出发，我更想知道的是为什么会造成这个问题，是哪里出了错。

更之前的badcase无疑是打低评价。不管是情绪化还是怎样，还是要从实际出发，善意假设，不以恶意揣测他人。目光放长远，从他人角度出发。

心平气和，心平气和。

人与人之间还是要少些攻击性

人与人之间还是要少些攻击性，与自己和解，与他人和解，与世界和解。

有的玩笑能不开就不开，在玩笑的背后何尝又不是心酸血泪呢。

我原本以为幽默就是幽默，但人微言轻的时候，幽默就成了搞笑，搞笑就容易被当成小丑。

不要从经验出发

经验或者说惯性有时还是很可怕的。在面对某一问题上时，我可以说按经验是xxx出了问题，但是这并不够，我更希望找到根本原因，哪一行代码写错了。

有时经验/惯性带来的伤害也是不小的。回想起在做需求时，按照经验这个地方应该这么写（线上就是这么写的），但是写完发现这里总会造成一个抖动，经验让我选择了相信这里的代码，并没有去怀疑他，然而最终发现还是这里出了问题。

另外一个经验/惯性带来的问题也是同样。历史代码里矩阵运算后乘了一个scale,但是经验没有告诉我在特定情况下这个scale总是1，而在我的场景下scale的值是可以变化的，进而产生了问题，经验就是这样带来了其他问题。

非暴力沟通

• 重要的事情说三点，比如三个论据，三个论点，三个观点等（最简单的结构化表达）
• 先说结论，再说过程和原因，然后再说结论。
• 说清楚What，How，Why

说回这里，互联网上有的争论确实是没有意义+浪费时间，典就完事了。

挖掘事物背后的本质

深入底层，多看源码，不自嗨。

了解问题发生的原因
挖掘事物背后本质
寻找其他相似问题

持续学习

多读书，多学习，多看源码。