hackape 最近的时间轴更新
hackape

hackape

V2EX 第 93095 号会员,加入于 2015-01-22 13:47:43 +08:00
hackape 最近回复了
JS/TS 全栈确实是个大趋势,前后端通吃,是个性价比非常高的路径,可以说是现在年轻创业公司的技术栈首选。加上云原生厂商如 cloudflare, vercel 也都把科技树点在 JS 上,前景看好。
属于事物的一般发展规律了。相关阅读推荐: https://blog.visionarycto.com/p/my-20-year-career-is-technical-debt
2022-07-03 19:57:55 +08:00
回复了 fpure 创建的主题 程序员 这算不算是静态类型系统的缺憾
有可行性,但只会在有限范围内。TS 的类型收窄,就是静态分析器有限度的做了一点运行时的工作:a) 读懂 if condition; b) 收窄的有效期需要跟踪变量是否在判断后没有改变。类似的,rust 的 lifetime 检查其实也是部分在做运行时的一些 context sensitive 的工作。

所以现在的问题就是,你愿意付出多大的代价维护这个 context ?从实用角度讲,你肯定不能要求静态分析器去追求运行时等效,那性能就没法保障。

咱还拿 TS 类型收窄举例

```ts
if (x === 10) {
x = 10
f(x)
}
```

加上 `x = 10` 就会报错,说明 TS 的实现逻辑就是,老子刚检查完你别动这变量啊,动了我就不保证了。那你说它读的懂 `x === 10` 能不懂 `x = 10` 吗?肯定不能啊,只是它选择不去懂。

思考一下 OP 想要的功能怎么实现,就是要求静态检查器跟踪变量的运行时赋值,除了检查 assignability 还要把 literal value 挨个记住。形如下例会付出多大代价呢:

```
x = 1
f1(x)

x = 2
f2(x)

x = 3
f3(x)
```

考虑性能,backtrace 大概率不会用因为慢,那就用 cache ,赋值几次 cache 几次,就算不考虑循环,赋值这么频繁出现的操作,内存肯定要爆炸。综上,我认为是有理论可行性的,但不经济。

反观类型收窄,是进入 if block 的时候才启用,并且只 cache 一个值,干净又卫生,所以就实现了。
2022-06-10 13:20:45 +08:00
回复了 shaoyaoju 创建的主题 程序员 我与 Apache 软件基金会的故事
请忽略柠檬精们的发言,你做的事情非常棒!维护过大项目的人都知道,核心技术有多牛逼真不是项目成功的重要标准,最终要的是日复一日的坚持,持续不断的维护打磨各方面的细节。commit chart 初始的几座山仅仅是开始,让项目成功的是后面那条长长的尾巴,以及数量不断增加的 contributors 。长期做好这件事本身比一周肝一万行代码难的多。
2021-02-23 13:38:17 +08:00
回复了 sugarkeek 创建的主题 git git 两个分支合并的时候,如何保证代码运行正常?
这事儿的本质跟 git 没有任何关系。

即便是不分叉、线性地去开发,想象一下张三开发 A 模块,改了通用服务 C,提交完了,然后李四接着开发 B 模块,然后也改了服务 C 。你看这里面没有分叉再合并、产生冲突的过程,但也不能保证李四改完了的 C 就完全不出问题,除非李四充分理解自己的改动,这包括他需要去看张三的那部分代码。

合并出现冲突,本质上面对的问题还是两个人分别改了同个东西如何保证不出错,要么是李四解决冲突的时候好好读代码,要么把张三叫过来,大家一起 review 一下。

再退一步讲,哪怕只有张三一个人写东西,照样不能保证不出错,相信大家都有过看不懂自己的老代码的经验。

所以说这事儿跟 git 没有半毛钱关系,而你说的问题,别的楼层提到的 CI/CD, TDD 都是有效的方法(如果不流于形式、好好执行的话),然而还是那句话 there's no silver bullet,这个话题没有最终答案的。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2831 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 22ms · UTC 13:17 · PVG 21:17 · LAX 06:17 · JFK 09:17
Developed with CodeLauncher
♥ Do have faith in what you're doing.