这是一个创建于 1410 天前的主题，其中的信息可能已经有所发展或是发生改变。
不同的页面，相似的功能，没有抽象全是复制粘贴。想改成模版元编程或者二级指针抽象，发现又不是完全复制，都是把结构体换了个名字复制，二十几个文件顿时丧失优化兴趣。反正能跑就跑算了
 |
1
yamatamain 2021-02-20 10:07:32 +08:00
大公司的项目，没有几个是从技术层面看起来过得去的。
毕竟是“大公司”的项目。 你想通了吗？ |
 |
2
paoqi2048 2021-02-20 10:08:54 +08:00  1
又不是不能用.jpg
|
 |
3
DoctorCat 2021-02-20 10:11:42 +08:00 1
代码质量堪忧 !== 不能赚钱嘛 😂
|
 |
4
wellsc 2021-02-20 10:13:02 +08:00 1
不要去动屎山
|
 |
5
Mrun 2021-02-20 10:13:25 +08:00
别想不开啊
|
 |
6
bthulu 2021-02-20 10:15:30 +08:00 15
复制粘贴再修改一下难道不是最简单的吗? 万一以后要什么功能, 直接怼代码上去就行了. 你给抽象一下, 万一后面改功能, 你这个抽象不支持怎么办? 别总以为代码简洁就是美, 美则美矣, 却丧失了各种可能, 又有什么用?
|
 |
7
lovecy 2021-02-20 10:18:57 +08:00 4
复制粘贴再修改，付出的是人力成本，请几个应届生搞定。
抽象封装搞优化，付出的是脑力成本，找个高手费钱费力 |
 |
8
whi147 OP 加了一个算法，要修改二十几个文件
|
|
9
whi147 OP 想起以前在小公司两个人干活时，那个轻松啊。花了三个月根据业务逻辑重新开发了客户端。用了十分之一的代码完成了所有功能还增加新的功能。
|
 |
10
nicevar 2021-02-20 10:52:59 +08:00
初次进入大公司的感觉么。。。十几年前我几个同事也是这样评价公司的项目的，隔几年进来的小弟也是这样评论他们的代码的
|
 |
12
mxT52CRuqR6o5 2021-02-20 10:56:00 +08:00 7
抽象得好是需要很高的水平的，抽象不足够好有可能还不如复制粘贴呢
|
 |
13
chuckzhou 2021-02-20 11:19:55 +08:00
大公司也是从小公司成长起来的，总不能公司大了就把所有代码重构吧，而且代码的稳定性是第一位的。
|
 |
15
hxndg 2021-02-20 11:23:05 +08:00
这种现象到处都有，很正常
我现在就在重构原先的代码，只不过我们这个是 C，重构更蛋疼 |
 |
16
northisland 2021-02-20 11:24:17 +08:00 1
dont repeat yourself 有时候只是一句放哪儿都对的口号，什么水平的人都可以这么说
建议从业务初衷去理解一下工程 |
 |
17
laragh 2021-02-20 11:24:29 +08:00
@yamatamain 营销号嫌疑
|
|
18
northisland 2021-02-20 11:31:19 +08:00 4
某些概念可以在组内轻易推广时，把概念封装成执行单元，don't repeat，我觉得 ok 。
为了 don't repeat，而生硬地造处一堆概念，我觉得污染了代码的可读性、可维护性。 |
 |
19
icyalala 2021-02-20 11:32:50 +08:00
不如说越是大公司的核心代码，屎山越高。
大公司新项目，兴许还能有好一些的代码。 |
|
20
yamatamain 2021-02-20 11:35:13 +08:00
@laragh ？？？三连
|
 |
21
lwch 2021-02-20 11:36:02 +08:00 1
曾经见到过一个函数写了 2000 多行
|
 |
22
zhuangzhuang1988 2021-02-20 11:37:03 +08:00 3
别想不开, 我这几天写前端打算抽象页面的, 给 2 个项目用
尼玛折腾了 2 天还是各种报错, 直接拷贝修改 2 小时解决 |
 |
