ARTS-week7(23.9.25-23.9.30)

2023-09-28
上海
本文字数：3651 字
阅读完需：约 12 分钟

Algorithm 一道算法题

检查是否是类的对象实例 https://leetcode.cn/problems/check-if-object-instance-of-class/

function checkIfInstanceOf(obj: any, classFunction: any): boolean {    if (obj === null || obj === undefined || !(classFunction instanceof Function))        return false;    return Object(obj) instanceof classFunction;};

复制代码

Review 读一篇英文文章

Ask "What Would the User Do"(You Are Not the User)

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

We all tend to assume that other people think like us. But they don't. Psychologists call this the false consensus bias. When people think or act differently to us, we're quite likely to label them (subconsciously) as defective in some way.

我们往往倾向于假设其他人与我们思考方式相同，但实际上并非如此。心理学家将此现象称为"假一致性偏见"。当人们的思维或行为与我们不同的时候，我们很可能会（潜意识地）将他们标记为某种方式上的有缺陷。

This bias explains why programmers have such a hard time putting themselves in the users' position. Users don't think like programmers. For a start, they spend much less time using computers. They neither know nor care how a computer works. This means they can't draw on any of the battery of problem-solving techniques so familiar to programmers. They don't recognize the patterns and cues programmers use to work with, through, and around an interface.

这种偏见解释了为什么程序员很难站在用户的角度来思考。用户的思维方式与程序员不同。首先，他们使用计算机的时间要少得多。他们既不了解也不关心计算机的工作原理。这意味着他们无法运用程序员熟悉的各种问题解决技巧。他们无法识别程序员用于处理界面的模式和提示。

The best way to find out how users think is to watch one. Ask a user to complete a task using a similar piece of software to what you're developing. Make sure the task is a real one: "Add up a column of numbers" is OK; "Calculate your expenses for the last month" is better. Avoid tasks that are too specific, such as "Can you select these spreadsheet cells and enter a SUM formula below?" — there's a big clue in that question. Get the user to talk through his or her progress. Don't interrupt. Don't try to help. Keep asking yourself "Why is he doing that?" and "Why is she not doing that?"

了解用户思考方式的最佳方法是观察一个用户。请一个用户使用与您正在开发的类似软件的类似任务。确保任务是真实的："将一列数字相加" 可以，"计算上个月的开支" 更好。避免过于具体的任务，比如 "你能选择这些电子表格单元格并在下面输入一个 SUM 公式吗？" — 这个问题中有一个很大的提示。让用户详细讲解他或她的进展。不要打断。不要试图提供帮助。不断问自己 "他为什么这样做？" 和 "她为什么不这样做？"

The first thing you'll notice is that users do a core of things similarly. They try to complete tasks in the same order — and they make the same mistakes in the same places. You should design around that core behavior. This is different from design meetings, where people tend to be listened to for saying "What if the user wants to...?" This leads to elaborate features and confusion over what users want. Watching users eliminates this confusion.

您将首先注意到的是，用户在核心行为上做事情的方式相似。他们尝试以相同的顺序完成任务 — 并且他们在相同的地方犯相同的错误。您应该围绕这种核心行为进行设计。这与设计会议不同，在设计会议中，人们倾向于说 "用户可能想要..." 这会导致复杂的功能和关于用户需求的混淆。观察用户可以消除这种混淆。

You'll see users getting stuck. When you get stuck, you look around. When users get stuck, they narrow their focus. It becomes harder for them to see solutions elsewhere on the screen. It's one reason why help text is a poor solution to poor user interface design. If you must have instructions or help text, make sure to locate it right next to your problem areas. A user's narrow focus of attention is why tool tips are more useful than help menus.

您会看到用户陷入困境。当您陷入困境时，您会四处张望。当用户陷入困境时，他们的注意力会变得更狭窄。他们很难在屏幕的其他地方找到解决方案。这是为什么帮助文本对于差劲的用户界面设计是一个不好的解决方案的一个原因。如果您必须提供说明或帮助文本，请确保将其放置在问题区域的旁边。用户的狭窄注意力是为什么工具提示比帮助菜单更有用的原因之一。

Users tend to muddle through. They'll find a way that works and stick with it no matter how convoluted. It's better to provide one really obvious way of doing things than two or three shortcuts. You'll also find that there's a gap between what users say they want and what they actually do. That's worrying as the normal way of gathering user requirements is to ask them. It's why the best way to capture requirements is to watch users. Spending an hour watching users is more informative than spending a day guessing what they want.

用户倾向于摸索着前进。他们会找到一种有效的方法，然后坚持使用，不管多么复杂。提供一种非常明显的做事方式要比提供两种或三种快捷方式更好。您还会发现用户所说的他们想要的和他们实际做的之间存在差距。这令人担忧，因为收集用户需求的常规方法是向他们询问。这就是为什么捕捉需求的最佳方法是观察用户，而不是花一整天来猜测他们想要什么。

Technique/Tips 分享一个小技术

Promise-异步编程

js 异步解决方案中 Promise 中，当 Promise 进入 rejected 状态时，如果错误没有被正确的捕获，会抛到全局及浏览器全局或 Node 全局。
执行 then 和 catch 会返回一个新 Promise，该 Promise 最终状态根据 then 和 catch 的回调函数的执行结果决定

• 如果回调函数最终是 throw，该 Promise 是 rejected 状态

• 如果回调函数最终是 return，该 Promise 是 resolved 状态

• 但如果回调函数最终 return 了一个 Promise ，该 Promise 会和回调函数 return 的 Promise 状态保持一致。

先看第一个问题：

js 异步解决方案中 Promise 中，当 Promise 进入 rejected 状态时，如果错误没有被正确的捕获，会抛到全局及浏览器全局或 Node 全局。

(function(){    const promise = new Promise((resolve, reject) => {        setTimeout(function () {            // resolve(3);            reject(new Error(4))        }, 500)    })    promise    .then(function (result) {        console.log(result)    })    setTimeout(() => {        console.log(promise)    }, 800)    })()

复制代码

浏览器中：

所以要正确的捕捉错误。

(function(){    const promise = new Promise((resolve, reject) => {        setTimeout(function () {            // resolve(3);            reject(new Error(4))        }, 500)    })    promise    .then(function (result) {        console.log(result)    })    .then(()=>{        reject(new Error(3))    })  	.catch(err=>{      console.log('err',err)    })    setTimeout(() => {        console.log(promise)    }, 800)    })()

复制代码

那么问题来了，俩个 error 啊，怎么就打印了第一个错误呢？

原因是 Promis 中 catch 只会捕捉到链式调用中的第一个错误。

在看看第二个结论即

执行 then 和 catch 会返回一个新 Promise，该 Promise 最终状态根据 then 和

catch 的回调函数的执行结果决定

• 如果回调函数最终是 throw，该 Promise 是 rejected 状态

• 如果回调函数最终是 return，该 Promise 是 resolved 状态

• 但如果回调函数最终 return 了一个 Promise ，该 Promise 会和回调函数 return 的

Promise 状态保持一致

(function(){    const promise = new Promise((resolve, reject) => {        setTimeout(function () {            reject(new Error(4))        }, 500)    })  const promise2 = promise.catch(()=> {    // return 2   throw new Error('error')  }) setTimeout(()=>{    console.log('promise2',promise2) },500)})()