诸位公司项目的代码质量高吗？

[clecho]

我之前待过的都是些小公司，代码质量都不高。不过基本都是做的 to b 端的系统，所以感觉 bug 也不多，性能因为用户少也没什么感觉。

这次的公司做 to c 的应用，我就开始感觉 bug 贼多，系统性能也不好。代码质量一言难尽。感觉线上系统全是 bug，就等着用户来发现。

这种情况不是某一个人造成的，是产品，开发，测试一起造成的。

产品考虑需求不全面，想着开发写的时候会发现问题。

开发写代码的时候也没有多考虑，主流程能跑通就 ok，以前的历史代码是这么写的，新功能我也这么写。

测试也对系统不够了解，主流程差不多就可以了。剩下的 bug 随缘发现。

总结一下就是，所有人都不了解系统。公司迭代又快，没时间去仔细思考。(以前一周一迭代，最近开始两三天就迭代一次)

造成的后果就是功能逻辑混乱，一但要加新的需求就会丢三落四，总有些地方没有兼顾到。线上全是 bug。

搞的我都有点怀疑自己的开发能力了，因为 bug 真的太多了。

以前网上总流传一个说法，大部分公司的代码不开源的原因不是业务有多机密，只是因为代码质量太差，开源了怕丢人。

所以今天想问下在座的诸位，你们公司的代码质量高吗？线上 bug 多吗？

[clearbug]

@gbin #148 老哥说的什么公司？

[dosmlp]

真的是"能跑起来能用就行"毫不夸张

[charlie21]

@timle1029 这是一项单独的工作，要考虑成本的，所以 如果没专人去做测试 ( 而是让 dev 开发 ) 那么结果就是 测试覆盖率很低很低，等于没有，等于自欺欺人

[LunaSentinel]

看到项目的时候很惊讶它竟然能跑起来，后来改造了 gradle 来优化项目结构和依赖，迁移了 k8s，增加了 ELK 支持，换了 zipkin, pinpoint, skywalking 链路追踪...但是独木难支，现在项目太急了，没空闲搞这些东西了，遇事不决就申请机器，拉个新项目，写的公共项目一引用，再也不想重构同事的代码了，管好自己就行，jenkins 编译的时候顺便就出 sonar 报告了，勤快看看就好了，严格律己宽容待人。

[levelworm]

@toyuanx 取其精华会不会最后就是注释基本没有 + 半天才理清楚 + 不注意缩进 + 冗余 + 没法交流。。。

[xiaotianhu]

@kayv 啥公司？

[random0O]

@kuangwinnie 也许设计成这样真的避免了很多 bug，但是几年十几年修修改改下来还是一团糟。今天我们依赖的众多存储服务之一出了一个 bug，导致我们核心功能整体挂掉。具体 bug 还没被找到，但是我去看了一下出事的那个文件，一万两千多行一个 Java 类，有九个方法，名字是 stageOne 到 stageNine。。。这个存储服务的体量是按 EB 计算的。

[kuangwinnie]

@random0O 哈哈哈哈哈哈哈好惨啊哈哈哈哈哈
能不能打断点看看是哪边出了问题？

[jourdon]

进公司看到代码就后悔了，就是一坨屎。
想着算了，跟老板说重构吧，想着说不同意就走人了，结果同意了（尴尬不）.
重构的过程是真痛苦，基础功能没写完就要求上线，老板说了，让用户去测试就好了，所以是一边写 BUG，一边等用户发现 BUG，然后改 bug，同时改需求，一个功能不管写没写完，一个字，改，又急着上线，结果出 BUG，再改，根本不知道要做个什么东西，一切随缘。

[hp66722667]

哈哈哈哈哈哈

[dashixionglihai]

甲方：我想要一个小汽车，能在告诉上跑的那种。
乙方：容易，两个月开发完毕。
一个月后
甲方：能不能加个翅膀，我现在想让他可以飞。
乙方：可以，加钱吧。
半个月后
甲方：能不能再加个炮桶？我想谁挡我路我就炸飞它。
乙方：。。。
十天后
甲方：能不能加个车斗，有些货我想可以拉一些。
乙方：出门左拐。

[new2500]

@kayv 啥公司+1.

[kayv]

血汗工厂亚马逊

[toyuanx]

@levelworm 您太幽默了

[monkeydream]

技术不断更迭，需求不断变化，质量再好的代码也会面临重构；所以只要基础架构 OK，前期还是要求快，等业务稳定了再来抓质量。