论添加一行代码需要付出多少努力

[roundRobin]

需求是需要在某一行计算费用总和的代码中除去某一项费用，就是类似加一行

totalfee -= excluded_fee

这个需求是公司的税务部门提出的，说这个费用必须免除。PM ，TPM ，SDM 们经过一周的开会后确定必须免除，于是让我开始写 LLD 和 LoE 。

然后我花了一天研究这个excluded_fee的是否在任何情况下都等于要求免除的费用，免除的费用是否能够同步到所有的数据库，中间是否存在数据不同步所导致的错误计算的可能。LLD 和 LoE 写好后开始分别找：

1. 这个 calculator 的 up stream
2. 这项费用的 down stream
3. 这个 total fee 的 down stream
4. 公司会计部门
5. 公司的会计工程部门（会计相关的 service 开发）
6. 公司税务部门
7. 公司的税务工程部门（税务相关的 service 开发）
8. 组内的 stake holder 们

在两周的时间里，开了无数会，写了无数个 meeting notes ，deployment plan 也因为 prime day 改了无数次，最终才得到所有的 approval 。

昨天一边吃止痛药一边花了一个小时的时间完成了代码修改和测试，接下来，这个 CR 需要再让他们 approva 一遍，才能部署。

这个漫长的过程，到底体现了流程的严谨，还是有太多的冗余步骤呢，过程中自己好像变成了 TPM ，跟各个部门扯皮较劲，心累不已。

一觉醒来竟然这么多提醒，感谢大家的热情，统一回复下：
- 有些同学已经猜到是什么公司了，将近十年前的屎山代码，甚至都没用 AWS
- LLD：low level design
- LoE: Level of Effort
- 我以前干的活肯定是要比写这一行代码多的， 发这个贴也是因为现在写的代码越来越少，写这种文档/proposal 的时间越来越多了，所以才感慨一下，以后估计这是常态了，我的老板也很体谅我能在两周内 onboard 一个需要沟通这么多部门的需求，这点可能国内做不到吧
- 桌面只是供君一笑，偶尔摸鱼做点 project 也是很正常的吧 lol

[zcf0508]

代码是为了业务服务的

[Vtwoguest]

yyyy-MM-dd hh:mm:ss ⇨ yyyy-MM-dd 00：00:00
就改这半个变量 得提申请 得做十多个文档 经过 4.5 轮 review 部署也要提申请

[noahlias]

越大的公司越是能发现牵一发动全身😄 流程复杂哈哈

[kmyzzy]

楼主亚麻的吧？大公司都这样。

[0xsui]

@Vtwoguest 这都是抠脚程序员留下的坑。

[0xsui]

@Vtwoguest 这样才能养更多的文职人员

[liprais]

十多年前在创业公司改类似的是快，半天就改完了
结果过了半年税务局来了让补交税说不能都扣除.....

[estk]

楼主谨慎是对的
有些中国老板，看到代码量会觉得这是摸鱼，还好楼主的公司应该不是这种文化

[opengps]

金融业务需要严谨，要不然一行代码毁掉一个公司不是问题，这种案例不是没有。。。

[buxudashi]

下次再说要打个折。涉及到对账，涉及到小数点后两位的精度。接着搞

[yhm2046]

建议改成“在大厂改一行代码需要走多少流程和时间”

[powerman]

不搞这么多流程怎么摸鱼呢，其实国内的程序猿并不讨厌繁琐的流程，讨厌的是繁琐的流程需要消耗太多的时间，但是老板又不给这些时间买单，简而言之这些时间 浪费的都是自己的，当然厌恶的很

[hez2010]

一切现有的制度都是前面的教训总结下来的。
如果没有这么多流程的话，你轻松一行改完 commit 进去出事故了，那恭喜你喜提权责。
之所以有这么多的流程，一方面是为了尽可能把更改提前通知到所有人，另一方面也是为了把责任分散到整个团队，这样出问题了责任不会全都落在你一个人头上。

[hez2010]

@hez2010 这样万一真的出了问题，结论也是：“这个问题非常的隐蔽，尽管我们已经使用了一切手段来避免问题的发生，但是还是发生了，这是没有办法的事情”。

[kneo]

这种东西，能不改最好不改。非要改，最好有界面能给用户加一个选项。没有选项，在展示结果的时候最好说明已扣除某费用。这条说明可以在几年后删掉。

要谁说改就改才是离了大谱。

[murmur]

复用度越高的逻辑越不敢动，宁可加参数，复制一份，也别轻易动

[1062740012]