23
anthow 2021-02-20 11:37:30 +08:00
这是什么代码，改下吧 ×
算了算了，能跑就完事 √ |
 |
24
RickyC 2021-02-20 11:38:04 +08:00
人类素来远离智慧。
|
 |
25
bojackhorseman 2021-02-20 11:57:40 +08:00
@zhuangzhuang1988 #22 2333
|
 |
26
ericgui 2021-02-20 12:00:30 +08:00 6
这是我以前的微博，我再发一次：
============== 虽然轮子哥 @GeniusVczh 非常推崇 DRY 原则，但是，在某些人那里，DRY 就是个灾难，因为他没有足够的抽象能力，DRY 出来的东西就是一堆狗屎，然后每次要加新功能，就彻底重写一次；或者是每次加新功能，都要打一堆补丁，然后你发现，补丁摞补丁，终于又成了一堆屎山。 ================ 抽象过度是个问题 抽象不足也是个问题 抽象能力决定了你的抽象的普适性 |
 |
28
knightdf 2021-02-20 12:03:33 +08:00
没人会跟钱过不去
|
 |
29
jones2000 2021-02-20 12:09:17 +08:00
抽象意味着， 需要有人维护底层的抽象类， 后期抽象类增加功能或修改， 需要把所有用到这个抽象类的项目或页面都要测试一般。 换成你， 你会干吗？ 出来问题还要背锅。
|
 |
30
IsaacYoung 2021-02-20 12:11:18 +08:00
xxx.page 8000 行
|
 |
31
yuzhibopro 2021-02-20 12:14:20 +08:00
写什么模式抽象，业务不需要，理解起来麻烦，还不如堆代码。快速出活，远离 996
|
|
32
jones2000 2021-02-20 12:33:29 +08:00 2
@ericgui 预算充值，不考核，人手充足，工期充裕（设计，写注释， 重构这些也算入到工期内）。 是可以抽像的。
抽象这个东西是根据项目的开发中动态调整的。 ”抽象过度是个问题 抽象不足也是个问题 抽象能力决定了你的抽象的普适性” 你说的这个就是没有在开发中动态的去调整抽象设计，前期的抽像设计可能在开发中需要调整， 前期的抽象是基于对项目的理解和过往的经验得到的，谁也不知道在具体在开发中会遇到坑，还要考虑产部隔三差 5 加新需求， 这些都需要根据具体情况和应用调整抽像的设计，这些都可能导致前面的代码都是重写，工作量巨大。 如果没有对项目或编程有极大的爱好的人是不会这么干的。 毕竟大家都是打工的。东西能跑就可以了。 |
 |
33
matrix67 2021-02-20 12:33:37 +08:00
腾讯吃鸡游戏有两个团队在开发，字节 clubhouse 的应用有 5 个团队在开发，你看老大层面的的 don't repeat 也没实现。
|
 |
34
taogen 2021-02-20 12:48:15 +08:00
先复制粘贴实现，以后再优化，然而以后就不想优化了。所以，在代码提交之前保证代码是优化过的。但有时候，需求比较急，也就专注于快速实现，没时间去考虑代码质量了。然后，根据破窗理论，代码会有越来越多的屎山。
|
 |
35
Lemeng 2021-02-20 12:48:52 +08:00
有句俗语怎么说来着，不过也不是绝对的事。企业文化很重要
|
 |
36
levelworm 2021-02-20 13:11:17 +08:00 via Android
其实就是业务繁忙的时候赶业务，想着先做了之后优化。之后就没有时间优化了。再加上几年走一批人，后面来的能把功能顺利跑出来也不错了。这咋听起来还是网络后台程序？
|
 |
37
rodneya 2021-02-20 13:23:21 +08:00
现在的项目 重复代码就有一堆。。。组长说有空重新合并一下。。。
|
 |
