提醒

本文预计阅读时间7分钟

每周完成一个ARTS
每周至少做一个 LeetCode 的算法题、阅读并点评至少一篇英文技术文章、学习至少一个技术技巧、分享一篇有观点和思考的技术文章。(也就是 Algorithm、Review、Tip、Share 简称ARTS)

由于微信公众号后台不支持在原文中添加链接,所以大家在文章最后面点击阅读原文就可以点击原文中插入的链接了,有问题随时留言交流~

一 

Algorithm

LeetCode538. Convert BST to Greater 

【题意】

给出一个二分查找树BST,更改里面的节点值,使得更改后的节点值为原来的节点加上所有比它大的节点的值。比如例子中的节点5,因为只有节点13比它大,所以更改的值为5+13=18,而对于节点2,因为节点5和节点13都比它大,所以更改的值为2+5+13=20。

【思路】

好久没刷LeetCode了,距离上次刷题好像还是几个月前怎么能怎么懒=) 这道题是之前一直想刷但因为不知道为什么一直还留着没用做,今天就从这道题开始吧。这道题题意很简单,一看就明白题目要求的是什么,但是因为好久没刷题了,一开始觉得还蛮复杂的,觉得首先至少应该把二叉树给遍历一遍,然后对于二叉树的每一个节点,查找除了该节点外的其他所有节点,然后判断节点的val大小,然后如果比它大就更新,这样想着想着觉得比较麻烦,看了一下这道题的标签居然是easy级别的!然后突然想起来应该用递归,然后想到二叉树三种遍历方式:前序,中序,后序。题目已经给出的是二分查找树BST,那就好办了,我们知道这样的树有一个特点,就是其节点左边的都比该节点的值要小,节点右边的都比该节点的值要大。

再进一步想到二分查找树的特点是中序遍历的结果是一个升序序列。而我们做加法时最简单的顺序就是从最大的值开始,降序地做下去。在树中对应的就是最右的叶子节点开始,因为该节点是最大的。如果对二分查找树有一定的敏感度的话,应该很容易就发现一个性质:如果我们按照中序遍历的逆序,即先右子节点,再父节点,最后左子节点顺序遍历的话,刚好就能降序地访问每一个节点。比如例子中就会是以13,5,2的顺序访问,这样我们每访问一个节点,就记录下到该节点的和,并在访问下一节点时将该和值加到节点的值上。以例子说明:
初始sum为0。
访问到13,更新节点值为13+sum=13+0=13,sum更新为sum+13=0+13=13;
访问到5,更新节点值为5+sum=5+13=18,sum更新为sum+5=13+5=18;
访问到2,更新节点值为2+sum=2+18=20,sum更新为sum+2=18+2=20;

因此,本题其实考的就是BST中序对应的逆序遍历,先访问右子树,然后父节点,最后左子树,并在访问过程中记录已访问的节点总和,累加到当前的节点上。

参考代码

/**
* Definition for a binary tree node.
* struct TreeNode {
* int val;
* TreeNode *left;
* TreeNode *right;
* TreeNode(int x) : val(x), left(NULL), right(NULL) {}
* };
*/
class Solution {
public:
void addSum(TreeNode * root, int & sum)
{
if(NULL == root)
return;
addSum(root->right,sum);//递归右子树
root->val += sum;
sum = root->val;//更新val值
addSum(root->left,sum);//递归左子树
}
TreeNode* convertBST(TreeNode* root) {
if(NULL == root)
return NULL;
int sum = 0;
addSum(root,sum);
return root;
}
};

Review

如何撰写技术文档(英文)

在日常生活中,我相信大家或多或少都写过技术文档,如何撰写一篇技术文档。并且同时考虑到它的实用性,可操作性,可维护性。那这篇文档可以算是一篇很棒的文档了。

一款软件有多好并不重要,因为如果文档不够好,人们就不会使用它

即使由于某种原因人们不得不使用它,因为人们没有选择,没有良好的文档,人们将不会有效地使用它或者你喜欢它的方式。

虽然几乎每个人都明白这一点。几乎每个人都知道需要良好的文档,并且大多数人都试图创建好的文档

但大多数其实做的并不好。通常,这不是因为他们不够努力。通常,这是因为他们没有以正确的方式做到这一点。

在这篇文章中,作者将技术文档(documents)分成四种:教程(tutorial)、指导(guide)、解释(explanation)和参考(reference)。解释了每一种文档的特点,并给出了写作建议。

ARTS for week1(20181019)_技术文档

三 

Tip

分享最近在项目中一个比较小的收获

最近一个项目在做数据的点播回放模块,测试的时候发现一个bug,每当客户端在服务端回放数据正常的时候点击停止按钮,服务端进程就会崩溃,这个问题之前就出现过但是之前一直忽略没有及时去解决,今天调试代码的时候发现在进度显示模块那里当点击停止按钮之后,原先更新进度的一个数值的分母的值变成了0,导致除数为0,从而导致程序崩溃。后来加了一个判断:在分子分母数都大于0的时候更新进度,如果分子或分母其中任意一个数值为0了则释放一个信号,通知服务端和客户端退出相应函数

虽然代码中两个数做除法这个点平常很容易被顺手就写了,可能大家也觉得没什么,但是我觉得一旦出了问题,后续如何定位问题点,去调试这些过程也是不太容易的,所以个人还是觉得这次出现的问题,正好也提醒了我以后要养成一个好的代码规范,代码的边界值判断这类很容易被大家忽略但其实还蛮重要的注意事项。

四 

Share

本文解释了什么是微服务架构,并且给出了一个简单的示例,在 Docker 里面使用 Flask 框架和 ZeroMQ 搭建一个简单的微服务应用。

ARTS for week1(20181019)_二分查找_02

ARTS for week1(20181019)_二分查找_03

新的一天,大家早上好~

ARTS for week1(20181019)_二分查找_03

ARTS for week1(20181019)_技术文档_05

ARTS for week1(20181019)_技术文档_06