这个是正确严谨的流程，改代码容易，但是影响的范围，会对业务造成的影响，这些都是要通过 meeting 后才能确定，并且这也是为了规避责任的一部分，否则出事了责任归属就是个问题了。

[leighton]

CR 暴露了楼主蕉厂员工

[kratosmy]

为什么你可以有五台显示器😂

[orioleq]

你们的系统好搞笑，减个费用不是改个配置就行而是要加一代码…你们是个小工具级别的系统么？啥都是写死的？
我觉得增加一项费用减免，从业务角度上需要讨论两周是合理的，技术要在上面耗两周，是不是要先反思下自己系统不是可配置的。

[renmu]

大公司病

[guanzhangzhang]

🙈注释有写吗

[majula]

大厂是这样的

之前在大厂做内部系统的时候，就连“修正界面上错别字”这种不涉及任何逻辑变更的改动，都需要分别找十几个业务方同步，等他们都确认无影响后才能上线，共耗时 5 个工作日。可想而知，那些涉及到逻辑变更的改动，要多久才能上线

至于为什么要这么做，那就不得不提当年的生产事故。有个业务方在获取数据的时候不去调 rpc 接口，而是直接爬 web 页面。有次我们修改了文案而没有通知下游，导致他们的爬虫获取到的数据错乱，影响生产环境，直接损失数百万元。最后我们全组背锅，绩效 C （意味着年终奖少了 10k+，而且一年内没有晋升资格）。那个业务方也没好到哪里去，据说裁了十几人

[chaorenzhuce]

当然是流程的严谨，建立这些流程一定是经过了血的教训，大公司之所以是大公司，就因为这些流程是有价值的，靠流程规避人性的风险，你看哪家大公司没有流程管理部门，真当老板们是傻逼吗

[youthfire]

微信：所以我早就说了 :D

[yagamil]

所以在大厂，大部分都是螺丝钉。

[xiangyuecn]

无所吊谓，就算是拉屎也得付薪水，开一礼拜会也不是不可以

[akira]

啥都不管直接上当然也可以啊。。后面各种账目对不齐的时候，花的 可就不是 2 周时间了

[forvvvv123]

LLD 和 LoE 是什么意思？

[keepwalk2020]

你干的这活有必要用 5 个显示器+两台笔记本么？
只看你的硬件配置，就知道是个形式主义+大公司病流行的公司。

但是，你改的那行代码确实需要这么到哦手续审核

[keepwalk2020]

你改的其实不是程序，而是付款流程，当然需要严格审核，如果你仍认为你改的只是一行代码，说明你还有很大成长空间

[keepwalk2020]

发起改这行代码的流程其实应该是自上而下，他们开完会，你负责删代码，根本没你多少事。
但是依你说的情况，发起改这行代码的过程是自下而上，当然会把事情搞得复杂，而且无形之中你可能给自己挖了一个坑你还不知道...

[wenyuhe]

@powerman 不能赞同更多，有些流程看似繁琐，其实只是正规流程。国内程序员不喜欢流程的本质就是流程上的耗时不算工作内容，而且很多小老板小 leade 喜欢处于“划算”的角度砍掉应有的流程。

[suuuch]

税务提出来的，可能是跟税收减免相关的，税务这玩意没弄好，被认定是故意的，那是可以把税务部门的审核人员给送进去的。。。。这人家怎么可能随便操作。

[LonelyChristmas]

@0xsui #6 非常对，开发第一版功能不注重代码质量，堆起的屎山可以推动很多项目，比如重构，比如各种 PMO 介入。要是一开始做好了，也就没后面人的事了，但是也体现不了初版设计的优越性，所以每次看到屎山我都用扁鹊三兄弟的故事提醒自己，出了问题再找我，否则不管。

[lookStupiToForce]

你对待这个变更的流程和态度是对的。

至于耗时费力，这其实暴露了 [现有的代码框架、工具、流程/你们使用的代码框架、工具、流程，无法很好地穿透单个变量的计算流程，以做到明晰化]

我以前就遇过这种问题，一个变量被引用来引用去，在各个类里继承来继承去，每次引用/继承还附带不知道多少道的转手解释或者过渡用计算。最后整个计算流程散落在 N 个人负责的不同子项目里，问谁谁都不懂这玩意儿咋来的，谁都不知道全局。
除非有完整经历以上所有过程的 code review 的总项目负责人，否则这就是个禁忌的薛定谔猫箱，谁都不敢打包票我输入进去啥，出来的对应玩意儿能按照我理解的概率可能来分布。

