组里的人代码质量差怎么委婉的说

建议你把自己的部分写好
别人的部分等你变成manager再操心
同时仔细考虑以后要不要回来

听取大家意见，不纠结了，后面的comment也不写了

代码质量只有在公司特别大之后才会有impact。当工程师多起来之后，要保证高迭代速度必须要有相对的高质量代码。小公司在不影响效率的情况不明下，代码质量真的没人care。

匿名用户 发表于 2021-10-04 07:59:06
当然不是，我见过微软一些早期项目和Uber早期的code，都是Sxxt，但是只要测试写得够多，business逻辑可以赚钱，comment都不是问题

并不是每家公司都不重视，不要以偏概全。 在我们公司这属于craftsmanship，属于升职三大要素之一， 代码质量，测试覆盖，文档完善，等等都属于这类。 这都是长期来看有助于提高工程效率，有助于加快迭代效率的。

屎山见多了就不怪了。

匿名者 发表于 2021-10-4 07:59
当然不是，我见过微软一些早期项目和Uber早期的code，都是Sxxt，但是只要测试写得够多，business逻辑可以 ...

你给的例子跟结论有任何causality？就跟说几百年前中国女人裹小脚所以现在也裹小脚一样 别瞎扯了 那你看他们现在的代码还是这样么？早期屎山代码都没人感动 野蛮上线后面再花时间重构 别人早期走了弯路你还要再走一遍？

并不认为应该说，他提升了，到时候裁员时走的就是你吧

匿名者 发表于 2021-10-4 08:24
典型的没见过世面的学生。成功产品的代码质量都是屎。代码质量好的产品都完蛋了

那你说说代码质量不重要为什么这些“成功产品”牺牲代码质量换时间抢占了市场之后花几倍的时间重构提升代码质量？

可以先加上一些check to stop the bleeding
- 例如，保存总eslint violation count只减不增 这样新的file都是高质量代码
- 对新的代码提高code quality要求
- 但凡一个PR触碰过老的代码，也必须要把里面的violation全部修掉

.1point3acres这样随着时间推移，自然而然就能提升代码质量的底线。

说了估计也没人听，不如不说