这是一个创建于 1860 天前的主题，其中的信息可能已经有所发展或是发生改变。
我之前待过的都是些小公司，代码质量都不高。不过基本都是做的 to b 端的系统，所以感觉 bug 也不多，性能因为用户少也没什么感觉。
这次的公司做 to c 的应用，我就开始感觉 bug 贼多，系统性能也不好。代码质量一言难尽。感觉线上系统全是 bug，就等着用户来发现。
这种情况不是某一个人造成的，是产品，开发，测试一起造成的。
产品考虑需求不全面，想着开发写的时候会发现问题。
开发写代码的时候也没有多考虑，主流程能跑通就 ok，以前的历史代码是这么写的，新功能我也这么写。
测试也对系统不够了解，主流程差不多就可以了。剩下的 bug 随缘发现。
总结一下就是，所有人都不了解系统。公司迭代又快，没时间去仔细思考。(以前一周一迭代，最近开始两三天就迭代一次)
造成的后果就是功能逻辑混乱，一但要加新的需求就会丢三落四，总有些地方没有兼顾到。线上全是 bug。
搞的我都有点怀疑自己的开发能力了，因为 bug 真的太多了。
以前网上总流传一个说法，大部分公司的代码不开源的原因不是业务有多机密，只是因为代码质量太差，开源了怕丢人。
所以今天想问下在座的诸位，你们公司的代码质量高吗？线上 bug 多吗？
这次的公司做 to c 的应用，我就开始感觉 bug 贼多，系统性能也不好。代码质量一言难尽。感觉线上系统全是 bug，就等着用户来发现。
这种情况不是某一个人造成的，是产品，开发，测试一起造成的。
产品考虑需求不全面，想着开发写的时候会发现问题。
开发写代码的时候也没有多考虑，主流程能跑通就 ok，以前的历史代码是这么写的，新功能我也这么写。
测试也对系统不够了解，主流程差不多就可以了。剩下的 bug 随缘发现。
总结一下就是，所有人都不了解系统。公司迭代又快，没时间去仔细思考。(以前一周一迭代，最近开始两三天就迭代一次)
造成的后果就是功能逻辑混乱，一但要加新的需求就会丢三落四，总有些地方没有兼顾到。线上全是 bug。
搞的我都有点怀疑自己的开发能力了，因为 bug 真的太多了。
以前网上总流传一个说法，大部分公司的代码不开源的原因不是业务有多机密，只是因为代码质量太差，开源了怕丢人。
所以今天想问下在座的诸位，你们公司的代码质量高吗？线上 bug 多吗？
 |
1
airfling 2019-10-29 08:34:17 +08:00
刚开始我们的项目也是这样，后来项目进入维护期我重构了两三次才解决这个问题
|
 |
2
devld 2019-10-29 08:35:01 +08:00 via Android  1
不高，我在想这东西竟然能跑起来
|
 |
3
MrUser 2019-10-29 08:35:02 +08:00 3
我怀疑我们是一个公司的，哈哈
|
 |
4
wispx 2019-10-29 08:36:35 +08:00
楼上+1, 你在窥探我的工作
|
 |
5
araaaa 2019-10-29 08:37:13 +08:00
我们小公司，没有白盒测试
|
 |
6
fanyingmao 2019-10-29 08:38:30 +08:00 via Android
从没接过好代码，感觉都是前人挖坑后人填，找工作真不想接二手项目。
|
 |
7
timle1029 2019-10-29 08:39:03 +08:00
说不高吧，每一个 commit 都有 code review，unit tests 基本覆盖，integ tests 也都写了，还有 Canary 一直测试。
说高吧，和公司其他优秀的 Services 比一比，就跟屎一样，缺少 Comments，Commit message 质量极低，为了及时写完各种 hack。 总结来说，就那样吧 |
 |
