一. Algorithm
Given a binary tree and a sum, determine if the tree has a root-to-leaf path such that adding up all the values along the path equals the given sum.
Note: A leaf is a node with no children.
Example:
Given the below binary tree and sum = 22,
5
/ \
4 8
/ / \
11 13 4
/ \ \
7 2 1
return true, as there exist a root-to-leaf path 5->4->11->2 which sum is 22.
本周业余时间看了 《算法(第四版)》 第四章图的部分内容，复习了一下 DFS 与 BFS，因此选择了刷 Tree 相关的算法题。本周刷的是一道简单的考察深度遍历的题目。
基本思路:
- 1.使用 DFS 遍历所有的叶节点，计算叶节点到根节点路径的节点 val 之和，等于给定数字则返回 true
class Solution {
private boolean hasPath = false;
private int sum = 0;
public boolean hasPathSum(TreeNode root, int sum) {
if (root == null) {
return false;
}
this.sum = sum;
this.dfs(root, 0);
return this.hasPath;
}
public void dfs(TreeNode node, int num) {
if (this.hasPath) {
return;
}
num += node.val;
if (node.left == null && node.right == null) {
if (num == this.sum){
this.hasPath = true;
}
}
if (node.left != null ){
this.dfs(node.left, num);
}
if (node.right != null ) {
this.dfs(node.right, num);
}
}
}
比较简单的一个题目，当然还可以进行拓展，本周因个人琐事较多因此没有继续刷 Path Sum II。下周补上，会在继续学习 《算法(第四版)》图 的同时刷 Tree 相关的算法题
Review
本周读了耗子哥在专栏中推荐的一篇关于日志的小短文 The Problem With Logging.
作者的针对 “log everything” 的观点进行了批判。除了作者因为日志打印遇到死锁问题之外，滥用日志会有以下几个问题:
- 日志打印代码过多，影响代码的可读性与可维护性
- 日志打印消耗资源
- 日志信息过多导致日后检索日志变得麻烦
- 日志过多，但真正有用的信息很少
作者提到自己在项目中只保留的异常处理的日志，并且去掉过多的日志后并没有对项目产生影响，结合上述问题作者非常反对日志的滥用。
在个人最近的实际应用中，因为涉及到许多与第三方接口的对接，因此很多时候会将第三方接口传递过来的数据和结果使用日志打印出来进行查看。当然如果是自己的项目，还是首先应该不断的思考，明确代码思路和逻辑后在进行调式，避免过度依赖日志打印和 debug调试 (print 大法好= = )。
就整个项目的日志收集，还是需要根据实际需求来确定。如果只是需要在系统出错的时候快速定位错误，那么只需要考虑将错误处理输出到日志即可，如果需要记录每个接口调用的传参、结果，那么就需要对每个接口的访问情况制定日志进行收集，在权衡利弊之后进行日志的收集。
Tip
本周分享一下 Python 中 list 列表与 tuple 元组各自的使用建议。
学过 Python 的同学应该都知道，Python 中列表是长度可变的序列，而元组长度不可变。其背后的原理是 Python 的列表 list 在添加元素后总会预留部分空间，为将来新加元素做准备。当新加的元素超过预留空间时，就新建一个列表，将旧元素和新元素一起加到新的列表并再次预留出空间，同时将旧的列表清空。由此我们可以知道，Python 列表可变性的代价就是 额外的内存占用与额外的空间计算。因此当需要创建大量的长度较小的序列或者一个长度很大的大型序列时，不建议使用 list 列表，这两种情况都会占用较多的内存来充当预留空间。
元组创建后，其长度和内容都不会发生改变，因此非常适合存储某个对象基本不会改变的多个属性。元组不会预留空间，因此相对于列表其占用资源更少，并且当元组被删除时，其自带缓存特性，元组的内存空间不会立即删除，因此下次创建元组相对于列表也会更加的轻量级。在需要频繁创建删除序列的时候可以考虑使用元组而不是列表。
Share
之前看了一下 Redis 数据持久化相关的内容，简单来说 Redis 提供了两种方式: 快照与只追加文件。其实与 MySQL 的 dump 和 binlog 备份原理是基本一致。前者是将已经存储的数据导出进行备份，后者是根据对存储单元的修改操作进行备份。虽然各自细节不同，但原理基本一致相同。 技术浩如烟海，繁杂的细节长久不用便会遗忘，但在实现之上的原理和思想却基本不变。因此在学习的时候一定要注意对知识细节之上原理与思想的抽象和理解。
另外一点就是坚持写作的重要性。最近坚持了一个月使用ORID 笔记法记录每日工作情况以及部分阅读笔记。开始觉得并没有什么改进，但是在周末写半年工作回顾的时候照着每天写 ORID 的方式，迅速的理清了思路，做过什么、完成了什么、收获了什么，需要改进的地方还有哪些，下一步该如何去改进。从开始下手时一个思考框架就已经在脑海中形成，之后就是顺着框架写下去了，完全没有了以前写类似回顾的窘迫感。切身感受到的进步胜过任何形式的激励，以后自己更要坚持不断的学习输入，写作分享输出。
