karloku

好处是让接口更有稳定性.

用了 getter/setter, 日后无论你怎么改里面的实现方式, 只要保持行为一致, 使用者都不需要更新自己的代码. 如果直接 obj.value 的话, 日后如果要更改内部实现逻辑, 下游用着要炸.

有性能需求的话在采购时把性能指标提好(页面加载时间, QPS 之类的), 然后根据需求把价格谈好. 没有提出性能需求那就是只要能用, 只管实现功能.

看中间那层是谁开发的. 前端开发的就是 BFF, 其他人开发 /维护的就是 gateway

@fuxkcsdn 自托管的 gitlab 社区版和企业购买 gitlab 企业版不冲突. 社区版的参与度高了对于企业版来说反而可以得到更多的代码反哺. 这是大部分 foss 项目基金会商业运作的模式, 通过放置在上游的社区版蹭社区的开发力量, 然后利用企业版的授权和支持来赚钱.

当然如果用户最后选择涌进 gitlab.com, 把这个官方的托管平台变成下一个 github.com, 那只能说用户咎由自取.

@patrickyoung 原文提到了. 既然公司宣称拥抱 FOSS, 就应该提供完全 FOSS 可自托管的代码库.
商业公司赚钱无可厚非, 一边打情怀假装自己拥抱 FOSS, 一边又是只提供基于完全闭源代码版本的中心托管平台.

现在的微软特别喜欢一边说着拥抱开源热爱社区, 一边建立自己一言堂的社区规则方便商业化整个社区的贡献.

作为其他语言用户确实困扰了
但是按 10 是 number 的一个子类大概理解一下觉得这个才直觉. 宽引用转换到窄必须显式转换并且最好有相应的异常处理. 不然谁能保证 x: number 一定是符合 10 的

丢失 collection 不至于.
就算古早的 mongodb 会丢数据, 但那也是 2.0 以前的默认配置下, 写入数据不需要 ack 时期的事情了.

venv 最有安全感, 配合 dotenv 一起用也没什么不便利的地方

如果优化不了条件的话, 可以设计成能提前进行 return/continue/break 的执行方式

当然最好是想办法优化一下判断条件, 这么长的判断式可读性很差