@lzlee 能水到 80% (逃

@www5070504 嗯嗯 需要多多实践。
本着减少 bug 、可维护、高质量代码去做就行，单测只是一个手段。为了单测而单测也不行

@imdong 要把单元测试和功能集成测试区分开

比如你有一个方法是判断输入参数的，就需要对这个方法进行单测
「意思是对于异常流程，不需要写测试了么？」异常流程肯定也需要，所以单测里面有个重要的概念：分支覆盖率
简单来说就是方法里面的各个 if else 是否都覆盖了

但话说回来，对于单测来说这是可预知的异常分支，比如一些其它异常请求参数非常大，tomcat 就报错了、mysql 网络异常等这些不在单测范畴

首先单测是肯定有用的，是利大于弊的

1. 大公司是有要求的，这么说吧，优秀的项目都是有单测的。当然为了覆盖率一刀切的假单测是没有任何作用的
2. 前面有人说了。还有一个就是要区分单元测试和集成测试，我见过极端的，全部用集成测试代替单测


@supermao
「写的单元测试都是你能想到的并且不会错的」
写的单元测试都是你能想到 这个没问题，不管什么测试都是这样的。但单测还有个作用就是重构的时候，不管方法内部改动多大，之前能满足的输入输出，重构后也要能满足
「并且不会错的」这个不对，单测并不是这个方法完全写好后，再写单测，一般是一边写逻辑，一边加单测代码。甚至先把单测代码写好。而且这个方法开发过程中、以及后面的重构，都可能出错，这样单测就能搂住了。有一个共识：发现阶段越早的 bug 越好修复

打电脑游戏的话还是网线好点，需要稳定，特别是台式机，不然还得花钱买个无线网卡。

阿里、腾讯

按序排列

@jiangzhizhou 要是真的中小公司也好 全部上云，不想那么多

但其实大公司也有小部门，redis 、mysql 可能公司统一的，但 zk 、kafka 这些没人愿意维护

楼主说的没错

但工程方面真的需要很多妥协，有人说为什么锁和队列都喜欢用 redis 。因为一般业务没那么大的场景，而且不一定都是钱相关
主要是 redis 简单，单机就能抗很大的流量

比如用 zk，实际用过就知道，本身服务故障的几率比 redis 大多了，有时候天生分布式反而是它的缺点，运维成本搞
队列也类似比如用 kafka 、RocketMQ 抛开本身集群的运维，还得知道很多概念，用错了问题更大，redis 的 LPUSH，RPOP 简单很多

这么说的，大部分工程师能把业务需求整明白就很不错了

你不想续费旧的怎么能行，不能违背科学呀

@easylee 额 navicat 用的挺好的，DataGrip 有啥高级功能吗？

很正常，多个候选人比较下

你也得多投嘛

我们是这样的
1. 按模块 /服务分，甚至某些子模块是要独立部署的服务
2. 这很正常呀 mall-search 、mall-admin 就是两个不同的服务（独立运行的 tomcat 实例、或者 docker ），肯定有重复的
3. 这种没太见过
4. parent pom 依赖有两种，dependencies 表示都有的依赖，这样子 pom 就不用重复定义了。dependencyManagement 是 parent 声明了版本，子 pom 只需要配置 groupId 、artifactId

我们发布打出的 jar 有 1G 多 来来来，你升一个

看图
mac.qq.com

一张表 5000 不算多，索引搞对了还行。机器配置怎么样？得 SSD

C++后端这么说吧 我们很缺人但是又招不到人

@aureole999 架构原因，不一定都是 web 起步，PC 和 Mac 可能是原生实现
即使是 electron 为什么要做个 web 呢？

主力还是在桌面客户端本身