@newmlp 请问一下，这个 H264 编码的开启是否有什么条件，我开了发觉比不开还要慢

我用了很多远程桌面工具，可以确定在同样的网络条件下，目前没有比 RDP 更优的。其它工具有时候看起来更好，实则是他提供的线路比你自己的网络好。而类似 steam 的串流技术是为游戏准备的，响应速度更好，但是对网络质量要求更高

楼主应尽量考虑争取到赔偿房屋重建的费用，毕竟这是国家政策允许的，土地本身赔偿不可能高的，首先修路征地本身针对土地的赔偿就不允许高，这也是政策规定的，你硬要高了现实的案例也不是没有，人家直接绕过去你一毛得不到不说，以后你就住路边上天天和噪音和灰尘为伍了

没啥意义，你研究出来又咋样？一个版本更新就可以让你全失效，而且你未经别人同意调别人的接口，腾讯这种级别的企业反手一个非法入侵控制计算机系统罪就可以让你吃不了兜着走。玩这种的都是灰产性质，要么就不公开，公开的很快就会失效

Java，强烈建议 Java，你见识过以简单为哲学构建系统的 Go 之后，应该研究另外一种以较为复杂的体系构建系统的 Java 的哲学。
不建议 C++，特性太多以至于其最初的开发者都没法完全背下来。
不建议 rust，其思维独特且学习曲线陡峭，可以在多见识几门语言后再来研究，现在早了

离职要签竞业协议是典型的骗老实人。要换我当场就要怼他脸上：懂不懂劳动法，居然敢 PUA 老子

我有幸在还没去大厂的时候进大厂参观交流过，至此就绝了去大厂的想法，大部分人都是螺丝钉的地方，除了钱给的够多外真想不出有去的意义，但是讲真，你要是会当演员，大厂真是个绝佳的去处。楼主这种太较真的性格，在大厂待不住，会吃亏

@mogutouer 因为它们在我们之前吃过隐私外泄的憋，这种事情都是如此，先要亡羊，才来补牢，数据安全法如果不是国内出了几次比较厉害的脱库事件，也不会这么快实施

财政部 2020 的调查数据，月收入过 5000 的不到总人口的 10%，总有人喜欢用身边统计学的感觉去质疑专业机构的调查

@micean 如果数据结构本身设计没问题，那清理屎山的最好方法就是重写，但是往往屎山是屎到数据结构都被污染了，这就很难恢复了

我从来没听说过劳动仲裁官司需要老板手机号的，请务必弄清楚仲裁是仲裁你和公司之间的问题而不是你和老板之间的问题。楼主不妨先解释一下为啥会需要老板手机号

到目前为止，swagger 这种代码和文档直接关联的做法还是最佳实践，单独写文档的最大问题，就是你一定要分出人力监督写代码的人务必更新文档，尤其在协作开发时这个问题非常突出

数据结构在编程中从来都是放在第一位的，Fred Brooks 在《人月神话》中说：

向我展示你的流程图,而隐藏你的表结构，我依然会非常迷惑；如果给我展示你的表结构，通常我就不需要你的流程图了，因为它们显而易见

你这么理解就明白了，这个类 User 仅仅是你的 A 服务为了映射请求结果而本地自定义的一个映射数据结构，这个映射数据结构和 B 服务可以说是没关系的。所以你当然应该放在 A 这里

你很纠结无非是你觉得这个东西似乎是可以复用的，所以纠结放 A 还是放 B，以及是不是要抽出来做个公共依赖。

我很久以前也很纠结这个东西，但是踩了太多坑以后我的想法就变了，高内聚低耦合本质的意义，就是把和一个服务（组件，应用，包，等等等等）相关的代码全部包在一起，不要和外界有牵扯，你有牵扯就会引发修改时的依赖地狱。


