大公司的核心项目代码也不是那么美好（c++）

• 資深大佬 : yamatamain

  大公司的项目，没有几个是从技术层面看起来过得去的。
  毕竟是“大公司”的项目。
  你想通了吗？

• 資深大佬 : paoqi2048

  又不是不能用.jpg

• 資深大佬 : DoctorCat

  代码质量堪忧 !== 不能赚钱嘛

• 資深大佬 : wellsc

  不要去动屎山

• 資深大佬 : Mrun

  别想不开啊

• 資深大佬 : bthulu

  复制粘贴再修改一下难道不是最简单的吗? 万一以后要什么功能, 直接怼代码上去就行了. 你给抽象一下, 万一后面改功能, 你这个抽象不支持怎么办? 别总以为代码简洁就是美, 美则美矣, 却丧失了各种可能, 又有什么用?

• 資深大佬 : lovecy

  复制粘贴再修改，付出的是人力成本，请几个应届生搞定。
  抽象封装搞优化，付出的是脑力成本，找个高手费钱费力

• 主 資深大佬 : whi147

  加了一个算法，要修改二十几个文件

• 主 資深大佬 : whi147

  想起以前在小公司两个人干活时，那个轻松啊。花了三个月根据业务逻辑重新开发了客户端。用了十分之一的代码完成了所有功能还增加新的功能。

• 資深大佬 : nicevar

  初次进入大公司的感觉么。。。十几年前我几个同事也是这样评价公司的项目的，隔几年进来的小弟也是这样评论他们的代码的

• 主 資深大佬 : whi147

  @nicevar 哈哈。后浪前浪都死在沙滩上

• 資深大佬 : mxT52CRuqR6o5

  抽象得好是需要很高的水平的，抽象不足够好有可能还不如复制粘贴呢

• 資深大佬 : chuckzhou

  大公司也是从小公司成长起来的，总不能公司大了就把所有代码重构吧，而且代码的稳定性是第一位的。

• 資深大佬 : sakura1

  @wellsc 屎山可太贴切了

• 資深大佬 : hxndg

  这种现象到处都有，很正常
  我现在就在重构原先的代码，只不过我们这个是 C，重构更蛋疼

• 資深大佬 : northisland

  dont repeat yourself 有时候只是一句放哪儿都对的口号，什么水平的人都可以这么说

  建议从业务初衷去理解一下工程

• 資深大佬 : laragh

  @yamatamain 营销号嫌疑

• 資深大佬 : northisland

  某些概念可以在组内轻易推广时，把概念封装成执行单元，don’t repeat，我觉得 ok 。

  为了 don’t repeat，而生硬地造处一堆概念，我觉得污染了代码的可读性、可维护性。

• 資深大佬 : icyalala

  不如说越是大公司的核心代码，屎山越高。
  大公司新项目，兴许还能有好一些的代码。

• 資深大佬 : yamatamain

  @laragh ？？？三连

• 資深大佬 : lwch

  曾经见到过一个函数写了 2000 多行

• 資深大佬 : zhuangzhuang1988

  别想不开, 我这几天写前端打算抽象页面的, 给 2 个项目用
  尼玛折腾了 2 天还是各种报错,
  直接拷贝修改 2 小时解决

• 資深大佬 : anthow

  这是什么代码，改下吧 ×
  算了算了，能跑就完事 √

• 資深大佬 : RickyC

  人类素来远离智慧。

• 資深大佬 : bojackhorseman

  @zhuangzhuang1988 #22 2333

• 資深大佬 : ericgui

  这是我以前的微博，我再发一次：

  ==============

  虽然轮子哥 @GeniusVczh 非常推崇 DRY 原则，但是，在某些人那里，DRY 就是个灾难，因为他没有足够的抽象能力，DRY 出来的东西就是一堆狗屎，然后每次要加新功能，就彻底重写一次；或者是每次加新功能，都要打一堆补丁，然后你发现，补丁摞补丁，终于又成了一堆屎山。 ​​​​

  ================

  抽象过度是个问题
  抽象不足也是个问题
  抽象能力决定了你的抽象的普适性

• 資深大佬 : ericgui

  @lwch 我们一个 UI 的 container，1300+行

• 資深大佬 : knightdf

  没人会跟钱过不去

