适用范围
此说明书用于更好地和白宦成协作。
我感兴趣且长期关注的领域
我个人关注的领域较多,但底层的核心逻辑是我关注的领域大多和个人的自我实现有关。
在此基础之上,可以细分为:
- AGI:AGI 令人惊艳。虽然能力有范围,但依然远超我个人的能力范围,我希望理解和利用 AGI ,并以此来优化我自己的执行逻辑和路径。
- Web3:Web3 作为现实中金融体系的无监管版本,对于我来说,是一个学习的好地方,并且可以和现实生活中的金融进行对比,更好地理解金融。
- 内容创作产业:帮助更多人走上内容创作的道路
- 面向中小开发者的开发者服务:帮助更多的人可以开发出自己的产品
- 自动化工具:解放生产力,让每个人可以去做自己想做的事情。
我会长时间关注上述领域,如果你和我沟通上述领域的内容,我会非常高兴和你详细聊一聊。
今年重点项目
- 基于 AGI 的播客 SaaS 产品:AGI 的出现,让独立开发者可以更加的强大,对于我来说,也是让我可以更好的做到我自己想做的事情。所以,Just Do IT。
- 自己的写作项目:写作是我的终身职业,所以我会持续,且一直投入时间和精力在我自己的写作项目上。
我的性格特质
我的 MBTI 类型:INTJ
我的排名前10位的盖洛普优势才干为:理念、专注、行动、沟通、完美、搜集、积极、分析、关联、取悦。
我是什么样的人
我既可以与人沟通,也可以与自己沟通,且我大部分时间都与自己沟通。如果我们见面沟通,那么,我会希望你我可以有不一样的观点可以分享。
初次见面聊什么好?
我很喜欢和别人聊一些不一样的体验。如果是第一次见面,不妨聊一聊最近看的书,最近去过的地方,我都很有兴趣听你分享你的故事。
喜欢的合作伙伴
- 比起同步沟通更喜欢异步沟通的人
- 比起语音更喜欢文字的人
- 有逻辑有条理的人
- 不拖欠款项(特殊情况除外)
工作/学习偏好
- 习惯深夜工作/学习
- 习惯在安静的地方工作,或者自带白噪音的环境
- 不喜欢在家工作(写代码时除外,因为需要双屏)
我喜欢的沟通模式
对于细节问题,我会更倾向异步的沟通方式,你可以将问题的细节整理好,发送邮件给我,我在看到邮件后会和你具体的沟通。
对于宏观问题,我会更倾向同步的沟通方式,我们可以在这种同步的沟通方式中,探索出新的可能。
喜欢的办公场所
- 咖啡馆:小众咖啡厅最佳,在背景音下工作体验非常好。
- 书店:聊完可以一起逛一下书店,带两本喜欢的书回去。
活跃时间
- 9:00 AM ~ 12:00AM:读书时间,勿扰。
- 2:00 PM ~ 9:00PM:阅读互联网信息/查收邮件,可联系。
- 9:00 PM ~ 11:00PM: 读书时间,勿扰。
Base 地
天津市
不喜欢什么样的人
- 不尊重专业的人:既然不尊重专业,那何须来找我呢?
- 抗拒将问题细节化的人:细节意味着上下文,只有充足的上下文,我们才能更好的将任务
如何付费
- 我的咨询报价为 $1000/h(折合人民币约 6,885.70 元/小时).
- 开始咨询,你需要支付至少 1 小时的费用;实际费用按照小时为单位进行结算。
- 咨询时长按照向上取整计算。
你和我沟通过程中可能会遇到的问题?
某条消息很久没有回你不一定是因为我不想回,很有可能是我没注意。现在看书比较多,所以看微信相对就会少一些。不妨再 Ping 我一次。
其他
如果你看了上述信息,仍然认为有必要与我建立联系,达成沟通,那么你可以扫描下方二维码和我取得联系。
大部分中国人是没有信仰的。
你可能会问,中国人不是也去寺庙去拜佛,也到教堂去做礼拜。为什么说中国人没有信仰呢?
在维基百科中,对于信仰的定义是“人事物或概念的坚定信念或信任。”,但对于那些去寺庙拜佛、去教堂礼拜的人来说,他们可能并不坚定的认为这些“神”的存在的,他们关注的也不是自己对于“神”的信仰,而是关注神到底能为自己解决多少问题?
这也是为什么我们发现,财神庙总是香火最旺。
在对外开放 OpenAPI 的时候,错误的设计也是一个极为影响开发者开发体验的设计点。今天我们简单聊聊关于错误码和错误处理
为什么需要错误码?
由于我们不能保证系统可以完全处理用户的请求,因此我们需要通过错误码来告诉开发者发生了不符合预期的情况。不符合预期的情况可能由用户输入错误导致,也可能由内部微服务故障导致。为了建设一个健壮(Robust)的系统,我们需要通过对外暴露一批错误码,帮助开发者更好地处理各种异常情况。
避免错误码数量过少
既然我们的目的是帮助开发者解决异常情况,那么一个合理的答案是:和异常情况匹配的错误码数量是一个好的错误码数量。
如果在某个 API 接口上提供了一个错误码,则意味着我们认为这个接口只会出现一种情况导致的错误。而实际上,很可能会有多种情况导致错误发生。这种情况经常在 OpenAPI 评审过程中被提出来,也是用户在使用 OpenAPI 时常遇到的问题:为什么我找不到这个错误码?对于开发者来说,无论输入何种错误,都会得到相同的错误码,难以定位和解决问题。同一个错误码也意味着你无法提供足够的错误信息来进行排查。例如,常见的 “400 Bad Request” 错误,如果参数很多,排查错误可能是一个极其痛苦的过程。
避免错误码数量过多
另一方面,错误码数量过多也会导致问题。有些 OpenAPI 接口提供了几十个不同的错误码,看起来感觉很不错。但是仔细一看,就会发现这些错误码实际上只是针对不同的字段错误而已,导致错误码数量快速增长。而实际上,可以将参数错误放在同一个错误码中,并通过动态的参数和原因来解决,而不是返回一堆类似的错误码。大量的错误码对于开发者来说,存在记忆困难的问题,在实际编写代码的过程中,也需要编写大量的错误处理逻辑,来兼容我们对外抛出的错误处理逻辑。
换一种思路来组织错误码
如果你无法很好的掌握拆分和组织错误码的粒度,那我可以给你一个建议:按照用户处理错误的手段来拆分错误码。过去从内部视角来组织和错误码,很容易出现错误码过多或过少的情况,而从外部视角来梳理错误码,则可以帮助我们更好的厘清错误码的分类和组织。
用户并不关注我们的系统到底因为什么出现了错误,他们只关心出现了什么样的错误?我应该如何处理这些错误?那错误码可以非常快速的收敛为以下几类:
- 本资源参数校验错误,对应的处理策略往往是开发者需要查看文档,了解资源参数的限制, 修改参数重新调用。
- 跨资源参数校验错误,对应的处理策略往往是开发者需要通过其他 API 获取关连资源的 ID 等信息,以便于重新调用。
- 请求频率太高,对应的处理策略是优化调用的接口和方法,调低并发量。
- 服务端错误,对应的处理策略是重试,并在重试无效时联系官方人员。
通过上述的分类方式,我们可以快速的将错误码归类到几个大的分类,从而实现合并同类项,收敛错误码但不至于让开发者不知道下一步 Action 的情况。
错误码不重要,错误处理才重要
看到这里,相信你对于文章中提出的什么才是好的错误码设计已经有了答案。但我想说的是,错误码从来都不是核心。实际上,如果我们回看各种编程语言的范式,大多没有错误码这种设计,而是选择将更多的信息通过 exception 这样的形式暴露给开发者。错误码的设计虽然给到开发者一个可以用来做唯一判定的数据,但可以做唯一判定的不一定非要是数字。数字错误码的设计严格来说,并不是一个好的设计,因为他使得你的代码中必然会存在某些特定的 Magic Number,你需要小心的维护这些 Magic Number 来确保向开发者返回错误时不至于返回错误的错误类型和错误码。
对于一个已经存在的 OpenAPI 系统来说,错误码已经成为既定事实,则要做的是让这套系统可以更好的运转下来。但如果你要设计一套全新的错误系统,那么类似 Slack 这样的返回形式,可能是一个更好的选择,既可以规避掉 Magic Number 的问题,又可以确保每一个错误有其对应唯一的枚举值。
总结
好的错误码设计是适度的,你需要学会平衡错误码和对应错误信息的数量,不要太多干扰开发者,但也不可太少,不足以支撑实际的接口调用。好的错误码可以帮助我们和开发者建设更加健壮的系统,减少不必要的沟通成本,也可以让我们每一个使用这个 API 的人,都更加的幸福。
最近在写 LCTT 译文的解析工具,写正则、调试正则的过程非常的痛苦。
比如,下面的这个正则表达式就是我用来提取文章的英文标题的正则。由于 LCTT 的文章元信息存储历史上出现过多次,所以我不得不写一个比较复杂的正则来匹配出想要的结果。
比如,下面的这段代码是我用来从文件路径当中提取出不同内容的正则,看起来十分复杂,对吧?
/(?<collectDate>(?<type>(?<path>\.\/)(?:published))\/(?<yearOrSeries>(?:.+)?)\/(?<month>(?<=\d+)\.(?=\d+))?)(?:⭐️|⭐️⭐️)?(?<title>.+)\.md/
相比于看起来复杂,更加麻烦的是可维护性。正则表达式的可维护性相比于正常我们熟悉的编程语言来说,是差了一大截。基本上如果要对上述这段正则表达式进行修改或者二次开发,难度极高。但借助一些工具,我们可以使用类似 DSL 的方式来管理正则表达式,则可以以一个更友好的方式来维护你的正则表达式。
比如,以我为例,上面这张图片中的定义,便是上方正则的等价替换。虽然写了更多的代码,但确实可读性、易于理解性和易于维护性,有了显著的提升。
想要使用,也不复杂,只需要使用对应的 DSL 语法来完成定义,即可完成正则表达式的构建。以我上面的这段正则为例,我使用的是 javascript 的 magic-regexp
包,实际使用时,大概是这样的,定义出对应的正则,直接基于其进行匹配即可。
const magicRegxp = require('magic-regexp');
const { createRegExp, exactly, oneOrMore, char, anyOf, carriageReturn, global, multiline, linefeed, maybe, digit } = magicRegxp;
const regExp = createRegExp(
exactly("./").groupedAs("path")
.and(anyOf("published")).groupedAs("type")
.and(exactly("/"))
.and(maybe(oneOrMore(char)).groupedAs("yearOrSeries"))
.and(exactly("/"))
.and(maybe(
exactly(".").after(oneOrMore(digit)).before(oneOrMore(digit)).groupedAs("month")
)).as("collectDate")
.and(maybe(
exactly("⭐️").or(exactly("⭐️⭐️"))
))
.and(exactly(oneOrMore(char)).groupedAs("title"))
.and(exactly(".md")
));
let result = regExp.exec(file_content);
console.log(result.groups.title);
当然,这样的维护方式,在不同的语言下有着类似的实现,如果你使用 Golang ,那么 Rex,也是一个不错的选择。
这个工具是我在研究别人的的 Notion 工作流时发现的,一个支持从网页中提取核心数据的 Notion Saver 插件 —— Save To Notion(官网)
和绝大多数 Notion Saver 类似,Save To Notion 也支持直接存储一个书签到 Notion 当中,对于平时需要大量阅读的人来说,这是一个和其他产品无法形成差异化的 Feature。
但 Save To Notion 一个非常厉害的功能,是你可以在你的保存表单中,设置从网页中提取数据,它应该是采用了 XPath 来实现这个 Feature,你可以根据自己的需求,从页面中选择数据来提取,从而可以基于 Notion 完全实现一套自己的数据库。相比于其他 Saver,多了一步解析数据的能力,而这个能力,可以帮助你节约许多的时间。
Just Use IT!