看年龄和经历，不过一般来说值得去，996 不是人过的

不用安卓难道想不开用 iOS ？总不能用功能机吧

@superrichman 写好了就不会改的东西反而是不怎么需要单元测试。单元测试一个重要的作用就是保证迭代中的改动不会 break 旧的逻辑。

按楼主百分之个位数的概率就算 5%绝对已经非常严重了

你确定长沙的培训班能有二本软件工程学院的水平吗

@RedBeanIce 好，现在给你这个场景做面试题，你真的没有方案吗？

方案肯定有的，就看愿不愿意用。主要还是考虑统一和方便性。前后端通信有意义的值为什么一定要定义 0 呢，0 只是抽象的符号，用什么都可以。

来一个

@RedBeanIce 一般都能接受。其实说白了都是为了自己方便，减少出问题的点，dba 不想要 null 值是为了防止 MySQL 莫名其妙的问题，研发为了 SQL 能过审核并且能少一些空指针判断 /避免指定义针类型也想自己方便就都 not null 。

产品不同意就去说服他们。

字节的测试人员大部分是外包，水平只能说点点点还行沟通也费劲。流水线要 qa 点了才能发布很多时候就是走过场，qa 的集成测试发现不了太多问题反而经常出问题导致发布卡壳。


实际上加了单测后研发的开发体验好太多了，只是单测质量要高。字节的项目要么没有单测要么单测跑不了，要么单测用 boe 的数据和环境，导致单测根本没法保证质量。

在 tt 经历过新业务，老业务，中台系统，没有一个有单测的。最后改造了一个系统加了比较完整的单测然后跑路了。

字节绝大部分业务代码是没有单测的，代码质量不能说差，只能说混沌一片，没有单测维护所以经常出现一些诡异的 bug

用了一段时间无界 16 ，32+1t 才 6k 多点，自己再加 32g 内存或加 2tssd ，配到 64g+3t 也就 8k 多

争取一下试用期不打折，试用期 6 个月打 8 折实在有点多

@CEBBCAT 虽然都会有一个 recovery middleware ，但是 request 处理内部会起 goroutine 就可能整个程序 panic ，不做处理的话这可能导致日志会丢失一些

@join 能分享下 panic 经历吗，在字节内部大量使用 gorm ，单纯因为 gorm 导致 panic 的没怎么见过

了解头条最近做了一波 SEO ，除了百度封头条外的搜索引擎都做了，我觉得结果还行不算内容农场

ByteVM 难道是字节的？

这样写显然存在 data race ，修好了应该没问题

@276562578 刚入职前司时在容器内 vim 查看日志，直接 oom 把实例搞挂了。从此打开不了解的文件都先看下大小