当然有了。
所有项目能用 pg 的都用 pg 。

技术栈统一，省太多事

@TimLang

现在没有了。曾经的团队。企业重后端业务。
实际十来个人够用了，只不过有 2 个内部因素，导致的最高扩充到了 30+。

Ruby 吧，我做过 30+人 Ruby 团队，90%是 Java 培训转过来的，另外 10%是在之前公司 Java 培训转的。
后端基本 2-3 周就上手了。当时主要是要全栈，国内 react 刚起步，培训起来费劲。毕竟写业务也都要写表单的。

教你个方法。打过来就说

“他欠我 10 万块钱，我现在也一直找不到人。你找到了麻烦通知下我。”

QOS 是消息到达方式
retained 是消息是否保留

和延迟都没有关系。应该是网络或环境问题。你在本机起一个试试延迟。

小心点吧，我哥们被跑腿小哥撞到，无名指粉碎骨折。光医疗费花了 3W 多￥

没啥优势

就 2 块钱，直接买了第二个

@itianjing 这个“不精确”是和电竞鼠标对比的。。

补上条，anywhere 指向不精确。

都不行。

首先妙控板不能代替鼠标，所以妙控板一般放左边的。整体占用办公空间太大。有时切 windows 没有妙控板会很难受，打开笔记本盖子妙控板又在中间，很难养成统一的肌肉记忆和操作习惯。

然后罗技鼠标真的不行，太重，重心太靠前太费手腕。master 太厚重，anywhere
建议选用电竞鼠标。我推荐炼狱蝰蛇，轻盈舒适，切 win 还可以自定义鼠标宏。

Laravel 是抄 Rails 的。Go 是静态语言，很多魔幻特性实现不了。

电脑：内存、硬盘
手机：运存、内存

习惯就好

SA 系统管理员？ System Admin

大部分公司招 php 主要都是做二开的，常年做 2 开，能有个鬼的架构经验。

@l00t
这不是自动化测试兄弟。这就是单元测试。

自动化测试是把肉测自动化。

@l00t

所以说大部分开发都不知道“写单元测试”这个需求哪里来的。

你想象一下自己是软件发布员。你要对线上的软件发布一个小版本，只是一点 bugfix 。这种发布频率可能是 1 周 2 次，甚至初期 bug 不断，每天都会 fix 。

这时候不可能每次发布都要求测试人员把系统所有功能肉测一遍。但是 bug 得修，修了又不能不发。
你怎么知道别人修改的代码不会产生更大的 bug ，甚至把系统搞崩？
软件里面可能几万条逻辑，你想人肉全部测一遍几乎是不可能的。

在人肉检查关键点前，先跑一遍整体项目的测试代码。如果 A 写的代码，由 B 调用或者 C 继承。那么 A 的代码的改动有可能导致 B 和 C 出现 bug ，而他们不一定能做好整体的检查。也有可能 A 的代码是 D 改的，D 改的时候不清楚业务场景，认为没问题就发布了代码，也有可能 B 或 C 没时间仔细检查，也有可能 B 或 C 离职了，想问也没得问。

这时候几万个逻辑的单元的测试就起到了作用，帮助你快速的“初步”判定有没有问题，如果有问题，尽快打回去重新 debug 。要注意，仅仅是“初步”判定，后面对关键点该有的肉测还要有。但是这个初步过滤就能解决很多问题。稍微负责任点的开发，发布（不是提交）自己的代码前，就应该自己把所有测试跑一遍，进行初测。

而且“单元测试”并不是说最小粒度到 method 的这种才叫“单元测试”，单元要看你怎么拆。业务单元也是单元，只要这个流程中间不间断，没有异步，有明确的 input 和 ouput 就可以作为一个单元。你甚至可以不用在最小粒度写单元测试，只对拆分好的业务单元去写测试。


懂不懂单元测试，是程序员水平的一个分水岭。
招聘的时候只要问他对单元测试的理解，基本就能判断他开发水平怎么样了。
不知道单元测试的是票友。听说过没写过，或写过说不出所以然的是初级。而写过单元测试但强烈认为单元测试没用的，这种直接过滤掉。

并不是说程序一定要写单元测试。
1 不太复杂，且对不稳定库依赖不强的程序，可以不写，人肉就可以很快完成 debug 。
2 对质量要求不高的程序，主要是低价外包程序，这种写一句测试都是浪费时间。
3 验证 idea 类的程序，写出来只是为了给自己或者是别人看一下。
4 变动频繁的程序，创业的项目，业务流程经常发生摆动，而每一次重构，可能都是大刀阔斧结构性修改的。这种可能测试刚写完，代码就废了。这种如果成员开发水平一般，测试还是要写的。但是尽量不要去 TDD ，有可能致命。

前三种，基本写一下注释就好了。
第四种，如果开发者有很强的记忆力、控制力和责任心，对软件（自己开发的部分）每个细节都了然于心，每次修改代码都能严谨的去敲定需求和自测，可以不写。