ARTS-WEEK10(23.10.16-23.10.22)

2023-10-22
上海
本文字数：3112 字
阅读完需：约 10 分钟

Algorithm 一道算法题

记忆函数：https://leetcode.cn/problems/memoize-ii/

type Fn = (...params: any) => any
function memoize(fn: Fn): Fn {    const idPool = new Map<unknown, number>()    const cache: Map<string, ReturnType<Fn>> = new Map()
    return function (...args:Parameters<Fn>): ReturnType<Fn>{        const key = args.map(getId).join(',')        const hasKey = cache.has(key)        if(hasKey) {            return cache.get(key)!        }
        const res = fn(...args)        cache.set(key,res)        return res    }
    function getId(o: unknown): number {        const hasO = idPool.has(o)        if (hasO) {            return idPool.get(o)!        }        const id = idPool.size        idPool.set(o, id)        return id    }}

复制代码

Review 读一篇英文文章

Before You Refactor

https://97-things-every-x-should-know.gitbooks.io/97-things-every-programmer-should-know/content/en/thing_06/

At some point every programmer will need to refactor existing code. But before you do so please think about the following, as this could save you and others a great deal of time (and pain):

在某个时候，每个程序员都需要重构现有的代码。但在这样做之前，请考虑以下事项，因为这可能会为您和其他人节省大量时间（和困扰）：

The best approach for restructuring starts by taking stock of the existing codebase and the tests written against that code. This will help you understand the strengths and weaknesses of the code as it currently stands, so you can ensure that you retain the strong points while avoiding the mistakes. We all think we can do better than the existing system... until we end up with something no better — or even worse — than the previous incarnation because we failed to learn from the existing system's mistakes.

对于重构，最佳的方法是首先对现有代码库和针对该代码编写的测试进行全面考察。这将帮助您了解当前代码的优点和缺点，以便在重构时保留优点并避免错误。我们都认为我们可以比现有系统做得更好...直到我们最终得到的结果没有比以前的版本更好，甚至更糟，因为我们未能从现有系统的错误中汲取教训。

Avoid the temptation to rewrite everything. It is best to reuse as much code as possible. No matter how ugly the code is, it has already been tested, reviewed, etc. Throwing away the old code — especially if it was in production — means that you are throwing away months (or years) of tested, battle-hardened code that may have had certain workarounds and bug fixes you aren't aware of. If you don't take this into account, the new code you write may end up showing the same mysterious bugs that were fixed in the old code. This will waste a lot of time, effort, and knowledge gained over the years.

不要重新编写一切。最好尽可能多地重用代码。无论代码有多难看，它已经经过了测试、审查等。丢弃旧代码，尤其是如果它已经在生产中使用，意味着您正在丢弃经过数月（甚至数年）测试和打磨的代码，这些代码可能已经包含了您不知道的某些权宜之计和错误修复。如果您不考虑这一点，您编写的新代码可能会出现与旧代码中修复的相同神秘错误，这将浪费大量时间、精力和多年积累的知识。

Many incremental changes are better than one massive change. Incremental changes allows you to gauge the impact on the system more easily through feedback, such as from tests. It is no fun to see a hundred test failures after you make a change. This can lead to frustration and pressure that can in turn result in bad decisions. A couple of test failures is easy to deal with and provides a more manageable approach.

许多渐进性的变化比一次大规模的变化更好。渐进性的变化允许您通过反馈更容易地评估对系统的影响，比如来自测试的反馈。在进行变更后看到一百个测试失败是令人不愉快的。这可能会导致沮丧和压力，进而导致糟糕的决策。一两个测试失败更容易处理，并提供了一种更可管理的方法

After each iteration, it is important to ensure that the existing tests pass. Add new tests if the existing tests are not sufficient to cover the changes you made. Do not throw away the tests from the old code without due consideration. On the surface some of these tests may not appear to be applicable to your new design, but it would be well worth the effort to dig deep down into the reasons why this particular test was added.

在每次迭代之后，确保现有的测试通过是非常重要的。如果现有测试不足以覆盖您所做的更改，那么请添加新的测试。不要轻率地丢弃旧代码的测试。表面上，其中一些测试可能看起来与新设计不相关，但深入了解为何添加了特定测试的原因将是非常值得的努力。

Personal preferences and ego shouldn't get in the way. If something isn't broken, why fix it? That the style or the structure of the code does not meet your personal preference is not a valid reason for restructuring. Thinking you could do a better job than the previous programmer is not a valid reason either.

个人偏好和自尊心不应该妨碍你的工作。如果某物没有出现问题，为什么要去修复它呢？代码的风格或结构不符合个人偏好不是重构的有效原因。认为自己可以比之前的程序员做得更好也不是有效的理由。

New technology is insufficient reason to refactor. One of the worst reasons to refactor is because the current code is way behind all the cool technology we have today, and we believe that a new language or framework can do things a lot more elegantly. Unless a cost–benefit analysis shows that a new language or framework will result in significant improvements in functionality, maintainability, or productivity, it is best to leave it as it is.

采用新技术并不是进行重构的充分理由。进行重构最糟糕的原因之一是因为当前的代码远远落后于当今的所有先进技术，我们相信新的编程语言或框架可以更加优雅地完成任务。除非成本效益分析表明新的编程语言或框架将显著改善功能、可维护性或生产力，否则最好将其保留不变。

Remember that humans make mistakes. Restructuring will not always guarantee that the new code will be better — or even as good as — the previous attempt. I have seen and been a part of several failed restructuring attempts. It wasn't pretty, but it was human.

请记住，人都会犯错。重构并不能保证新的代码总是会更好，甚至和之前的尝试一样好。我见过并参与了几次失败的重构尝试。这并不美观，但这是人性。