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

2019-10-29 08:23:06 +08:00
 clecho
我之前待过的都是些小公司,代码质量都不高。不过基本都是做的 to b 端的系统,所以感觉 bug 也不多,性能因为用户少也没什么感觉。

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

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

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

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

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

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

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

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

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

所以今天想问下在座的诸位,你们公司的代码质量高吗?线上 bug 多吗?
21157 次点击
所在节点    程序员
195 条回复
yufeng0681
2019-10-29 15:30:33 +08:00
逻辑 /业务复杂的功能 /特性, 就要先写文档再开发; 重性能的就要关注数据结构的设计;
简单的增删改查类的功能就放低要求,在上线过程中纠正,也不会很痛苦。
这样重要模块增加的设计成本(文档,数据结构),就不那么多。
hantsy
2019-10-29 15:38:52 +08:00
@toyuanx Code review 那一步哪里去了?没有评审他们的代码是怎么提交上去的?
learnshare
2019-10-29 15:40:26 +08:00
多数项目都是面向上线编程(能用就行)
+ 文档资料缺失,后续更新维护很难
+ 没有测试代码,甚至没有完善的测试方案
+ 代码没法看,有 lint 不敢开
+ 领导甚至其他成员还不让你优化重构

代码和应用质量通常跟公司业务好坏关系不大,所以领导们不想在这方面多花时间和精力
hantsy
2019-10-29 15:40:57 +08:00
@random0O 国外公司很多有自身的考虑,而不是说他们不愿意用成熟的框架。我之前遇到一个项目也是这样,他们不用 Spring 这些流行的框架,每个第三 LIB 引用全部要审核它的协议,保证使用没有法律风险。
fengjianxinghun
2019-10-29 15:43:32 +08:00
@hantsy 从来没听说过有什么 code review。
specita
2019-10-29 15:46:35 +08:00
一言难尽,毕业后在大厂,发现同事写的代码好厉害,简单明了,模块化
后来回家乡的其它厂,一言难尽,反正他们的标准就是能运行起来就行了,其它无所谓
hantsy
2019-10-29 15:52:35 +08:00
@murmur 没错,国内很多创业公司上线都是在 3-6 个月左右。我之前参与过两个公司,都不到一年灰飞烟灭。只能说我没法适合国内的创业模式,各种套路招人,想各种方法(股权啊,什么发一部分以后融资了再补一部分工资)降低工资,加班加点,最后市场不接受,大家一起 88。以我的观点,那些没有两年以上规划的创业公司,基本上浪费人的青春。
gabezhao
2019-10-29 16:08:04 +08:00
原来都这样呀,哎
duanxianze
2019-10-29 17:13:21 +08:00
大家都一样啊。。。
zr8657
2019-10-29 17:18:16 +08:00
说真的,对绝大部分公司来说,能上线就不错了,剩下的过后再说,然后就没然后了
tt67wq
2019-10-29 17:19:47 +08:00
垃圾到爆炸
random0O
2019-10-29 17:58:34 +08:00
@hantsy 内部的东西倒是都挺成熟,但就是设计得和市面上常见的框架们不一样。数据库不支持外键,函数中一旦创建一个事务对象,所有被它调用的子函数只能使用这个事务,想再建都不行。Java 代码里每一步异步操作必须单独写个函数还不让调用,想在其他函数用它的结果必须将其返回值列为一个参数,框架会去找哪个函数的返回值匹配这个类型然后调用它。内部的其他服务,都因为历史原因各有一系列大坑。
hantsy
2019-10-29 18:33:27 +08:00
@kayv
1. Code Review 大部分在 PR 上进行(创建 PR 之前的 Commits 可能是 Partial work,属于 Work in Progress 状态),反复讨论修改,Commit,直到所有没有什么意见,测试全部通过为止,合并代码。
2. 到了一定规模的应用程序,可能不会每次合并就部署到生产环境前,加入有一个缓冲阶段,依然需要 UAT 环境部署,QA 测试,正式部署到 Production 之前进一步优化用户体验。
3. DevOps 工程师有时还是不缺少的,虽然 Infrastructure as Code 可行,有时脚本也要人维护,而一些特殊的生产环境可能与开发环境完全脱离,部署人员也可能有专职的维护那些环境。还有有的公司出于安全考虑,开发人员可能接触不到部署环境的一些配置参数。
ZSeptember
2019-10-29 18:40:17 +08:00
哈哈哈,大家都一样。
youyeku
2019-10-29 19:11:08 +08:00
不高和你情况差不多。迭代又快新手害人。我自己都看不下去那写的代码,而且有些还是历史遗留问题,写的连重构的欲望都没有。
hslx111
2019-10-29 19:33:27 +08:00
代码越多坑越多,哪里都一样
52coder
2019-10-29 19:51:20 +08:00
我怀疑我们在同一个公司。
BenjaminReed
2019-10-29 19:59:37 +08:00
嘶 早上九点到十二点是解决线上问题时间 你说惨不惨 日哦~这种情况已经延续一年多了。
donyee
2019-10-29 20:32:16 +08:00
java 项目代码不分层...一个类实现所有功能...
有个公共类是小写的...
akira
2019-10-29 20:34:55 +08:00
所以 ,高质量的代码 的存在 只是一个传说?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/613867

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX