问下，真正的大佬们是不是不管需求怎么变化，都能在原有的系统上稍加修改就合适了？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 1680 天前的主题，其中的信息可能已经有所发展或是发生改变。

有点被折磨了。。。

问题抽象化大概是这样的，老板说设计个 o(n)的算法，马上要，根据现有数据规模，勉强实现出来了

老板看了后发现很满意，然后就让用这个就实现一个 100 倍现有数据的另一个功能，马上要。告诉他实现不了，然后就开始说怎么不行，这个都可以，那个差不多也可以之类的

不知道大家遇到过这种情况没有，上述问题就是当应急实现了个东西后，马上又要根据这个拓展，而这个应急写出来的本身不具有任何拓展功能，但是提需求的人不管，认为既然差不多，就应该马上实现。。。每次遇到这种问题都想 ko 他，但是每次提问题的人都是惹不起的(位置)。。。

马上

实现

应急

抽象化

36 条回复 • 2020-05-13 17:20:16 +08:00

xuanbg

2020-05-12 11:48:07 +08:00

是的，只要你能把所有代码都写对地方就行。

AngryMagikarp

2020-05-12 11:50:50 +08:00

当然不是。有些需求本身就是前后矛盾的。

maichael

2020-05-12 12:00:55 +08:00

“稍加修改”，不可能，再强也不可能。

imdong

2020-05-12 12:01:12 +08:00 via Android

我认为大佬可能只是提前预见了未来的一些可能的需求，开发设计时就适当考虑这些可能的需求。

freakxx

2020-05-12 12:06:43 +08:00

视乎你怎么定义这个问题，系统是指多大，需求变化怎样

倘若你举例，你要在原有接口做处理，
你也可以在逻辑层继承出去把“屎”包好，就不会影响到你原有的。

再恶心一点，你就加多一个参数，让外部自动传给你，或者你写个自动去判断，把逻辑分开。

代码的层次划分就很重要。

hecz

2020-05-12 14:36:20 +08:00

开发一个应急不可扩展的需求和可扩展的需求时间是不一样的。如果一开始就有扩展需求，就需要重新评估时间和方案

aalikes95

2020-05-12 14:43:32 +08:00

要是能这样，就真是太牛了

tankren

2020-05-12 14:45:58 +08:00

中国式敏捷？

Ehco1996

2020-05-12 14:46:45 +08:00

真正的大佬不写需求

fancy111

2020-05-12 14:47:10 +08:00

可以的。没有实现不了的功能，只有实现不了的人。

Zien

2020-05-12 14:47:42 +08:00 via Android

世上真有这种大佬的话...我膜拜一下

xpresslink

2020-05-12 14:49:03 +08:00

从绝对的角度是的。
但是从相对地的角度不可操作，因为项目受时间、成本、质量三个约束条件制约。
你初始需求说盖个二层楼，你初始打个二层楼的地基，现在需求要改成 200 层，你在原来地基上绝对盖不起来。

ericgui

2020-05-12 14:59:33 +08:00

怎么可能呢？

我们的一个前端 app，6 个月，大的布局变动至少 4 次，更别提小的了

所以我们的代码，里面充斥着各种 todo

sunshinev

2020-05-12 15:21:31 +08:00

我见过一个大佬，做一个需求的时候，他就把产品要做的下一个需求都想好了。结果后来产品提的很多需求，真的是稍微修改下就支持了。

一种思维模式吧。

这位大佬之前是生物专业的，后来高的计算机。他常说：“计算机什么的，比生物简单太多了”

chinvo

2020-05-12 15:24:14 +08:00

多做外包可以有效锻炼这种能力

所以不要看不起外包了

能独立从头开发的外包都有系统设计和规划以及预测新需求大方向的能力

[doge]

KasonPasser

2020-05-12 15:26:10 +08:00

这就是所谓的敏捷式开发[doge]

kiracyan

2020-05-12 16:10:03 +08:00

再原来基础上改一改就能完成的功能：
1.功能简单
2.设计之初就预留了扩展的空间

kop1989

2020-05-12 16:27:20 +08:00

不一定。
能做到“随便改改就满足了”，只能是两种可能性：
1 、在一开始设计程序功能和逻辑的时候就预留了比较充裕的扩展空间和使用了比较自由的框架架构。
2 、对行业有理解，预测了需求。

1 的弊端是不好掌握度，很容易过度设计。导致开销大不划算。软件工程是工程学，讲究最大性价比解决问题。
2 的弊端是对人要求高，需要你对当前业务这个行业有很强的理解。而且客户或者产品设计者的水平是参差不齐的。有可能你预测客户、产品要做个航天飞机，最不济也得是火箭，结果客户、产品经理最终需要一个窜天猴。

namelosw

2020-05-12 16:49:59 +08:00

优化过的算法一般很难做到这点，因为大部分优化算法都是 mutable 算法，很难重构，不太可能做到一改就能适合新业务。你看 CLRS 上的各种数据结构的限制都非常强，稍微改一点需求这个数据结构就不能用了。

不考虑性能的话，光业务功能有时候能实现这种，基本上出于对业务方向的预测，但要求变化合理，并不能做到怎么变化都能达到这点。基本押错了要不就算过度设计啰嗦难懂，要不更惨给以后埋坑。

不过每个人都会碰到过需求变化听起来很简单，做起来特别难的时候。这个就是设计问题，其实是可以避免的。
对于任何业务都有个核心复杂度，这个就是“没有银弹”的基础，对业务老老实实地，不走弯路地建模是一个软下限，改需求的时候要也有这么个软下限。如果这个软下限没那么低，但也随随便便就改好了，不然是之前押对方向，不然就是抄近路。
抄近路的设计就是突破这个软下限的（用算法做类比就像基数排序，能突破常规排序下限但是加新数据类型就要重写），但是可能是隐患。
但是更多的是有问题的设计，就是既没达到省事的目的，最后还把自己坑了改起来的工作量大幅超过软下限。这个理论上是一定程度可以避免的。

总的来说，真正的大佬：
1. 并不能任何时候随便改改就合适
2. 对业务有熟悉，经常能押对方向，之所以能随便加上的原因是之前就已经对这个因素建模了
3. 不给自己添没意义的乱，即使抄近道也要有价值