8
xuanbg 2019-10-29 08:39:18 +08:00
没办法，只能抓大放小。除了我重构过的那几个系统，代码质量也是没眼看。
|
 |
9
fsship 2019-10-29 08:42:29 +08:00 via iPad 1
感觉我司是经手的人越少，历史越短的项目代码质量越高。
而老项目我接手时有些代码文件缩进和变量名风格都不统一的，乱得一塌糊涂。 |
 |
10
lrh3321 2019-10-29 08:46:27 +08:00 via Android
很低，想把它们全重构了，奈何时间不允许
|
 |
11
mnssbe 2019-10-29 08:47:15 +08:00
发现 bug 就去修， 修不了么？ 那就忍吧
你说的好像不只是 bug 的问题，好像要全部重构 |
 |
14
xutao881 2019-10-29 09:04:26 +08:00
我觉得我俩的审美，有必要喝一杯[]~(￣▽￣)~*
|
 |
15
clecho OP @mnssbe 已经在重构部分模块了，奈何时间紧任务重。又在原来的基础上修改。真的无力吐槽了。。。
|
 |
16
wangsd 2019-10-29 09:05:55 +08:00 2
最近在重构之前写的烂代码，一个地方改了还有几十个关联的地方要改，然后我默默的点了 revert。
|
 |
18
assad 2019-10-29 09:06:30 +08:00 1
先紧业务，再整质量
谁一开始质量就高？ |
 |
19
JamesR 2019-10-29 09:06:47 +08:00 1
我这儿是经手的人越少，代码质量反而越高，哈哈哈。
还有代码 bug 多少，不能怪测试，这个与测试无太大关系，程序又不是测试写得。 Bug 多说白了是项目领导管理无能，一个程序写完主要功能后，至少要再花 50%的额外时间，用来写很多代码处理种种意外情况。 无能领导要么不明白这点，要么明白这个却没能力管理好这点，没有安排好进度，没有给下面程序员没有留够充足的时间，不讲究工作质量，效率，所以，就不能怨人家 Bug 多。 |
|
20
clecho OP |
 |
22
Chowe 2019-10-29 09:10:07 +08:00 1
什么？质量？我只要功能！！！--领导名言
|
 |
23
1024G 2019-10-29 09:11:31 +08:00 1
我觉的开始时间紧迫占一个原因。我们以前公司基本改个 bug 要好多天。如果是复杂的 bug，一开始进行开会讨论，review 修改的方向，然后修改，开发自测，最后 bug 提交的时候还有 code review，不行还得返工。提交以后 QA 进行测试，至于回归，主要就是 CI/CD 帮助 check。慢工出细活。
|
 |
24
SteveAlan 2019-10-29 09:12:04 +08:00
代码风格一个接着一个，毫无规范，有新功能就堆新的代码，对设计模式的运用不高
|
|
25
clecho OP @JamesR 不是说怪测试。开发产品和测试都有问题。我们这边 bug 多的主要的原因，就是没有一个人能真正的懂产品的所有功能。所以总要填以前的坑。
|
 |
26
darktutu 2019-10-29 09:12:34 +08:00
只有更烂没有最烂
|
 |
27
Acrab 2019-10-29 09:13:02 +08:00 1
七八年前的老代码，不知道多少代人维护过，代码风格五花八门，全球各个国家的需求杂糅在这一套代码里，业务复杂度高，极易产生 bug。因为产品特殊性，是基本不可能重构了。基本是面向 bug 编程。
|
 |
29
Davic1 2019-10-29 09:13:56 +08:00
只要功能, 能跑起来久行. 剩下的都交给上线以后再说
|
|
30
1024G 2019-10-29 09:14:29 +08:00
如果总是添坑，总有一天会维护不动，只能推翻重来了
|
 |
31
pegasusz 2019-10-29 09:16:13 +08:00 2
看到你们都是这样 我就放心了
|
 |
33
justin2018 2019-10-29 09:21:17 +08:00
看到你们都是这样 我就放心了
|
 |