• 資深大佬 : jones2000

  抽象意味着， 需要有人维护底层的抽象类， 后期抽象类增加功能或修改， 需要把所有用到这个抽象类的项目或页面都要测试一般。 换成你， 你会干吗？ 出来问题还要背锅。

• 資深大佬 : IsaacYoung

  xxx.page 8000 行

• 資深大佬 : yuzhibopro

  写什么模式抽象，业务不需要，理解起来麻烦，还不如堆代码。快速出活，远离 996

• 資深大佬 : jones2000

  @ericgui 预算充值，不考核，人手充足，工期充裕（设计，写注释， 重构这些也算入到工期内）。 是可以抽像的。
  抽象这个东西是根据项目的开发中动态调整的。

  ”抽象过度是个问题
  抽象不足也是个问题
  抽象能力决定了你的抽象的普适性” 你说的这个就是没有在开发中动态的去调整抽象设计，前期的抽像设计可能在开发中需要调整， 前期的抽象是基于对项目的理解和过往的经验得到的，谁也不知道在具体在开发中会遇到坑，还要考虑产部隔三差 5 加新需求， 这些都需要根据具体情况和应用调整抽像的设计，这些都可能导致前面的代码都是重写，工作量巨大。 如果没有对项目或编程有极大的爱好的人是不会这么干的。 毕竟大家都是打工的。东西能跑就可以了。

• 資深大佬 : matrix67

  腾讯吃鸡游戏有两个团队在开发，字节 clubhouse 的应用有 5 个团队在开发，你看老大层面的的 don’t repeat 也没实现。

• 資深大佬 : taogen

  先复制粘贴实现，以后再优化，然而以后就不想优化了。所以，在代码提交之前保证代码是优化过的。但有时候，需求比较急，也就专注于快速实现，没时间去考虑代码质量了。然后，根据破窗理论，代码会有越来越多的屎山。

• 資深大佬 : Lemeng

  有句俗语怎么说来着，不过也不是绝对的事。企业文化很重要

• 資深大佬 : levelworm

  其实就是业务繁忙的时候赶业务，想着先做了之后优化。之后就没有时间优化了。再加上几年走一批人，后面来的能把功能顺利跑出来也不错了。这咋听起来还是网络后台程序？

• 資深大佬 : rodneya

  现在的项目 重复代码就有一堆。。。组长说有空重新合并一下。。。

• 資深大佬 : newmlp

  核心就是无数人堆起来的屎山，轻易不敢动的那种

• 資深大佬 : newmlp

  @lwch 我见过 5000 行的，

• 資深大佬 : php01

  这些层太搞笑了。
  我真想知道，如果是一个小公司，这样做，上这些人又会怎么说。想想都要笑出猪叫

• 資深大佬 : sillydaddy

  成本大于收益，所以不抽象。

  可能抽象后的代码扩展性不强。
  可能别人理解起来会困难。
  可能抽象所需时间比较长。
  可能这些代码仅仅是局部的，无关全局。

  即使是涉及到架构方面的代码，还有一个权衡利弊，判断是否要重构的过程。何况其他的代码呢！

• 資深大佬 : TimRChen

  @bthulu 什么都不做肯定是没问题的，敢于尝试的都是错的。doge

• 資深大佬 : atonku

  大公司的核心业务又不是优化代码！他们首先定一个高工资，让小公司的社畜不停的骚动，然后制定一堆自己都不执行的乱七八糟的标准，去拖小公司的后退。这就是核心业务

• 資深大佬 : paradoxs

  上次公司来了个新人，写的代码，一些基础的东西封装的挺好的。

  我秒懂了，这人是培训班出来的。

  真的自学科班出身，哪有这样封装的，都是能用就行。

• 資深大佬 : dwSun

  @atonku #43 这就是 google 在干的事情，所以我一直觉得要远离 google 的产品

• 資深大佬 : beichenhpy

  不写第三方框架很少用到抽象封装或者设计模式吧。。最近学了一些，感觉都很抽象

• 資深大佬 : zhigang1992

  https://overreacted.io/the-wet-codebase/

• 資深大佬 : quceng

  哪个大公司啊？

• 資深大佬 : lakehylia

  首先完成需求，拿到 KPI 。然后再重构，缩小代码大小，又拿到 KPI 。接着继续完成需求，循环往复。有 KPI 就有重构得动力，没有就没人愿意动。

