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

[whi147]

不同的页面，相似的功能，没有抽象全是复制粘贴。想改成模版元编程或者二级指针抽象，发现又不是完全复制，都是把结构体换了个名字复制，二十几个文件顿时丧失优化兴趣。反正能跑就跑算了

[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 中正则搜索添加, 不到一分钟搞定