是否开源并非是否安全的充要条件，工程代码的可靠性是需要各种“成本”覆盖来保障的，其中有一条就是快速响应修复。

当然，有些人觉得只要没暴露出来安全问题就没有安全问题，我只能说，看看牙膏厂这两年的 CPU 安全漏洞，是不是要打算从 CPU 开始造轮子？

VS 有数据库代码化版本控制的功能，社区版就有，对比差异，添加注释什么的都是有的。

然后 SQL Server 2005 之后的版本都支持 DAC 方式发布升级，不过有些变更还是需要人为干预，不过各个 ORM 框架的自动迁移功能其实多多少少也需要人为干预。ps：vs 支持生成 DAC package。

最后，用数据库自带扩展属性就能满足表字段的说明了，然后用脚本生成即可

https://gitee.com/TomCzHen/codes/jqp7nob9ylu0k6xvsw58h

只要加班不用付出额外成本，即使边际收益再小，资本也会选择让工人加班。

换发行版、上 docker，二选一或者换发行版上 docker。

让人推荐平台配置又不说预算的都是来瞎扯淡的。

问题英语等级考试的评估模式和看视频电影的需求并不完全切合。

虽然词汇量要求肯定是要的，但是由于内容偏向和口音，包括流行词汇和俚语等都会影响理解。

只能说楼主还是谨慎点比较好。

公司任何帐号都是密码生成器生成密码，私人电脑登录公司帐号一律开隐身模式，帐号密码交接出去之后，不管是不是记得都说不记得——反正也确实没法记。

我敢说楼主肯定只是安装并运行成功就算打完收工了。

在 AMD Rzyen 2400G 平台上 OpenSUSE + Lutris 肝了几个月 WOW 的表示，WOW 在 Linux 有个超级蛋疼的问题，不做处理，会在游戏过程随机出现错误并退出，需要从 Windows 上拷贝一份最新的 World of Warcraft/_retail_/Cache/WDB 覆盖到 Linux 下的路径才能解决这个问题。

不管技术是不是真的具有稀缺性，是老板，心里怎么想不重要，肯定要这样说；是员工，心里怎么写不重要，肯定要反对。

商用和家宽不一样，具体差异要看服务协议这些。当然，你觉得不值也没办法，因为没法选择。

如果没有什么合理的理由，比如大规模扩充人员架构各个层次都要之类的。那么，通常就是对行情不了解，又怕做冤大头，所以才这样讲——有点像网游里面打到个“极品”装备不知道开什么价的。反正用人方市场强势，大多数人也不能说什么。

至于那些实际能开的薪资比 JD 薪资下限还低很多的情况，我是完全搞不懂什么操作。

比烂，恰饭，常规操作。以后要是他发达了，就是情商高，敢拼，你这种人情商低，死板。

307/308，但是需要 http client 有实现。

改变不了什么，不过迷茫又不知道该做什么，那就先学着。

沃尔玛收银员——曾经在世界 500 强企业负责财务相关工作。

USB3.0 外置硬盘座

嗯，知道了。

这个不是一个完全的技术问题，需要建立在良好的设计之上才能解决。事实是不论如何做版本管理，最终落地都会对开发人员有水平要求，而人员成本直接决定了版本管理方案最终能不能实行下去。对于很多小公司，由于人员流动高，管理水平有限，一份代码复制 N 份，一个客户一个压缩包是常态。

当初我选择的方法是一个客户一个分支，然后可以合并的功能合并到主干，并做成可配置化，分支需要主干的功能时由对应负责的人去从主干合并到分支。数据库这边不使用所谓的保留字段，会造成同一个个字段不同客户有不同的业务意义，涉及到功能代码升级时无法平滑升级。

实际实践中仍然一堆问题，主要是合并代码时对操作的人要求比较高，分支负责人通常都图方便，选择直接复制粘贴对应代码解决。当主干功能模块出现 bug 修复后，无法找到合并记录，还得人肉再对比修复。后面经过几次人员更新，又变回压缩包解决的方式了。

后面我想明白了，在一定规模下，压缩包这种方式也确实可以有效降低人员要求和管理要求，也算是符合成本的解决方案。

这些 ERP 为了保证功能正常，有些就是需要暴露高危端口和服务的，开发商那边的技术支持也解决不了问题。

无论上上云还是部署防火墙其实出发点是一样的：认为只要这样做了问题自然会解决。