Java 这个语言在诞生的时候不管是发明者，业界，都很非常强调设计模式，设计模式中的一个需求来源就是代码复用，但是这是历史；历史上 Java 被开发出来，是希望写基础设施，来取代 C++的位置，基础设施离业务比较远，需求相对稳定，因此比较容易抽象和复用。但是 Java 发展到今天，形势已经变了，就像 Go 为了满足社区里大量写业务的人的需求，不得不加泛型一样，Java 现在和业务靠的非常近，和基础设施相对距离远，而业务又是复杂多变，这就导致抽象和复用变的困难而价值降低，能适应修改变成了硬需求，这种情况下。IOS 那种把一个程序的依赖全部聚合在包的内部的做法，才是最适宜的。

诚然，不抽象和复用，代价就是代码会膨胀，以及相似代码到处 copy 的问题。但是什么事情没有代价，无非是你选哪头而已。以 Java 目前这种更靠近业务的使用环境，项目初期我是完全不赞成去考虑抽象和复用的，至少要等到业务成型并稳定后，再去抽象和考虑复用进行重构

@linhongye Electron 本质是个浏览器，里面跑的东西就是 web 前端，vscode 比较狠的地方在于它的 web 部分是用原生 JS 写的，没有使用任何 UI 库之类的东西，而且使用了很多“魔法”进行优化。这是绝大部分 Electron 开发者压根做不到的事情，他们基本都需要借用第三方 UI 库，也不可能进行“魔法”级的优化。就算是这样，vscode 的性能也只能说在 Electron 开发的程序中算非常优秀，和那些用原生技术开发的编辑器比比性能照样会败下阵来。

@sheep3 凡是用过 PC 原生程序的人，都不会对 Electron 这种动不动占上百 M 内存的软件有任何好感，更别说基于 Web 的 UI 目前在性能上差原生远的很，也就是新生代觉得可以接受，老 PC 用户根本无法接受这种性能。

另外你也别拿 Vscode 和 idea 来说事，vscode 从来就不是以性能出众的（虽然在它用的技术这个领域里它性能已经算出众了）。和一票老牌的原生编辑器比 vscode 的性能一比遭，无非是作为新生编辑器社区够大，生态够大，所以性能不出众的问题大家也就忍了而已。至于 IDEA，我就一句话，我不得不用 IDEA 作为生产力工具，是因为 java 的 IDE 基本都是拿 Java 写的，大家性能差不多的烂，IDEA 功能还算可以，也只能捏着鼻子用了。

我们只是没办法，不得不忍受这种非原生程序的性能，不是我们愿意我们喜欢，吹这些非原生程序的时候你可以说他们功能好用，社区庞大，但是唯独别吹什么性能。把 PC 当生产力工具的领域的用户太多都是原生时代过来的老油条，原生和非原生之间的性能差距远没到让人感觉不出来的时候，说这些非原生程序性能不行，没有任何错误

@cubecube 空项目有啥用呢，你加个最基础的 web 依赖试试

这还要争多久啊？

喜欢 ORM 的思路，选 JPA 。

喜欢 SQL 帮助工具，选 Mybatis(的各种增强版，抱歉，原版 Mybatis 我也用不下去，普通的 OLTP 查询也要写 sql 我受不了)。

实际现在真正流行的东西，是 OLTP 的 ORM 和自定义查询的 SQL 帮助工具的结合体。Mybatis 的几个增强工具其实就是这个思路，这也是为啥这东西流行的原因。觉得[Spring Data JPA 这么好用]。纯粹是你还没遇到能戳到它弱点的需求而已，被戳一次你就再也不会想用 Spring Data JPA

@bnm965321 作者用词可不是瑕疵，用的是“错误”和“困境”。你觉得你比作者更理解 npm ？

我也不想和你争论这个，没意义，我们互相不可能说服对方的，我能理解有些 noder 对 node 唯一一个包管理器 npm 的维护情绪。但我本身是多门语言一路玩过来的，我更喜欢批判而不是维护。我也不打算去说服别人，你的存在恰好证明了我的观点，前端社区对什么是好，什么不好，根本不统一，社区意见都不统一，工具链发展自然是左右摇摆的探索期