34
lagoon 2019-10-29 09:22:31 +08:00
哎。。。写了 N 年代码，待过的几家互联网公司，规模基本也在 300+人，但从来没见过什么叫单元测试。
|
 |
35
Saszr 2019-10-29 09:28:10 +08:00 1
屎山
|
 |
36
a5401017 2019-10-29 09:34:16 +08:00 1
屎山 还是各种各样的屎
|
 |
37
QuincyX 2019-10-29 09:35:43 +08:00
重构
|
 |
38
Johnny168 2019-10-29 09:36:56 +08:00
哎呦，还在写 BUG 啊
|
 |
39
JRay 2019-10-29 09:37:21 +08:00
我也怀疑我们是一个公司的
|
 |
40
hyy1995 2019-10-29 09:37:54 +08:00 1
工作接近 3 年，接触的都不高。。。就算是大厂，也有很水很垃圾的代码，比如新浪微博 web 端、百度贴吧 web 端，更别说中小型公司了。
|
 |
41
cwjokaka 2019-10-29 09:38:34 +08:00
很高，很符合我的代码习惯，就我一人在写
|
 |
42
unicloud 2019-10-29 09:39:38 +08:00
讲真，写业务代码，代码质量能高到哪去？就算是大厂，不说别的，F12 走一波，你也能发现「质量不那么高」的代码。。。
|
 |
44
Kbyte 2019-10-29 09:50:15 +08:00
我就记得，有个子项目的工具，用了 4000 行 if。具体情况就是完全没抽象出对象，甚至 switch 都不写，硬怼。人看傻了
|
 |
45
fancy111 2019-10-29 09:53:07 +08:00
代码见得多了，你就习惯了。纠结代码质量的那是你经验不足。
</br> 没有修复不了的 bug，没有完美的代码。 |
 |
46
Juicpt 2019-10-29 09:57:31 +08:00 2
质量?不存在的，
 我们领导放下豪言，要招满一个楼层的实习生， 然后用实习生干活，这能存在质量就有鬼了。。。。hhhhhhhhhhhhh |
 |
47
129ykx733D016U2n 2019-10-29 10:04:30 +08:00
刚开始好好写，后面感觉整个项目的代码都是 Shit，改都不想改
|
|
48
Kbyte 2019-10-29 10:05:23 +08:00
@Juicpt 我以前待过一个公司，找了包括我在内的一群鸡实现一个功能，后来请来了个十年的这行的老人过来说有个开源实现，是我们写了一个月的垃圾的完美形态……后来我就摒弃了什么都想自己写的弱智想法
|
 |
49
raptor 2019-10-29 10:09:25 +08:00
没办法，需求滚滚来，产品经理的 feature 也是铺天盖地，只能先实现了再说，质量问题……等出问题再处理吧……或者下个版本重构（希望有机会
|
 |
50
coderluan 2019-10-29 10:10:03 +08:00
高啊，公司有印度部门，从领导到小弟，只要技术不咋地的，都热衷于优化代码本身，改改格式变量命名拼写之类的，还分着提交，然后开会时吹水，我又提交了多少个 patch，占总提交的多少。
|
 |
51
hoyixi 2019-10-29 10:11:02 +08:00 3
自从这行变成程序员默认 996 之后，质量就不是个事儿了~
软件流程、开发管理、测试等等质量手段，都是为了啥? 为了降低维护成本。 然而可以等工资条件下加班用人肉解决，那还考虑个屁质量，加班就是了 |
 |
53
doveyoung 2019-10-29 10:16:18 +08:00 2
@clecho 我不是写代码的，但是对“先上线，再迭代”这句话深恶痛绝，这种一般都是上线之后没下文了，“又不是不能用”，别的事情也是，都说了先 XX 再 YY，但是 XX 后根本不可能 YY
|
 |
