你说的症状很可能是 navicat 自己的问题。我建议用代码试试看。读一下返回的错误提示就大概能明白是怎么回事了。

你这不像是长度受限...能把错误提示贴出来看一下不？

读，这不是个问题

建议读 PhD，但是现在 PhD 这么容易读了吗？

你这个情况不要回国了。你的技术栈跟互联网基本没什么关系。
我建议你静下心来研究一下现有的技术，看看能不能从互联网行业学到一点什么，应用到你目前的工作中。
德国企业还是比较舒服的，如果你真的到了国内的互联网企业，估计会很难受。

正则表达式其实是提供给程序用的东西，并不是给人读的。
因此让你写你当然痛苦，写出一串正则表达式，跟你按照相同的逻辑写一大堆 if-else 消耗的精力是完全一致的。
只是读你自己写的结果，更加痛苦......
但是程序员不就是干这个的么？

翻译成缺陷更好一点。总觉得更正式......
错误也行，但是觉得太口语化，写到文档里不太合适。

我知道模板这个概念，大约是 3 年前的事情。
最早我写代码是大约 15 年之前了。那个时候我是一个网站的 ASP 程序员。我记得步骤如下：
1. 连接数据库(可以共享代码)，所有的页面用同样的数据库连接代码
2. 拼接 SQL
3. 执行 SQL
4. 拼接 HTML 字符流。
上面的所有步骤我记得都是用 VB 脚本完成的。当时一个页面文件里的代码分成 2 个部分，一个部分是 VB script，这部分在服务器端执行，另外一部分则是 HTML 和 Jscript，则在客户端执行。但是这两部分代码可以用<%%>一起混用，于是导致的后果就是自己写的代码，过 2 周再回去看的时候，弄不清楚某一行到底是 VB 还是 HTML....一定要在脑子里把程序过一遍。
后来.net 出现了，我当时的感觉简直就是一个新天地，虽然没实际用于生产环境，但是确实引入了很多新的概念。
再后来我作为 BA 开始了解 JSP，当时的想法就是:这和 ASP 没啥差异，就是把 VB 换成 Java 而已。
其实代码架构的演化，这些年一直都是在为程序员服务，主要目标是提高代码复用程度，减少单个文件的复杂度。但是带来的后果就是整个项目的文件结构复杂度是在增加的。现在的 Flask 或者 Django 那样的框架，对于项目文件结构的要求其实比以前是提高了。

没区别，Web 后端通常没有 APP 分离得那么彻底，例如之前会有人在 V2 问到底该不该返回 HTML 字符流给前端程序之类的。这种问题很难出现在 APP 上

1000 万行的意思是一天 3 万行代码....
这...远远超过了前段时间统计的 100~150 行 /天的平均水平。

cousera 的 machine learning 课程非常好，但是确实需要一点数学基础。不过如果楼主以前的数学名词没忘光,应该能看懂。

这个其实就是测试用例，经验指的就是这种事情。
除非有一天我们可以用程序本身来写程序，否则就要依赖于这种失败->修正的循环过程来提高稳定性

你这是供应链还是区块链....

我建议建在昆明比较好....南宁没什么值得一提的优势。
昆明至少还沾一个四季如春，能省点空调电费。

通常说的专业精神，指的就是楼主这样的。
这种情况下，我认为不需要考虑对方的感受，如果是一个有头脑的人，吵完架最终自己也会明白的。
虽然我现在面对这种问题已经不再吵架了，就是直接向上汇报，如果整个公司都没有一个明白人，那就赶紧收拾收拾滚蛋。

作为劳动者，今天我们说，我们讨厌 996，我们心理上拒绝加班。
为什么？是因为我们知道这个世界上还有一帮不加班的人。
今天欧美的劳动者是有业余时间的，是不搞 996 的。
那么人家的今天是怎么来的？麻烦各位去了解一下。
这个世界上哪来的什么都不做就能为自己争取权益的？

这篇文章更适合拿出去给微信公众号。
基本上没什么逻辑性，也完全不符合我对于软件开发行业的认知。难道小型游戏公司都是这么运作的吗？
这事目前看来，更像是双方平时在工作中就积累了很多矛盾，然后在游戏开始运行的时候一股脑爆发了？
从那位程序员的回应来看，他描述的事件过程更符合我对于公司经营者的一贯印象——不懂技术，不思考管理的问题，出事了就拿技术人员来顶缸。
这么费劲在网上互相撕逼，干嘛不直接上法院解决？