• 資深大佬 : firefox12

  XML 倒是抽象 复杂，你们怎么都去用 json ？口嫌体正直。

  每一座屎山都是一段历史，没有经历过的人 真的没资格去评论。

• 資深大佬 : chendl111

  能用就行.jpg

• 主 資深大佬 : whi147

  @atonku 厉害

• 主 資深大佬 : whi147

  @quceng 安防行业
• 資深大佬 : coolesting

  能运行就不重构，否则，你会无限地加班 ！！

• 資深大佬 : shm7

  “没有抽象全是复制粘贴”
  相信我，有时候完全以 DRY 为代码规范来写的，一样有阅读的问题。

  “不同的页面，相似的功能” 假如页面变化较大，一个页面要改一个 小组件来实现，一个不要改怎么搞？

  也许这么写是比较好读又好改的折中方案呢。

• 資深大佬 : zjl03505

  @whi147 #53 你说到安防行业，行业领头的那两三个确实远远比不上一般的互联网大公司。

• 主 資深大佬 : whi147

  @zjl03505 对啊，写的也不是很舒服

• 資深大佬 : mapoor

  如果核心代码抽象做的不好，那依托以此的产品可想而知，必定没有任何竞争力。
  你说的核心代码真的是核心吗？

• 資深大佬 : Avedge

  毕竟很多历史因素，改改说不定就扯出一堆新问题。

• 主 資深大佬 : whi147

  @mapoor 这个项目是多项目结构，也就是有 100 多个 dll，我就在其中一两个里写，有的代码封装的很好，有些代码不是

• 資深大佬 : stevenkang

  优化大厂的项目，代码也不算多 14w 行左右，硬是把 sonar 扫描出来的中、高级缺陷都给消灭掉了，剩余低级缺陷不足 20 个，之前有不低于 500 多处不规范代码。

  优化的过程其实对企业产生不了效益，反而增加测试同学的负担，优化的时候都是非常谨慎，生怕影响原来的代码逻辑。

  现在看来，优化代码前，还是得先从单元测试入手，一步一步让屎山变为金山银山吧。

• 資深大佬 : hxndg

  @paradoxs
  噗，如果这样子说的话，你像我司是三个人定好标准，只求简洁和清楚：把 OPENSSL 库封装好，然后提供各种级别调用，我们都是培训班出身呗。。。。
  @northisland
  从工程实践的角度有道理，
  但是有的地方还真是追求强行一致性，比方说 linux 内核里面的 list_entry，page_struct 里面的 mapping 还有就是 openssl 里面的一大堆地方都是强行追求一致性

  @ericgui
  实际上都是先有的重复，然后才有的抽象。

• 資深大佬 : jsjgjbzhang

  打江山阶段和坐班阶段能一样么

• 資深大佬 : tailf

  代码是写给人看的，只是恰好能运行。

• 資深大佬 : OliverDD

  我觉得，这只是工作，你写得再好看优美，客户看不到 boss 看不到，代码除非别人接受不然没人看得到。有那个想法爱好，课余时间去贡献贡献开源代码，那才是该写优美的地方。工作就是工作，目标驱动，何必为难自己为了设计去设计

• 資深大佬 : xumng123

  沟通成本极高，所以能不改就不改，将就能用即可

• 資深大佬 : owenliang

  打江山的代码，收益远大于表面文字

• 資深大佬 : going2think

  .想搭车问一下大家，c++稍微大型点的项目规范文档哪里有呢，最近在写一些 c++项目，总感觉很不规范，想找一些文档参考一下

• 資深大佬 : imzcc

  我们公司一个 typeapi 有 7.8m ，惊了

• 資深大佬 : imzcc

  @imzcc Java class

• 資深大佬 : timsensor

  一切跟业务走，否则谁都不知道你干了什么

• 資深大佬 : newmlp

  @going2think 随便写，有没有规范都一个样 [手动滑稽]

• 資深大佬 : shayuvpn0001

  @going2think 可以参考 Chromium 的文档，我觉得还是不错的。如果本身底子不好，人员水平又参差不齐，建议还是尽量用 Qt 这种框架，给你一个比较好的模式和舞台。

  还有一些项目虽然很有名也很厉害，比如 Linux 内核的，其实不建议参考，一是为了尽可能保证效率各种骚操作多，二是历史包袱也是有点重的。

• 資深大佬 : jorneyr

  IBM 的 Domino, 其中有一个 cpp 文件超过 10M，Notes 的一个核心函数 1 万多行。

