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

[wszgrcy]

有点被折磨了。。。

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

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

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

[xuanbg]

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

[AngryMagikarp]

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

[maichael]

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

[imdong]

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

[freakxx]

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

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

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

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

[hecz]

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

[aalikes95]

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

[tankren]

中国式敏捷？

[Ehco1996]

真正的大佬不写需求

[fancy111]

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

[Zien]

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

[xpresslink]

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

[ericgui]

怎么可能呢？

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

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

[sunshinev]

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

一种思维模式吧。

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

[chinvo]

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

所以不要看不起外包了

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

[doge]

[KasonPasser]

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

[kiracyan]

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

[kop1989]

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

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

[namelosw]

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

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

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

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

[wuhanchu]

那就不是大佬了 这种人我一般称之为 大神

[janxin]

不一定是随便改改就行的，多熟悉流程的人也扛不住业务会变化，小的改改就行，推翻大改一定不是随便改改

[subpo]

可能在最开始开发设计模型的时候，会预先预留一些情况
但是也会增加最开始开发的时间

[rockyou12]

纯理论上是可以的，但落实到具体工程中当然不是了，除非最初设计就考虑到通用

[hankai17]

设计时 考虑了很多吧

[kim01]

你就问老板先喊他给你一百，然后再喊他给你一万，你问他啥感觉，感觉不够再诚实就有感觉了

[newtype0092]

因为提问题的人惹不起就能修改事物客观发展规律了？你要真能做到应该他惹不起你才对。。。
讲清楚鱼和熊掌不可兼得，让他做选择，而不是他说啥你都答应。

[cs419]

需求合理 就好改

不合理吗 ？ 有多离谱呢？是异常离谱
应该。。。有吧

这种大牛的高度 您觉着给开多少工资合适
我觉着请这种大牛 不是钱不钱的事了

[yiyi11]

因为量变产生质变啊，所谓架构不都是因为业务量上来了，拆分，然后复杂度直线上升。

[yiyi11]

建议老板提供一台可无限扩展的服务器。

[yousabuk]

是的，有。
改的少是因为想的多

[phpcxy]

被傻*产品坑多了有经验

[wszgrcy]

@hankai17 @yousabuk @phpcxy 里面有个前提，就是时间有限，比如领导看 xx 有这个功能，然后就开始让马上做，立马出结果，然后做完了后觉得可以，然后就让大面积改成这种风格，并且认为花不了多长时间

[Acoolda]

知道去年某公司的产品经理为什么被程序员暴打吗？

[stevenkang]

如果是没有外部依赖的系统，需求变化了，原有系统改一下就合适了，这不算难事。

外包项目经常这样变，甚至整个业务流程都能变，懒得推翻原有系统，直接基于原有逻辑调整一下就完事。

[fangcan]

真的大牛会说这个需求无法实现，打回

[tikazyq]

真正的大佬会说：咱们有排期，所有工作安排在一起，大概明年 8 月能给到你，如果需要插队，请找老大