54
mamahaha 2019-10-29 10:19:41 +08:00
代码质量高不高主要看实现了啥功能，bug 是否严重，用笔记、脑图把流程记录完整比格式好看更有效。毕竟写代码不是为了让其他程序员高兴，而是为了让用户高兴，让自己高兴。
|
 |
55
Orenoid 2019-10-29 10:20:00 +08:00
保证高代码质量是很费神费时的，除非团队有严格要求，或者项目很小，否则指望开发人员自觉基本不太可能，除了那种真正有追求的，而不是在简历上写写而已的。
|
 |
56
wangxiaoshan 2019-10-29 10:21:52 +08:00
差的可怕
|
 |
57
loshine1992 2019-10-29 10:25:48 +08:00 3
一言难尽。。
Android 项目 1. Java 代码里直接用像素不用 dp 转的 px 2. xml 里文字大小不用 sp 用 dp 3. 万事不决加成员变量，一个 Activity 光成员变量的声明可能就写了 50 行 4. View 层级多到离谱，哪个方便哪个写，一层一层往里加 5. Fragment Manager 事务不提交，我也不知道这个事务为什么要 begin 6. 纵向 NestedScrollView 套 linearlayoutmanager 的 RecyclerView，不把上面非 RecyclerView 的部分变成 RecyclerView 里的一个 view type 7. Presenter 里用 Activity，Fragment，Context 的方法 8. 到处都是的神秘 EventBus 事件订阅，有的在 View 里，有的在 Presenter 里，有的在 Activity、Fragment 里，有的在 Adapter 里 等等 |
 |
58
xaoduer 2019-10-29 10:34:39 +08:00 1
业务代码确实难写难维护，人员更换频繁，越写越臃肿，甚至基本错误接手的人都不敢改或者不愿意改或者没时间改
|
 |
59
jsondog 2019-10-29 10:37:58 +08:00 6
程序员本来是个智力活，硬是让中国企业给整成了体力活。996，9 你妈比，老子到点就走
|
 |
60
deljuven 2019-10-29 10:38:24 +08:00 1
屎山……
|
 |
61
virus94 2019-10-29 10:39:40 +08:00
没有质量可言,各种乱七八糟的业务 feature,能做完就不错了
|
 |
62
freefcw 2019-10-29 10:43:19 +08:00
偏业务的代码就是这样的。。。
主要还是看能力，但公司能给多少待遇给对应的人呢？还不是人少事杂 |
 |
63
taogen 2019-10-29 10:43:48 +08:00 1
不规范造成的恶果。。。
时间短、成本低、质量高，只能同时保证两个。 |
|
64
freefcw 2019-10-29 10:45:12 +08:00
不过多少和人的能力有关的，接到一个需求，是否合理，如何接入系统，性能，可扩展性等诸多方面都要考量，有这些思考能力的人就少，能写出合格代码的更少，加上人少事杂。。。呵呵哒
反正需求方就是三藏，我要我要我要。。。 |
 |
65
hunter2015 2019-10-29 10:57:51 +08:00
看到你们都是这样 我就放心了
|
 |
66
hanxiaodi 2019-10-29 11:00:49 +08:00 1
曾经不止一次想过重构，领导的意思是：重构可以，自己花时间下去搞，上班时间该干啥干啥。
WTF ？好多批人来来走走之后，几经迭代，现在公司甚至都没有最新的源码，线上在跑的跟本地源码差别还有点大， 然后领导的意思：线上在跑的不要动，有新添加的功能模块，单独弄个服务搞上去... 代码质量就... |
 |
67
dany813 2019-10-29 11:04:41 +08:00
哭着维护
|
 |
68
ganbuliao 2019-10-29 11:05:23 +08:00
哈哈 看到你们都这样我就放心了 所以部门里还是有个搞基础建设的好
|
 |
72
Alwaysonline 2019-10-29 11:15:57 +08:00
面向 ZF 定制的。
服务端不挂，没啥需要维护的。 各种备份，硬件设备报得多。。。 功能导向的，界面丑是真丑。 |
 |
