需求梳理，模式设计。让 API 兼容更多场景，编写鲁更加鲁棒的代码到底对不对？

[DeepSIeep]

马上周末了，一些碎碎念

做项目 n 多年了，一直重视组织架构和鲁棒性。现在发现，功劳最多的是哪个每次有个小需求都要写代码的，反倒是你，每次需求你动动手指，改改配置就好了没什么参与度。

年终评审绩效的时候，有几个人能看懂你的高可用和高适配？防御性编程，有时候在特殊情况下也是蛮有道理的

[vfs]

我认为作为程序员，你只需要保证你写的代码完成期待的功能就行。 不要提前设计，不要过度防御，不要为了不存在的 case 将代码复杂化， 保持你的代码简洁，简单，少就够了。

[DeepSIeep]

@vfs 然后一个需求一个 API ，所有参数都放里面（真有人这么干）

[vfs]

@DeepSIeep 代码总是需要随着新需求演进，从一开始你不需要考虑后头会有什么需求，但是当新需求来的时候，你需要让你代码适应新的需求，同时不破坏旧的需求。 这里有人会选择增量变成（加一份拷贝或者一个 if 分支）， 有人会选择重构、整理代码来优雅的适应。 我也不知道哪种好， 反正两种方式最后新功能都能被支持

[msg7086]

这取决于你的领导是不是傻子。

[DeepSIeep]

@vfs 各有好处反正。但是简单做，可以保证自己随时有工作，手里有 offer 。所以我现在开始摇摆了

[vfs]

@DeepSIeep 哈哈,别啊, 我们同事也在代码里乱整(水平差还 vibe coding), 我都麻木了. 等维护不下去了再说, 那时候你再出来力王狂澜, 岂不是更加凸显你的能力强么

[vfs]

@DeepSIeep 防火不如救火

[DeepSIeep]

@vfs 防火不如救火，有道理

[feng950704]

有 1-2 个亮点就行了，首先要明确自己的工作范围，然后干好本职工作，选一两个亮点重点突出，让人记得住。比如你就是搞会员这块的，那就把这块好好写，适当加一些多级缓存架构之类的能讲的东西。 每个小需求都写代码，累的也是自己，把功能做的太优秀，搞的太闲也不好。平时中规中矩，突然冒出一两个亮点就最好。