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

[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 ，跟各个部门扯皮较劲，心累不已。

[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]

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