每周完成一个 ARTS：
Algorithm: 每周至少做一个 LeetCode 的算法题
Review: 阅读并点评至少一篇英文技术文章
Tips: 学习至少一个技术技巧
Share: 分享一篇有观点和思考的技术文章
题图：Trevor Cole
难度：Easy
题意：Given two binary trees, write a function to check if they are the same or not.
Two binary trees are considered the same if they are structurally identical and the nodes have the same value.
示例 1：
Input: 1 1
/ \ / \
2 3 2 3
[1,2,3], [1,2,3]
Output: true
示例 2：
Input: 1 1
/ \
2 2
[1,2], [1,null,2]
Output: false
示例 3：
Input: 1 1
/ \ / \
2 1 1 2
[1,2,1], [1,1,2]
Output: false
解法：
这道题比较简单，直接递归查看两个节点和其左右节点的值是否相同即可，但要注意结束条件，就是两个节点已经是叶子节点下面的节点了（其实已经是空，但为了好理解就这样称呼它），这个时候我们返回 True。
代码：
# Definition for a binary tree node.
# class TreeNode:
# def __init__(self, x):
# self.val = x
# self.left = None
# self.right = None
class Solution:
def isSameTree(self, p: TreeNode, q: TreeNode) -> bool:
if p is None and q is None:
return True
if p is not None and q is not None:
return p.val == q.val and self.isSameTree(p.left, q.left) and self.isSameTree(p.right, q.right)
return False
本周的文章来自 Medium 的 The Startup 频道《What Happens When You Lack Senior Engineering Leadership》。文章讲述了一个缺乏资深技术人员领导的公司 / 团队可能会出现的各种问题。
首先是「重构陷阱」。很多工程师在拿到他前任写的代码的时候，经常会发出「这 TM 是啥」的感慨，继而觉得，应该进行重构，自己能写出更好的代码。高级工程师也会碰到这样的情况，但根据经验，重构并不是一个好主意。通常而言，一个可用的软件应当是对世界做了准确的建模，而这个世界实际上就是「混乱的」，所以代码可能很难看，那是因为它需要精准地捕获这个世界的复杂性。「新代码总要好过旧代码」这一论调是明显错误的，旧代码是经过使用的、被测试了的代码，尽管有 bug，但很多的 bug 也被修补过了。
其次是「你可能得到了你所问的，但并不是你所要的」。在所有的研发工作开始之前，你都需要有一位资深的技术 leader 来询问基本的业务问题。即使是最彻底的产品路线图，也可能会有一些高级工程师需要填补的漏洞。没有资深工程师的经验和知识，这些漏洞就会无法填补。比如在一个电商类网站的制作过程中，产品经理提出需要添加一个对「颜色」进行过滤的功能，此时一位年轻的研发小哥走过，顺手将数据库中已有的颜色列表「酒红色、珍珠色、李子色」添加到了网站中，然而这是一个非常复杂的颜色过滤功能，一个资深工程师可能会选择将所有的蓝色衣服划为一类，当用户搜索「蓝色」时任何材质的蓝色衣服都会出现在用户眼前。
之后是「年轻工程师对技术潮流更敏感」。年轻工程师很多是刚从学校毕业的，所以对新鲜的技术潮流可能更敏感。但仅仅因为一门语言一种工具比较新就能证明它更好吗？这可未必。现在的新技术或者新框架的市场营销都做的非常好，年轻的技术人员可能会觉得这些新技术是自从切片面包发明以来最好的东西了。然而我们都知道，市场营销对用户体验和可靠性而言，并不总是对的。资深的技术人员并不会盲从于新的趋势或工具，他们会根据公司的需求、预算和框架，做出最适合的技术选型。
最后文章谈到了「工程师会糊弄非技术型领导」。这一点其实相对好理解，研发人员出于各种原因，可能会使用艰深晦涩的技术术语来使非技术型领导退让，有一位专业的技术领导就会避免出现这种情况。
众所周知，VS Code 有对用户代码片段的支持，只要点击主界面左下角的齿轮按钮，选择「用户代码片段」即可添加自己经常会用到的 snippets。有朋友对我的 ARTS 打卡的模板比较感兴趣，那么我下面就将这个 snippet 放上来
"ARTS template": {
"scope": "markdown",
"prefix": "ARTS",
"body": [
"# ARTS 第 $1 周",
"",
"",
"",
"> 每周完成一个 ARTS： ",
"> Algorithm: 每周至少做一个 LeetCode 的算法题 ",
"> Review: 阅读并点评至少一篇英文技术文章 ",
"> Tips: 学习至少一个技术技巧 ",
"> Share: 分享一篇有观点和思考的技术文章",
"",
"## Contents",
"",
"- Algorithm: ",
"- Review: ",
"- Tips: ",
"- Share: ",
"",
"## Algorithm",
"",
"### Algorithm 题目",
"",
"题目：",
"",
"难度：",
"",
"题意：",
"",
"示例：",
"",
"```script",
"",
"```",
"",
"解法：",
"",
"代码：",
"",
"```python",
"",
"```",
"",
"## Review",
"",
"### Review 题目",
"",
"## Tips",
"",
"### Tips 题目",
"",
"## Share",
"",
"### Share 题目",
"",
],
"description": "ARTS template"
},
使用时只要将其加入到你的 .code-snippet 文件中，保存，新建一个 markdown 文档，输入「ARTS」，再按 TAB，VS Code 就会自动将这个模板填入文档，接下来只需要填入内容就可以啦。
最近感觉自己的发力方向一直在公司需求和科研目标之间来回摇摆：公司老板是个想法很多的人，所以经常出现「我按照他的要求做了一个 prototype，向他汇报的时候他觉得他要的不是这个」这种情况；或者是自己写代码时候的洁癖，对文档和代码风格刻意的追求，导致论文复现速度缓慢。刚好看见「大狗熊」在他朋友圈发了一条关于使用「Scrum」来进行产品开发的心得体会，于是我打算了解一下「敏捷开发」。
在极客时间《说透敏捷》专栏中，宋宁在专栏开始就要求学员仔细理解「敏捷的五条价值观」，即：
- 个体和交互 胜过 过程和工具
- 可以工作的软件 胜过 面面俱到的文档
- 客户合作 胜过 合同谈判
- 响应变化 胜过 遵循计划
- 虽然右项有价值，但我们更重视左项
其中我觉得让我受益最大的两点分别是「可以工作的软件 胜过 面面俱到的文档」以及「个体和交互 胜过 过程和工具」：
不管是在日常开发还是论文复现的过程中，我个人的最大问题其实在于对代码质量有着过分追求，容易导致分不清事情的轻重缓急，然而「working software」才是最重要的东西，「code quality」和「comprehensive documentation」都在其次。如果像我一样强行注重代码质量和文档的话，实际上是提高了完成任务的门槛。这一点也可以引申到生活上很多其他的事情上去，「先完成再完善」是一条金科玉律，不要人为地增加完成一项任务的门槛。
在我目前的阶段，对于「个体和交互」的理解，也还仅限于和自己的两个老板的交流和沟通，但反过来想，他们很多我没有达到的要求，实际上都是出于没有对他们的期望做出更深的理解（u1s1，这也不全是我的锅🤣），如果能更多更频繁地进行交流沟通，我就能对他们（我的客户）的要求做出更快速地响应，更好地对当前工作做出调整。这也在某种程度上印证了第四点「响应变化」的重要性。