38
newmlp 2021-02-20 13:34:12 +08:00
核心就是无数人堆起来的屎山，轻易不敢动的那种
|
 |
40
php01 2021-02-20 13:49:41 +08:00
这些楼层太搞笑了。
我真想知道，如果是一个小公司，这样做，楼上这些人又会怎么说。想想都要笑出猪叫 |
 |
41
sillydaddy 2021-02-20 13:53:09 +08:00 via Android
成本大于收益，所以不抽象。
可能抽象后的代码扩展性不强。 可能别人理解起来会困难。 可能抽象所需时间比较长。 可能这些代码仅仅是局部的，无关全局。 即使是涉及到架构方面的代码，还有一个权衡利弊，判断是否要重构的过程。何况其他的代码呢！ |
 |
43
atonku 2021-02-20 13:59:32 +08:00
大公司的核心业务又不是优化代码！他们首先定一个高工资，让小公司的社畜不停的骚动，然后制定一堆自己都不执行的乱七八糟的标准，去拖小公司的后退。这就是核心业务
|
 |
44
paradoxs 2021-02-20 14:03:35 +08:00 1
上次公司来了个新人，写的代码，一些基础的东西封装的挺好的。
我秒懂了，这人是培训班出来的。 真的自学科班出身，哪有这样封装的，都是能用就行。 |
 |
46
uselessVisitor 2021-02-20 14:06:58 +08:00
不写第三方框架很少用到抽象封装或者设计模式吧。。最近学了一些，感觉都很抽象
|
 |
47
zhigang1992 2021-02-20 14:07:32 +08:00
|
 |
48
quceng 2021-02-20 14:26:36 +08:00
哪个大公司啊？
|
 |
49
lakehylia 2021-02-20 14:47:57 +08:00
首先完成需求，拿到 KPI 。然后再重构，缩小代码大小，又拿到 KPI 。接着继续完成需求，循环往复。有 KPI 就有重构得动力，没有就没人愿意动。
|
 |
50
firefox12 2021-02-20 14:59:20 +08:00
XML 倒是抽象 复杂，你们怎么都去用 json ？口嫌体正直。
每一座屎山都是一段历史，没有经历过的人 真的没资格去评论。 |
 |
51
chendl111 2021-02-20 15:15:06 +08:00
能用就行.jpg
|
 |
54
coolesting 2021-02-20 15:42:33 +08:00
能运行就不重构，否则，你会无限地加班 ！！
|
 |
55
shm7 2021-02-20 15:44:33 +08:00
"没有抽象全是复制粘贴"
相信我，有时候完全以 DRY 为代码规范来写的，一样有阅读的问题。 “不同的页面，相似的功能” 假如页面变化较大，一个页面要改一个 小组件来实现，一个不要改怎么搞？ 也许这么写是比较好读又好改的折中方案呢。 |
 |
58
mapoor 2021-02-20 15:53:26 +08:00
如果核心代码抽象做的不好，那依托以此的产品可想而知，必定没有任何竞争力。
你说的核心代码真的是核心吗？ |
 |
59
Avedge 2021-02-20 15:56:43 +08:00
毕竟很多历史因素，改改说不定就扯出一堆新问题。
|
|
60
whi147 OP @mapoor 这个项目是多项目结构，也就是有 100 多个 dll，我就在其中一两个里写，有的代码封装的很好，有些代码不是
|
 |
