我老婆最一年也在教一些计算机课程（单片机，深度学习等）
她问我该让学生们看什么自学，我就只推荐了 CS61A ，B 站有搬运（ https://www.bilibili.com/video/BV16W411W76H ）
如果能把基础课程啃完的话，这些应用技术应该是最后临找工作前 3 个月随便刷刷就够了。毕竟离开了学校就再也没有环境能让学生们静下心来学基础，做理论题了

不，这是编程范式的问题，不是 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 ......

我司项目，大约 20 多人开发规模
mysql: 同事在用，我用 pg
redis: 同事在用，我基本上内存里做缓存了
nginx: 作为 k8s ingress 在用，前端也在用它做静态托管
es: 推荐系统组在用，不懂这玩意儿
mq: 听说过没用过
docker + k8s: 这套是我搭建的
rpc + protobuf: 在用，内部通信和对外接口都有暴露 grpc 端口
session + cookie: 前端项目谁离得开它？
jwt: 多好的签名算法


除了上面的这些，我还在用
cassandra
knative(serving & eventing) + istio
open telemetry
grafana + prometheus
kafka
graph database
其他想不起来了

我讲个故事：
2012 年刚参加工作的时候，我入职了一家对日外包软件开发公司，技术栈是 .NET 。公司里有两位前辈与故事有关，老宋和李哥：老宋在这家公司干了十几年，业务熟手；李哥则是技术非常强，业务理解不算差。而当时我的 leader （老宋）曾不止一次跟我强调：“技术是有上限的，技术做到一定程度还是要转向业务，对业务理解越深，职业发展越顺”。大意如此，我不敢说一字不差的背下来，只传达核心思想。

2013 年，公司从日本回来一位同事胖子，公司给他定的薪资有 15k ，是老宋和李哥的 2.5 倍有余。得知这个消息的老宋和李哥一个星期天天往老板办公室跑，谈涨薪，无果。

一周后，技术强的李哥面试了一家银行软件开发，并收到 offer 。
而老宋，看着他拿起一本 Java SSH 网站开发的书翻几页，越看越无奈，又合上书看看我们，又翻开书再看几页，如此循环了一会儿，对我们说：“我真羡慕你们还年轻，学得进去。我这个年纪已经学不进去了”


我的观点：
极端点说，如果你的业务是银行财务相关，或者数学 /物理计算模拟软件。业务背后有经济规律 /法律甚至数学物理定律撑腰，那我觉得业务可能更重要一些。

如果你的业务是互联网 CRUD ，其中步骤来自老板 /产品经理朝令夕改的脑洞。或者你们只是在研究如何骗用户点你们平台的广告，那我并不觉得这类业务有什么值得深入的。

@shilianmlxg 没有，但是 JS 作为披着 C 外皮的 Scheme ，你熟悉 JS 的前提下，直接看 Scheme 版 SICP 不是什么难事。7 年前我就是这么看的，当时我只是个卑微的前端。

@JarvenI 看 Python 版 <SICP> 入门其实没什么问题，也更有实用价值，不用非得追求 scheme 版，但课后题一定要全刷，只有刷完最后一道课后题才能真正理解 <SICP> 在讲什么，空看是没有用的

中文确实有进阶路线，机械工业出版社的黑皮砖头书就是进阶路线。
远离极客时间，知识星球，等一切知(割)识(韭)付(菜)费平台。打开学堂在线，离散数学 /组合数学学起来，操作系统 /算法学起来，唯有正襟危坐扎扎实实的上课 /做题，别无他法

emmmmm
<SICP> 被誉为神书正是因为他讲的是基础啊，是“编码”这件事的本质。程序的求值模型是怎样的，如何构造惰性 /无穷列表，以及如何自己实现解释器

我看的是 Scheme 原版 + MIT 翻译的视频，至今只看了前三章。效果显著，薪资翻了十倍，对于我一个带专来说已经是很翻身了

@daimubai Point-free style ？

当然如果你 C++ 代码没有涉及系统调用，就是纯计算的话，还可以迁移到 WASM 实现上去，就不用操心 arch / os 兼容问题了。

如果生产环境 arch / os 和你本地不一样，甚至 node / v8 版本不一样，最后生成的 addon 都是不兼容的，搞交叉编译不如 docker 发布。

docker 多阶段构建
一阶段构建环境，装 node gcc 等 devel ，编译出 addon 来。如果有 webpack / vite 任务也应当在这个阶段执行。
二阶段运行环境，把一阶段生成的文件拷贝进来，作为最终镜像

最后去生产环境 pull 下来 docker run

@FFFFourwood 咱公司叫啥名？😊

在用，copilot 真是太强大了，基本上 >50% 能猜中我的意图

开发方向和使用技术当然让我成就感满满，毕竟能写 Scala 纯函数式我还是很开心的。

但是做的项目没什么亮点，都是些定制 CRUD ，而且我本人也完全不相信所谓的 low/no code 。对我来说需求方就像癌症晚期的病人，而 low/no code 不过是又一个江湖骗子，需求方病急乱投医，幻想 low/no code 可以根治自己的顽疾，不过是梦幻泡影。

总结：
1. 接到复杂需求后,应该如何进行需求分析和功能拆解呢
2. 可以用哪些工具来辅助自己更高效的分析业务逻辑呢
3. 编写代码前,可以做哪些工作,能够来帮助提高编码效率呢
4. 如何避免写出屎山代码呢

答：
1/2/3: 面向类型建模
4: 常修常新，不要惧怕重构底层

和楼主差不多的工作内容，我是写 Scala 业务系统搬砖的，初创公司业务方向经常变来变去，还经常需要舔甲方爸爸做定制需求。

我的方式是面向类型建模，因为 Scala 里有 ADT 这些 Sum type 类型，我可以把业务流程和状态编码到 Scala 的类型中，包括中间数据状态。同时还可以借助 Either / Option 这些内置类型抽象，做 Railway Oriented Programming
https://fsharpforfunandprofit.com/rop/。Scala 编译器能辅助我避免掉 50% 以上的 Bug ，剩下的 Bug 很大一部分是产品经理自己都没想清楚，和过去的功能冲突了。只有很小一部分是一些运行时错综复杂的问题。

同时尽量将系统核心部分稳定下来，新需求（特别是那些听上去就很扯的）往新的文件夹 /子项目里实现，哪天这个客户不做了（这块逻辑不要了）直接整体移除掉，对主线功能没有影响。

其实避免屎山我觉得很重要的一点是，常维护，不要惧怕修改重构。在做新需求的时候，不可避免的会对老代码有些许修改，这就是重构的最佳时间。我曾花了 2-3 个月时间把整个系统的异步模型迁移到另一个框架上，这期间代码质量得到了很大提升，CPU 占用率也降低到原来的几十分之一。

我也用 compose-jb 写过跨平台桌面程序。讲道理，体验真不错，写出了 React + Scala 的感觉。