何解？
试想一下，现在有了 AI ，或者以后有了 AGI ，每次这种 引用+后继计算 时，都有一个 AI 来总结计算内容、计算逻辑、变量来源、变量边界条件、输入输出范围、输入输出意义，那么变成上面这种烂摊子的几率就会小很多

[wolfie]

第一次看到 横排 5 个显示器的，能多发几张桌面图？

[zkqiang]

所以为什么要那么多个屏幕...

[corcre]

@zkqiang 当然是为了玩 Command Line Train 啊🐶🐶

[0xsui]

@LonelyChristmas 好，事不关己高高挂起，学会了，睁一只眼闭一只眼。

[0xsui]

@forvvvv123 long lost distance running （ LLD ）长距离高消耗训练，一种全新的马拉松训练方式，很新颖的训练方式。这中说话表达方式，就跟现实工作中，两句话五六个英文单词那种装大以巴狼的差不多，好好说话就没法跟别人产生差距和优越感了，你问他缩写全程怎么说，他还得现翻手机查半天。

[woodfizky]

你这个其实不是代码层面的技术问题，代码好改。
这个应该是程序员以外的部门需要做的事情，而且这流程也太长了，真就大公司病呗。。

[msg7086]

@orioleq #20 像密林这样大的系统，这么小的东西怎么可能都做成配置。
真要做成配置，那也应该是现在提需求把这个减不减费用的旗标做成配置，然后上下加个 if 判断，检查配置然后再减。但是楼主都说了讨论完以后决定这个费用「必须」免除，也就是根本不存在需要做成配置并且手动切换的必要，所以根本就不应该做成配置。
这就只是纯粹的业务逻辑的 bug ，然后 bug 被修正。不存在说一个 bug 要不要触发需要配置文件来控制。以及如果这里配置文件就可以改了修掉 bug 的话，那说明他们知道这个费用不应该加上，那么一开始就不会有这个 bug 。

这种时候谈配置只能说是纯粹的马后炮行为了。

哦，改配置和改代码一样，也是要走 change request 并且公司老老小小负责人批准的。你不会以为改源码要测试要批准，改配置就不需要同等强度的测试和批准了吧。

[orioleq]

@msg7086 我没说减免费用这一条改配置。我说的是整个费用的每行条目都应该是配置。另外所谓配置包含数据，公式等等，数据和系统应该是分离的。程序员管好系统逻辑，业务负责数据和配置。更改流程如果需要改代码程序员负责，如果改配置只需要业务负责。测试肯定是要测的，别带上开发就行。业务拉上测试自己去搞。
而且现在的问题是，程序员自己都觉得不爽的事情来抱怨了，那就是一开始的设计没做好，理想状态下肯定是需要重构的，不然难道下次再加个费用程序员再跟着耗两周？
最后，密林是啥？

[zhtyytg]

@0xsui #41 幽默，点了

[fredweili]

太正常了，做正经的企业开发就是要搞清业务

[msg7086]

@orioleq 密林？亚马逊啊。
一开始设计没做好正常，人家系统都多少年了。别说亚马逊了，我司都一大堆十几年甚至二十几年前的代码还在跑还需要改。多了不说，十年前的工程项目管理和现在的就已经是天壤之别了。十年前 Java 8 才刚刚发布，一大堆人还在用 perl 和 shell 脚本写逻辑。我上一家公司系统的代码很多都已经是快二十年前的代码了，核心代码全是 shell ，看得恶心死。

毕竟不是小型初创公司，碰的代码并非总是新鲜出炉的东西，特别是大公司，碰屎山才是每天的日常。

[rekulas]

你怕是理解错了，这个耗时 2 周并不是程序员耗时，而是针对修改流程的分析所用耗时，真正代码耗时有 5 分钟吗？就算你改成配置，难道就能后台随意修改 10 分钟搞定？大公司修改配置同样要走流程不是你改配置能绕过的

而且我很好奇，你开发能什么数据都配置？做成这么细真的方便维护吗？没别的意思 真想看看你的代码啥样的

[rekulas]

@orioleq 忘记 @了 sorry

[orioleq]

@rekulas 你的看起来就是个会计系统，那每条费用明细都应该是会计科目的一条，我不理解为什么要写死，应该都是业务数据。加一个收费或减免项目应该只是配置数据多一条，带正负号，明细数据自动可以列出来在账单或报表上。
当然业务不同还是以你的感受为主，我只是吐槽我的感受。

[orioleq]

@msg7086 正常又不代表合理。
我也说了是理想状态下需要重构了，实际会遇到什么阻力我当然也明白。
但是你身为一个程序员，你大的重构做不了，每次改之前也要想想下次一模一样的需求来了是不是还要再吃一遍你说的那啥山。