61
stevenkang 2021-02-20 16:45:07 +08:00
优化大厂的项目，代码也不算多 14w 行左右，硬是把 sonar 扫描出来的中、高级缺陷都给消灭掉了，剩余低级缺陷不足 20 个，之前有不低于 500 多处不规范代码。
优化的过程其实对企业产生不了效益，反而增加测试同学的负担，优化的时候都是非常谨慎，生怕影响原来的代码逻辑。 现在看来，优化代码前，还是得先从单元测试入手，一步一步让屎山变为金山银山吧。 |
|
62
hxndg 2021-02-20 17:07:02 +08:00 1
@paradoxs
噗，如果这样子说的话，你像我司是三个人定好标准，只求简洁和清楚：把 OPENSSL 库封装好，然后提供各种级别调用，我们都是培训班出身呗。。。。 @northisland 从工程实践的角度有道理， 但是有的地方还真是追求强行一致性，比方说 linux 内核里面的 list_entry，page_struct 里面的 mapping 还有就是 openssl 里面的一大堆地方都是强行追求一致性 @ericgui 实际上都是先有的重复，然后才有的抽象。 |
 |
63
jsjgjbzhang 2021-02-20 17:27:57 +08:00
打江山阶段和坐班阶段能一样么
|
 |
64
tailf 2021-02-20 17:35:33 +08:00
代码是写给人看的，只是恰好能运行。
|
 |
65
OliverDD 2021-02-20 18:07:52 +08:00 1
我觉得，这只是工作，你写得再好看优美，客户看不到 boss 看不到，代码除非别人接受不然没人看得到。有那个想法爱好，课余时间去贡献贡献开源代码，那才是该写优美的地方。工作就是工作，目标驱动，何必为难自己为了设计去设计
|
 |
66
xumng123 2021-02-20 18:09:58 +08:00 via iPhone
沟通成本极高，所以能不改就不改，将就能用即可
|
 |
67
owenliang 2021-02-20 18:19:07 +08:00
打江山的代码，收益远大于表面文字
|
 |
68
going2think 2021-02-20 18:26:11 +08:00 via Android
.想搭车问一下大家，c++稍微大型点的项目规范文档哪里有呢，最近在写一些 c++项目，总感觉很不规范，想找一些文档参考一下
|
 |
69
imzcc 2021-02-20 18:54:00 +08:00 via Android
我们公司一个 typeapi 有 7.8m ，惊了
|
 |
71
timsensor 2021-02-20 18:56:04 +08:00 via Android
一切跟业务走，否则谁都不知道你干了什么
|
|
72
newmlp 2021-02-20 18:59:18 +08:00
@going2think 随便写，有没有规范都一个样 [手动滑稽]
|
 |
73
shayuvpn0001 2021-02-20 20:03:24 +08:00 1
@going2think 可以参考 Chromium 的文档，我觉得还是不错的。如果本身底子不好，人员水平又参差不齐，建议还是尽量用 Qt 这种框架，给你一个比较好的模式和舞台。
还有一些项目虽然很有名也很厉害，比如 Linux 内核的，其实不建议参考，一是为了尽可能保证效率各种骚操作多，二是历史包袱也是有点重的。 |
 |
74
jorneyr 2021-02-20 20:11:40 +08:00
IBM 的 Domino, 其中有一个 cpp 文件超过 10M，Notes 的一个核心函数 1 万多行。
|
 |
76
AndyAO 2021-02-20 20:48:09 +08:00
成熟的思考，极高的可读性，走到极致就应该是文学编程。
自从这个概念被高德纳提出并且实践以来，当前属于文学编程的低潮阶段，它比任何时候都冷。[^1] 有很多好东西是被重新发现的，所以这不排除这是未来，毕竟，对项目的质量和可维护性应该有很大提升。 [1]: Whither Literate Programming (1)/(2)/(3). |
|
77
AndyAO 2021-02-20 22:02:13 +08:00
还有就是，很好奇你说的具体是哪个「大公司」，「大」是个很模糊的词汇，如果看市值和知名度的话，可口可乐算是很大的公司，但保不齐他们的某个 IT 项目做得非常烂。
|
 |