73
17681880207 2019-10-29 11:17:22 +08:00
垃圾。
|
 |
74
jsnjfz 2019-10-29 11:27:59 +08:00
两三天一迭代产品天天在出需求吗，To C 的产品真的要克制需求，而把数据分析做好，两三天一迭代怎么看数据
|
 |
75
anry 2019-10-29 11:28:04 +08:00
楼上的摸鱼都被我抓到了
|
 |
77
fengchang 2019-10-29 11:28:14 +08:00
@timle1029 先上线，后迭代。有的是先上 MVP，然后加功能，有的是先上一堆 bug，然后慢慢改。AWS 是先上了 EC2，然后 S3，一个一个产品加上去的，但是可从来没有上线一堆 bug 给客户用。
|
 |
78
mmrx 2019-10-29 11:33:01 +08:00
@loshine1992 我对其他的没有异议，唯独第二点，字体大小习惯用 dp，虽然 sp 是推荐的，但是 sp 会受到系统定义的字体大小影响，设计又要求 ui 的还原度，咱也不知道测试的测试机字体用的多大号...只能用 dp 来做还原度保证...你对此有什么建议么
|
 |
79
Marmot 2019-10-29 11:45:05 +08:00
有好多时候都是名字有坑，只能往里面踩，就是要做出来，做成那样子，项目稳定前都是这样
只能等项目稳定了，慢慢重构，但是这需要花费资源冒风险，公司一般也不愿意 |
 |
80
abmin521 2019-10-29 11:52:50 +08:00 via iPhone 1
有人拿编程当爱好
有人拿编程当工作 |
|
81
loshine1992 2019-10-29 11:54:32 +08:00
|
 |
82
cgmaybe10 2019-10-29 12:03:32 +08:00 via Android
自从上次坐在同事旁边帮他写页面，页面写完后能运行起来，但也 as 有些地方报错，提醒他改一下，结果同事说没事，能跑起来就行，从此再也没对项目的代码提过意见。
|
 |
84
GuangXiN 2019-10-29 12:07:51 +08:00 via Android
只要测试覆盖充分，再糙的代码都不怕
|
 |
85
Novll 2019-10-29 12:12:49 +08:00
一切尽在不言中
|
 |
86
exploreXin 2019-10-29 12:21:11 +08:00 1
代码质量是一套体系而不是某一个东西，公司不给提供相关管理环境，个人是没办法改变的。我在一个三个人的创业团队待过很短的一段时间，那里连运维是什么，团队的老大都不知道，更别说代码审查，测试环境这些，写了代码直接丢线上，出了问题再调，可以看出现在创业环境比以前确实降低了，什么虾兵蟹将都可以出来包装一番美其名曰这个科技公司那个网络公司，实际上注册资金就几万块，根本就连在街边摆摊卖草鞋都没资格，还搞什么高科技，人工智能，真是不知道自己几斤几两，可笑之极。
|
|
87
timle1029 2019-10-29 12:24:43 +08:00
@fengchang #77 客户没觉的是 bug 是因为很多时候 alarm/sev2 迫使大家找到 bug 了，其次很多 customer ticket 最终的结果也是 code bug
|
 |
88
fewok 2019-10-29 12:25:48 +08:00
一顿异常报警，终于发布成功。。。居然还不影响服务。可以，先这样吧。
|
 |
89
sevenzhou1218 2019-10-29 12:27:18 +08:00
一坨屎
|
 |
90
EscYezi 2019-10-29 12:43:37 +08:00 via iPhone
真的烂，连给自家做的 oa app 打卡功能都一堆 bug，隔三差五打卡来个 500，这谁顶得住啊 https://i.loli.net/2019/10/29/p1jNmIzQ3iA645E.jpg
|
 |