• 資深大佬 : melkor

  @whi147 小公司业务和大公司业务的复杂度和历史包袱不可相比吧

• 資深大佬 : AndyAO

  成熟的思考，极高的可读性，走到极致就应该是文学编程。
  自从这个概念被高德纳提出并且实践以来，当前属于文学编程的低潮阶段，它比任何时候都冷。[^1]
  有很多好东西是被重新发现的，所以这不排除这是未来，毕竟，对项目的质量和可维护性应该有很大提升。

  [1]: Whither Literate Programming (1)/(2)/(3).

• 資深大佬 : AndyAO

  还有就是，很好奇你说的具体是哪个「大公司」，「大」是个很模糊的词汇，如果看市值和知名度的话，可口可乐算是很大的公司，但保不齐他们的某个 IT 项目做得非常烂。

• 資深大佬 : abcbuzhiming

  记得在别处看到过，google 的搜索引擎有个核心程序是 C++写的，编译出来得到的可执行文件高达 1GB ；以至于编译时的 GCC 超出内存占用，以至于那个开发组不得不魔改 GCC 来完成编译。

  我个人觉得，抽象也好，各种设计模式也好，过于学术，过于完美。而现实不是完美的，所以现实的东西总是看起来这里有缺点，那里有缺点。所以我觉得，程序员尤其不能处女座

• 資深大佬 : chenqh

  @paradoxs 你这在黑谁呀？怎么感觉都黑了

• 資深大佬 : chenqh

  @abcbuzhiming 谷歌不都是 128G 内存的吗，还会内存溢出？

• 資深大佬 : jianghu52

  说一下个人经历，接手一个小项目，不到 7 千的代码，最核心的代码超过 1 千行，写在一个文件的一个函数里面，光参数就 20+，还很多都是结构体。
  这样的一个结构，领导给的时间只有一周，如果按照式样书做，就是结构体追加两个变量，然后在参数的 600 多行的位置，再追加两个判断，就能完事儿。测试也很简单，只要测试这一个结构体相关的内容就可以了。
  当时年轻，总觉着自己能改变现状，于是业余时间花了快两个月的时间，自己重构这个函数，把他拆成六个相对独立的函数，同时还做了两个接口，用于外部调用。然后拿着这个解决方案给领导，本以为会受到表扬，结果被训了一顿。
  领导的意思：首先，我做的拆分没有实际的根据，完全是根据现有代码逻辑来的，对于以后的业务完全没有扩展。其次，这样的拆分对于客户来说，风险远远大于收益，核心函数这样大的变化，客户的 sku 超过 2 千个，每个都要测试，但是收益只是维护的便利性增加了一点点。最后，函数级别的解耦，通常只能解决部分问题，如果要做，那么应该从整体结构就开始做解耦，单做一点，费力不说，而且效果很小。
  通常历史悠久的公司，往往烂代码更多。一方面是因为当时的编程者的只是结构就是老的，一方面也是因为当时的设计根本不可能完全适合未来的变化。但是业务有时候会剧烈的变化，可是代码受限于当时的结构，就不可能剧烈的变化，于是开始有了补丁。也是技术债的产生根源。
  作为程序员，在我们眼中，程序的质量高于一切。但是在商业社会，商业活动最终是利润说话的。假设一个 60 分的代码，可以提前 3 个月面世，并且每月能获得 100 万的收益，并且每月他的维护费用为 10 万，一个 90 分的代码，要晚 3 个月面世，同样收益为 100 万，每月维护费用为 1 万。你觉得你是老板会选哪个。

• 資深大佬 : zhc

  看回复就看得出靠写代码混饭吃的还是占绝大多数。很难体到编程带来的快乐。大公司的通病说白了就是随着人员增多代码爆炸，复杂度太高的问题。好好看看英文原版的代码大全，人家早就总结出了很多经验。

• 資深大佬 : edimetia3d

  开源项目要 PR,算是脸面..

  内部项目你代码质量写的好是能反向 PUA leader 吗?