78
abcbuzhiming 2021-02-20 22:48:11 +08:00
记得在别处看到过，google 的搜索引擎有个核心程序是 C++写的，编译出来得到的可执行文件高达 1GB ；以至于编译时的 GCC 超出内存占用，以至于那个开发组不得不魔改 GCC 来完成编译。
我个人觉得，抽象也好，各种设计模式也好，过于学术，过于完美。而现实不是完美的，所以现实的东西总是看起来这里有缺点，那里有缺点。所以我觉得，程序员尤其不能处女座 |
 |
80
chenqh 2021-02-20 22:54:26 +08:00
@abcbuzhiming 谷歌不都是 128G 内存的吗，还会内存溢出？
|
 |
81
jianghu52 2021-02-20 23:13:28 +08:00 2
说一下个人经历，接手一个小项目，不到 7 千的代码，最核心的代码超过 1 千行，写在一个文件的一个函数里面，光参数就 20+，还很多都是结构体。
这样的一个结构，领导给的时间只有一周，如果按照式样书做，就是结构体追加两个变量，然后在参数的 600 多行的位置，再追加两个判断，就能完事儿。测试也很简单，只要测试这一个结构体相关的内容就可以了。 当时年轻，总觉着自己能改变现状，于是业余时间花了快两个月的时间，自己重构这个函数，把他拆成六个相对独立的函数，同时还做了两个接口，用于外部调用。然后拿着这个解决方案给领导，本以为会受到表扬，结果被训了一顿。 领导的意思：首先，我做的拆分没有实际的根据，完全是根据现有代码逻辑来的，对于以后的业务完全没有扩展。其次，这样的拆分对于客户来说，风险远远大于收益，核心函数这样大的变化，客户的 sku 超过 2 千个，每个都要测试，但是收益只是维护的便利性增加了一点点。最后，函数级别的解耦，通常只能解决部分问题，如果要做，那么应该从整体结构就开始做解耦，单做一点，费力不说，而且效果很小。 通常历史悠久的公司，往往烂代码更多。一方面是因为当时的编程者的只是结构就是老的，一方面也是因为当时的设计根本不可能完全适合未来的变化。但是业务有时候会剧烈的变化，可是代码受限于当时的结构，就不可能剧烈的变化，于是开始有了补丁。也是技术债的产生根源。 作为程序员，在我们眼中，程序的质量高于一切。但是在商业社会，商业活动最终是利润说话的。假设一个 60 分的代码，可以提前 3 个月面世，并且每月能获得 100 万的收益，并且每月他的维护费用为 10 万，一个 90 分的代码，要晚 3 个月面世，同样收益为 100 万，每月维护费用为 1 万。你觉得你是老板会选哪个。 |
 |
82
zhc 2021-02-21 00:18:01 +08:00 via iPhone
看回复就看得出靠写代码混饭吃的还是占绝大多数。很难体到编程带来的快乐。大公司的通病说白了就是随着人员增多代码爆炸，复杂度太高的问题。好好看看英文原版的代码大全，人家早就总结出了很多经验。
|
 |
83
edimetia3d 2021-02-21 00:56:11 +08:00
开源项目要 PR,算是脸面..
内部项目你代码质量写的好是能反向 PUA leader 吗? |
 |
84
geektony 2021-02-21 01:19:51 +08:00
其实这是一个恶性循环：管理层要求短时间出成绩 -> 没有充分思考的产品决策 -> 不充裕的开发周期下的技术架构与决策 -> 坏味道代码 -> 产品没有不符合管理层预期。
要打破这个循环，要改变的是管理层的思维和决策方式还有自顶而下的协作方式。在大厂这部分基本都比较固化，前线员工是无法改变体制的。这是出现的 side-effect 就是，前线员工一边骂着老板傻逼，一般要加班加点干出实现逻辑，各种技术决策开始折中妥协。后来加入的人又再循环，“在屎上面继续拉屎”。 回到管理层的问题，其实是企业文化的反应，而企业文化又不是一时半刻形成的，更不可能被前线员工，甚至中层管理者可以撼动的。如果你能忍受，可以继续待下去。如果不能，那就找适合自己的环境。 这样看来，我们的编码规范、原则和思想都可以通过人和时间完善。但是在冰山下隐藏的，本质上不是技术问题，而是协同与管理的问题。 |
 |