[msg7086]

@orioleq 是啊，但这是一次性修改，都说了「必须」这样做了，改成配置有什么意义。
另外别说大的重构，小的重构也不会随便批的。比如我们隔壁组把以前写的 python 和 shell 脚本重构成 java 项目，上面的要求是严格遵循原来的逻辑，只要能一一对应翻译的，绝不做优化，绝不做重构，逻辑能不修改的绝对不允许修改。
这不是程序员甚至是下层管理有权利做的事情。

我最近甚至还遇到个，把一个没有正确缩进源代码的项目用格式化插件重新调整缩进，没有一丁点的源码改动，只改换行和空格，就这么一个更改都需要审批而且需要等某个版本发布后的某一个特定时间窗口内合并才行。

[orioleq]

@msg7086 你举的两个例子跟我说的“重构”没啥关系。不过我说的也不清楚，更适合的词可能是“重新设计”。这是为程序员维护系统减少工作量，跟系统稳定并没有冲突。下次你可以试试说服你老板。

[google2023]

@yagamil 在哪里不是螺丝钉呢？

[codehz]

@lookStupiToForce 最后发现 ai 理解出现了亿点偏差，然后大家全搞错了，最后还得回到人工检查上来（因为 ai 没法背锅）

[xuanskyer]

其实问题的本质是：你觉得写代码的重要性比其他事情高。
然后事实上是：写代码这件事和其他事情一样，并不特别重要。
如果认识到这点，一切都会合理起来

[lookStupiToForce]

@codehz #50 哈哈
请务必记住你现在对 AGI 的质疑🐶

[powerman]

@wenyuhe 别说小老板了，大公司很多照旧一个吊样，算工时的时候 就跟你算开发工时，结果项目里面 要各种扯皮，流程，审批，Review ，单测 ，自动化测试，全特么不给算进去，流程多如屎，事情有多，业务线这边要业务进度 要快，一刻不能等，工时在技术线那边也要压缩，结果就是屁事一大堆，加班搞不完

[vice]

业务越复杂或牵扯到的业务量巨大的业务都是需要层层审批的， 因为你完全不知道历史上发生过什么，以及有多少上下游业务方会和你有关联，举个最简单的例子，原先有个订单按钮入口，UI 设计师觉得实心按钮很挫，而前端刚好在改那个模块的东西，想着调一下颜色饱和度，仅仅只是调了一下饱和度，直接导致当日订阅订单跌了 5 个点。

[unco020511]

正常的,大公司是这样的,没有这些流程就容易出错

[laminux29]

1.与费用有关的，多开会，多做记录，是正确的做法，因为这能在发生事故后进行全责分摊。毕竟人无完人，对于复杂事情不可能考虑周全，发生麻烦事情在所难免。

2.不过，你这情况，才 5 个显示器，是否有些儿戏，系统设计 + 流程图 + 编码 + debug + 查资料 + IM 协作，5 个显示器是不够的。建议至少上 10 个显示器，21.5 寸壁挂屏 + 上下显示器支架。如果有条件，可以考虑 12 个屏。

[wenyuhe]

@powerman 最后都是流程和沟通成本，无偿加班买单。 看上去忙忙碌碌 上头就会很“划算”“有效”的感觉

[supuwoerc]

大企业容易这样，写代码可能 1 分钟，走流程可能 1 年...

[augustheart]

国内的话，这种事有啥做不到？从需求节点发起，一层层往上请求，直到能拍板和协调这么多部门的一层。然后讨论组拉起来，所有相关部门派人进组。小问题的就直接讨论组完成，有必要的就申请会议室，最后邮件。其它时候该干啥干啥。不牵涉到扯皮的很快就干完，需要扯皮，尤其是改需求的就大家一起扯皮。
而且这事是应该产品干的，码农只需要执行最终结果和提反对意见（技术实现困难）。一群码农在这感慨……

[google2023]

@augustheart 产品指的是项目经理？

[augustheart]

@google2023 对啊，pm 。不过我司习惯上都叫产品。一个公司级的需求的调研、规划、沟通，推进甚至给具体的人在管理系统上建 task 不都应该有专门的项目管理人员跟进么。至少在我司是这样操作的。
也不是项目经理说啥就是啥，程序明确说了技术上做不到的，项目经理就得想怎么迂回实现（所以根据手机壳颜色换肤的需求，你得告诉程序用什么原理实现，程序点头了才向下推进，要么就上升到产品主管和技术主管打架）。项目最后做砸了的，项目经理也得想好怎么收场。