• 資深大佬 : geektony

  其实这是一个恶性循环：管理层要求短时间出成绩 -> 没有充分思考的产品决策 -> 不充裕的开发周期下的技术架构与决策 -> 坏味道代码 -> 产品没有不符合管理层预期。

  要打破这个循环，要改变的是管理层的思维和决策方式还有自顶而下的协作方式。在大厂这部分基本都比较固化，前线员工是无法改变体制的。这是出现的 side-effect 就是，前线员工一边骂着老板傻逼，一般要加班加点干出实现逻辑，各种技术决策开始折中妥协。后来加入的人又再循环，“在屎上面继续拉屎”。

  回到管理层的问题，其实是企业文化的反应，而企业文化又不是一时半刻形成的，更不可能被前线员工，甚至中层管理者可以撼动的。如果你能忍受，可以继续待下去。如果不能，那就找适合自己的环境。

  这样看来，我们的编码规范、原则和思想都可以通过人和时间完善。但是在冰山下隐藏的，本质上不是技术问题，而是协同与管理的问题。

• 資深大佬 : CastleBUPT

  上们说的抽象不足的 DRY 是啥意思啊，重复代码又是怎么保证甚至提高抽象性的啊，我怎么看不懂你们说的，去哪儿能买到你们的著作？就问一件事，如果业务改动导致要在重复代码中间加一行，你们打算怎么做啊，是找到所有重复代码然后粘贴这一行吗？

• 資深大佬 : ericgui

  @abcbuzhiming 我是处女座

• 資深大佬 : chinuno

  同样安防写 c 艹的说说我的想法吧。新旧项目都做过，发现代码越来越烂是必然的结果。
  一开始架构设计一般来说问题都不大，都是最切合立项时的需求的，一般设计上的问题在第一个版本做出来的时候不太还会存在了。
  问题出在项目的后续需求演变，首先公司的人员流动性很高，项目的维护者没多久就要换一批。前期架构不管设计得多好这个时候就要看接手人的水平了。能够理解一开始设计架构的思路跟着做下去就很好，这种情况最舒服了，有问题好改好排查，结构清晰节省时间。水平不够的对不上架构电波的就自己发挥随便乱拉屎了，从这个时候开始整个项目就被屎污染了，后面维护的人只能跟着继续搅屎。这两种情况我都遇到过，真的是最真实的体验了。
  再一个问题是客户端需求奇葩。安防行业的客户专业的很专业，不专业的就。很任性，一定要你照他说的做，特别强硬。经常会出现毫无意义浪费资源，但是客户坚持要的功能。这种奇葩需求前期设计的时候是根本无法预见到的，所以为了应付客户只能跳出框架挂个屎包补丁。
  不说客户端奇葩需求，正常需求也很麻烦。同样一套系统对不同用户都要做不同的定制，这些修改往往都是不通用的不好抽象的。这样导致的情况就是一个定制版本就是一套系统复制粘贴稍作修改，看起来大部分东西都一样，但是就是抽象整合不出来。
  其实就我感觉行业内的东西都是一样烂，天天跟友商做对接感觉就很明显了，都是系统天天出问题，从来没有稳定过。不是公司核心业务也根本不会投入资源去给你做重构的，能用就行。

• 資深大佬 : Cbdy

  瞎抽象不如不抽象，现在很多程序员都是干苦力，软件能跑能赚钱就行，要啥自行车

• 主 資深大佬 : whi147

  @chinuno 现在客户都反馈界面 ui 比几年前慢，可以看出第一版时期的开发者还是有考虑用户体验的，后面出现国际化版本（多个国家）后人员激增，就破坏原有设计了

• 資深大佬 : dorothyREN

  大公司要突出一个大字啊，不复制粘贴怎么能体现出来呢

• 資深大佬 : JoStar

  之前看过一篇文章，也是关于代码简洁问题的

  出自 react redux 核心开发者的文章
  https://overreacted.io/zh-hans/goodbye-clean-code/

  代码简洁这个问题，还是要找一个平衡点，要抽象也要解耦。

• 資深大佬 : jinsongzhao

  吐槽归吐槽,调侃归调侃, 娱乐过后, 是一地鸡毛, 还是像钱学森的故事一样, 放下国内远远达不到精度的工艺, 依旧实现了目标. 工程本来就无法完美,再完美的理论也要适配精度.

• 資深大佬 : l00t

  @zhc #82 编程有啥快乐的。程序员的快乐是创造，不是书法。创造体现在产出新的能做到什么什么的产品，而不是怎样写出一个产品。

• 資深大佬 : bthulu

  @CastleBUPT 是的, IDE 中正则搜索添加, 不到一分钟搞定