hackape 最近的时间轴更新 hackape 最近的时间轴更新 |
hackapeV2EX 第 93095 号会员，加入于 2015-01-22 13:47:43 +08:00 |
hackape 最近回复了
2023-08-28 11:35:14 +08:00 回复了 AndyChina 创建的主题 › 职场话题 › 外卷思路讨论, 转换技术栈, 英语+TS 全栈 可行性如何, 想听听大家的看法 |
JS/TS 全栈确实是个大趋势，前后端通吃，是个性价比非常高的路径，可以说是现在年轻创业公司的技术栈首选。加上云原生厂商如 cloudflare, vercel 也都把科技树点在 JS 上，前景看好。
2023-08-24 23:35:48 +08:00 回复了 zhangolve 创建的主题 › 程序员 › 我们程序员写的代码做的产品，绝大多数都是失败产品 |
属于事物的一般发展规律了。相关阅读推荐： 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 一个值，干净又卫生，所以就实现了。
所以现在的问题就是，你愿意付出多大的代价维护这个 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，这个话题没有最终答案的。
即便是不分叉、线性地去开发，想象一下张三开发 A 模块，改了通用服务 C，提交完了，然后李四接着开发 B 模块，然后也改了服务 C 。你看这里面没有分叉再合并、产生冲突的过程，但也不能保证李四改完了的 C 就完全不出问题，除非李四充分理解自己的改动，这包括他需要去看张三的那部分代码。
合并出现冲突，本质上面对的问题还是两个人分别改了同个东西如何保证不出错，要么是李四解决冲突的时候好好读代码，要么把张三叫过来，大家一起 review 一下。
再退一步讲，哪怕只有张三一个人写东西，照样不能保证不出错，相信大家都有过看不懂自己的老代码的经验。
所以说这事儿跟 git 没有半毛钱关系，而你说的问题，别的楼层提到的 CI/CD, TDD 都是有效的方法（如果不流于形式、好好执行的话），然而还是那句话 there's no silver bullet，这个话题没有最终答案的。
Select Language