85
CastleBUPT 2021-02-21 01:28:35 +08:00 via iPhone
楼上们说的抽象不足的 DRY 是啥意思啊，重复代码又是怎么保证甚至提高抽象性的啊，我怎么看不懂你们说的，去哪儿能买到你们的著作？就问一件事，如果业务改动导致要在重复代码中间加一行，你们打算怎么做啊，是找到所有重复代码然后粘贴这一行吗？
|
|
86
ericgui 2021-02-21 04:04:00 +08:00
@abcbuzhiming 我是处女座
|
 |
87
chinuno 2021-02-21 09:09:08 +08:00 via Android
同样安防写 c 艹的说说我的想法吧。新旧项目都做过，发现代码越来越烂是必然的结果。
一开始架构设计一般来说问题都不大，都是最切合立项时的需求的，一般设计上的问题在第一个版本做出来的时候不太还会存在了。 问题出在项目的后续需求演变，首先公司的人员流动性很高，项目的维护者没多久就要换一批。前期架构不管设计得多好这个时候就要看接手人的水平了。能够理解一开始设计架构的思路跟着做下去就很好，这种情况最舒服了，有问题好改好排查，结构清晰节省时间。水平不够的对不上架构电波的就自己发挥随便乱拉屎了，从这个时候开始整个项目就被屎污染了，后面维护的人只能跟着继续搅屎。这两种情况我都遇到过，真的是最真实的体验了。 再一个问题是客户端需求奇葩。安防行业的客户专业的很专业，不专业的就。很任性，一定要你照他说的做，特别强硬。经常会出现毫无意义浪费资源，但是客户坚持要的功能。这种奇葩需求前期设计的时候是根本无法预见到的，所以为了应付客户只能跳出框架挂个屎包补丁。 不说客户端奇葩需求，正常需求也很麻烦。同样一套系统对不同用户都要做不同的定制，这些修改往往都是不通用的不好抽象的。这样导致的情况就是一个定制版本就是一套系统复制粘贴稍作修改，看起来大部分东西都一样，但是就是抽象整合不出来。 其实就我感觉行业内的东西都是一样烂，天天跟友商做对接感觉就很明显了，都是系统天天出问题，从来没有稳定过。不是公司核心业务也根本不会投入资源去给你做重构的，能用就行。 |
 |
88
Cbdy 2021-02-21 09:26:08 +08:00 via Android
瞎抽象不如不抽象，现在很多程序员都是干苦力，软件能跑能赚钱就行，要啥自行车
|
|
89
whi147 OP @chinuno 现在客户都反馈界面 ui 比几年前慢，可以看出第一版时期的开发者还是有考虑用户体验的，后面出现国际化版本（多个国家）后人员激增，就破坏原有设计了
|
 |
90
dorothyREN 2021-02-21 10:42:11 +08:00
大公司要突出一个大字啊，不复制粘贴怎么能体现出来呢
|
 |
91
JoStar 2021-02-21 11:32:43 +08:00
之前看过一篇文章，也是关于代码简洁问题的
出自 react redux 核心开发者的文章 https://overreacted.io/zh-hans/goodbye-clean-code/ 代码简洁这个问题，还是要找一个平衡点，要抽象也要解耦。 |
 |
92
jinsongzhao 2021-02-21 12:17:02 +08:00
吐槽归吐槽,调侃归调侃, 娱乐过后, 是一地鸡毛, 还是像钱学森的故事一样, 放下国内远远达不到精度的工艺, 依旧实现了目标. 工程本来就无法完美,再完美的理论也要适配精度.
|
|
94
bthulu 2021-02-22 09:03:48 +08:00
@CastleBUPT 是的, IDE 中正则搜索添加, 不到一分钟搞定
|
Select Language