你会因为 IDE 无法分析和跳转函数的所有调用点而烦恼吗？

[jaggle]

比如，RPC 服务，有时候 IDE 可能无法知道某个函数是一个远程接口的调用点；

再比如，反射出来的的类，IDE 很难通过文本知道，某个变量是什么对象；

再比如，很多项目都有依赖注入、门面、工厂的概念，这些概念可以让你的写的代码更优秀，但是让你改代码时，往往牵一发而动全身；

更甚至，执行字符串 eval('print("hello")') 。

这些无法跳转的函数调用常常会给程序员带来很多烦恼，程序员需要写很多 annotation 去告诉 IDE ，或者在 docblock 中说，嗨，老李，这个函数在某某文件的某行被调用啦，修改前记得看看对那边有没有影响！

所以，人工智能时代的 IDE ，会为程序员解决这个烦恼吗？

[lmshl]

不，这是编程范式的问题，不是 AI 问题

比如，RPC 服务，有时候 IDE 可能无法知道某个函数是一个远程接口的调用点；
-- 像 algebric effect / zio / tagless final 等范式，会给这类函数两个标记，`IO` 和 `Effect`，比如一个 `Repository[F].getX() -> F[Result]` 中，Repository 就是依赖的 Env ，F 就是 `IO`。Rust 的 async/await 也会对远程接口做一个基本修饰。

再比如，反射出来的的类，IDE 很难通过文本知道，某个变量是什么对象；
-- 像 Scala / Rust 等现代编程语言，编译器足够强大，类型信息都可以在编译期生成完备，没必要拖到运行时给黑客留那么多注入空间。

再比如，很多项目都有依赖注入、门面、工厂的概念，这些概念可以让你的写的代码更优秀，但是让你改代码时，往往牵一发而动全身；
-- 还是 Scala ，注入可以在编译期解决。再配合完备的类型系统，可以帮助程序员将 90% 运行时错误在编译期发现。

更甚至，执行字符串 eval('print("hello")') 。
-- 编译器越强大，需要手动 `eval` 的场景就会越来越少

这些无法跳转的函数调用常常会给程序员带来很多烦恼，程序员需要写很多 annotation 去告诉 IDE ，或者在 docblock 中说，嗨，老李，这个函数在某某文件的某行被调用啦，修改前记得看看对那边有没有影响！
-- 将这些信息编码到类型中，下次编译的时候，编译器会提醒你还需要注意修改哪里

所以，人工智能时代的 IDE ，会为程序员解决这个烦恼吗？
-- 所以，你需要的是用现代化编程语言配合现代化编程范式，Scala / Rust / Kotlin ......

[documentzhangx66]

正因为您能够：

1.发现这个问题。

2.解决这个问题。

3.把这个问题的解决方案做成一键模板，能让你自己或别人，快速配置来实现这个功能。

这就是为什么你比别人价值高，也是你收入能比别人高的原因之一。