ziggear

“雇一个人看店” 就能把店经营下去的可能性为 0

谢谢大佬分享！另外请问一下“vite+React+antd+nest.js 一把梭”有没有什么学习路线或者最佳实践案例？我是客户端开发想转前端，目前正在学 React ，想找个不那么费劲的后端技术栈

@ClutchBear01 大佬请问 蜜獾超存 6 盘位的，我看有些说认 6 盘失败，是这套硬件有什么缺陷吗。外观倒是挺精致的

@wxw752 666 我曾经也立志全换，没想到原装这一套跑得非常稳定也就没再折腾了

@guoqiao 老哥，如果没有 WHV 或者 PR ，想在新西兰找到愿意提供工签的公司是不是基本不可能？

带宽很难跑满，你得想办法增加连接数，跑满 CPU

银行的职责就有还钱这一条，不会拒绝你，去之前提前打电话说一下应该就行，给他们点准备的时间
万一拒绝给你换的话可以找相关部门投诉

问“哪些领域”，不如问“哪些能力”或者“哪些知识”

开发人员 bug 列入考核，那就要先问：怎么考核？我想无非就是那几种方案，比如常用的“千行变更 bug 率”——这个规则一旦实施之后其实会引发另一个问题：对于模棱两可的 issue，QA 到底要不要提为 bug ？比如前端开发字体过大（即使需求如此？），很多时候 QA 会提为 bug，严格来说应该分类到“体验优化”的 issue 里，但是互联网公司一切都要求快速推进的节奏，我不知道有多少 QA 团队会去细化和贯彻提 bug 的界限、分拣规则，以及后续的无效 bug 打回或转需求等问题。

我所在的团队曾经就面临这样一个恶性循环：领导提出要考核 bug 率 —— QA 提 bug 后频繁被打回 —— QA 开始变得谨慎，提 bug 之前先找开发确认 —— 开发效率降低 —— 代码质量下降。所以我个人认为，bug 列入考核确实不合理，但并不是从不公平角度来看的，真正能很好执行考核流程，还能解决上面我提到的问题的团队，相信都是无论是个人的业务能力还是团队的合作能力都非常到位的团队，自然不用太担心 bug 率的问题。

另外，如果是为了恶心你们，那就另说了。