2023 ARTS 打卡第一周

A

开启刷题计划，今天刷了 Leetcode80: 删除有序数组中的重复项 II题目就不在这里描述了下面就展示一下代码以及思路

code

func removeDuplicates(nums []int) int {
     n := len(nums)
     if n <= 2 {
        return n
     }
     slow, fast := 2, 2
     for fast < n {
        if nums[slow - 2] != nums[fast] {
            nums[slow] = nums[fast]
            slow++
         }
         fast++
     }
     return slow
}

思路

由于给定的数组是连续的，那么相同元素就是连在一块的。就可以使用快慢指针进行处理。slow 指针表示已经处理数组长度，fast 指针表示已经检查数组长度，题干中要求相同元素至多出现两次，那么我们就可以判断 nums[slow-2] = nums[fast]，如果相等证明三个连续的元素相等，此时 nums[fast]就不应该保留，依次移动快慢指针遍历完数组，即可得到 slow 为最终的数组长度。思路大概如此，这题是一题使用双指针的题目，双指针考察算是比较频繁的。

R

最近看了一篇 blog https://dev.to/memphis_dev/grpc-vs-rest-33dl

英语不太好，其实主要还是靠翻译软件才看完的

文中主要讲了 gRPC 和 REST 的起源、使用、限制和问题等等方面来阐述他们的不同其实归根结底有如下几个方面的区别：消息格式基于什么 HTTP 协议延迟 and 速度负载限制安全性最后我觉得其实两者之间很难分清孰优孰劣，每一种都有自己适合的场景以及自身的优势，我们应该根据所需要的场景合理的选择它们，这样才能得到最优解。感觉在计算机领域，这样的情况非常多，比如语言与语言比较，架构与架构比较，库与库比较。每一个分支的技术都是不断进步发展的，没有很绝对的说法，后面出现的就是最好的，因为他完善了。我个人认为后面完善是因为我们所面对的场景越来越多，而不是因为这项技术落伍了。选择合适的场景用上合适的技术，就会得到最优解。大家是这样认为的吗？

T

一个写代码的建议（其实也不算建议，都是自己踩过的坑部门提交代码后会有一些检查机制，自己踩了很多坑 1、一个函数不要写太长，尤其是有 if 判断和 for 循环的。if 判断 尽量判断 false。（这种情况如果过长可能会遇到 lint 检查报复杂度过高）2、对于一些通用的逻辑判断代码，可以单独抽出来写成一个函数，比如通过 token 获取用户信息。（这种情况可能会遇到 lint 报重复代码过多）3、自己定制化 Http 方法的时候，其实每种方法都有很多重复的代码，我们可以通过一个 option 参数，随后使用 switch 来进行判断（不要用 if，lint 会报错），这样可以使函数更加通用，减少很多无用代码。上述是自己开发过程中踩的一些坑，可能这些建议不是最好的，欢迎大家讨论，或者给一些建议，让我更加快速的进步

S

进入工作一年多来，时常有一个感触就是，如何问好问题或是如何询问别人并获得自己想要的帮助。有时候请教 mentor 的时候，自己所想要问的问题是 a，而 mentor 回答的却是 b。举个小例子：我： x 哥，我想请问一下这里为什么不能这样用，这样用最后效果貌似不是想要的（会自己找答案很久，实在寻找不到才会去询问以及给 mentor 看代码，看效果，这里其实我想问的是一个技术点的疑惑，而不是代码的逻辑问题）mentor：你多仔细点，一点点排查，多打几个 log，按着代码逻辑一步步找，我知道你可以自己找到原因的。（此时，mentor 认为的是我找不到原因，而我是知道原因，但是 mt 并 get 到我的意思）。这个时候我就不得不，自己回到位置，自己继续寻找了。过了一段时间 mentor：你找到原因了吗，我：我找到了，然后我把原因啪啪一顿说（我自己搜了一些我疑惑的技术点相关的内容，以及我猜想是为啥这样的）mentor： 不对 不是这样的，然后又一顿说在这里我就有一个思考，是我的提问方式不对，还是我表达的不清晰，会出现这样的情况，其实一开始如果双方都 get 到，可能一开始就可以解决问题，而不需要再花费很多时间困在这里，大家有没有一些好的建议，可以一起交流讨论一下。