91
dongyx 2019-10-29 12:56:10 +08:00 via iPhone
公司雇我们来，就是改善代码质量的。没有 bug，架构完善，给我们那么多钱来做什么呢？我们的任务就是去改进这些东西，而不是抱怨。
|
 |
92
charlie21 2019-10-29 12:58:31 +08:00 via iPhone
1. “能跑起来就行” 发展到最后 必然导致屎山
2. 多人团队，代码质量并不和工资挂钩，是否抱着 “能跑起来就行” ，都不影响一个人的工资 3. 多人团队，必然有至少一个人把 “能跑起来就行” 挂嘴边 - 那么问题来了：怎么攻破屎山形成的必然性？ |
|
94
dongyx 2019-10-29 13:07:46 +08:00 via iPhone 1
@clecho 我认为求职是个自由市场，如果有其他公司能否给到我们更好的的回报，我们可以选择去新的公司。如果当前公司是我能找到的最好的公司，那我只能想办法把事情做好，以求加薪或者提高选择能力后跳槽。如果能够把现在公司的项目质量提高，对程序员来说是简历上的亮点。什么都很完善了，简历上怎么写了？
|
|
95
dongyx 2019-10-29 13:15:06 +08:00 1
@dongyx 另外关于需求和技术的矛盾，我自己有过一些反思。产品和技术的评价标准不一样，如果一个需求会导致按照我们程序员的标准必然导致烂代码，以前的我会觉得特别难受。但是后来发现是我自己被禁锢了，回顾软件工程的历史，我们程序员关于好代码的标准是怎么建立的呢？是在一次一次的实践中建立的，这些标准的最终目的是做出好产品。当市场上绝大部分公司的需求都会破坏这些既定的标准的时候，这说明时代变了，需求的模式变了，而我们软件工程的理论没有变，是我们落后了。我想我们要做的，是去探索新的符合这个时代的软件工程理论和架构模式吧。
|
 |
96
pangleon 2019-10-29 13:16:39 +08:00
很垃圾，然后 S13 总监还说，你觉得我们代码烂，那你是没学到我们的精髓，我们一样支撑了 X 量级的业务（我心说几十台服务器放那了是你牛逼还是服务器牛逼？）。
然后我就走人了，跟 S13 待久了会影响智商 |
 |
97
darkalien 2019-10-29 13:29:05 +08:00
能跑就行，被纠结什么代码烂不烂
|
|
98
fengchang 2019-10-29 13:29:37 +08:00
@timle1029 bug 是不可避免的，就算是飞机的控制软件也有 bug。但是有的公司会把明知有 bug 的软件「先上线，后迭代」，有的公司就不会。
|
 |
99
ieiayaobb 2019-10-29 13:30:45 +08:00 1
看了上面的回复，大多都是“我”重构以后的就是质量好的代码
|
 |
100
hantsy 2019-10-29 13:46:59 +08:00 3
国内就是这样，先跑起来再说。
某些职场的领导层面可能是受一些“成功人士”言论的影响，总幻想那些为数不多的成功案例会发生在自己身上，特别是一些创业公司，创始人像被洗过脑一样，天天做梦都想着拿到几千万的风投，就可以大干一场，然后才有时间，有能力请更多的人力来把项目推倒重来。 没有重视软件工程之前，很难改变这种状态。国内绝大部分公司没有要求写测试，没有 CI 服务器，不跑 CI，CD （当然没有测试，跑也没太多意义），开发部署流程没有全部实现自动化（或半自动化）。 敏捷是挂在嘴上的，有些公司实施 Scrum 除了开会做样子外，没有其他的，没有真正体会到每个 Sprint 结点的实践要求：除了展示阶段性成果，规划下一步，最重要就是代码重构，定期清理 Bad Smell 代码，保证代码质量。 说白了，管理层面的软件工程知识缺乏。员工也没机会去实践（当然很多人也不愿意做这些事）。 |
Select Language