要多健壮的代码才能支撑起千变万化的需求？

[waiaan]

最后不会成为屎山

[typing]

容易改的代码

[FanChen]

if else 足够多的话

[flyingghost]

千变万化的开发团队。

[MrBearin]

人容易看懂的代码

[KagurazakaNyaa]

可维护性高，可扩展性强的代码

[wangritian]

看架构怎么拆分层级依赖

[qping]

怎么都不可能吧,
尽可能的解耦. 不断迭代 , 把一段时间内堆的小屎山铲掉

[xieqiqiang00]

“开闭原则（ OCP ）: 如果系统想要容易被改变，那么其设计就必须允许只靠增加代码来改变系统行为，而非只能修改原有代码”

“不将未来的需求抽象化，「 You aren’t going to need it 」，一项中的需求往往是不存在的
需要发现在某个位置确实需要边界，如果不设置，再添加的时候需要的成本和风险往往是比较高的
架构师需要在上边两点做 trade-off，需要一点点未卜先知的能力”

[h82258652]

不可能的，例如一个一对一的逻辑，贯穿了整个业务流程，然后某天产品说要改成一对多的。

[HENQIGUAI]

你好，有的 。https://github.com/kelseyhightower/nocode

[waiaan]

@h82258652
不错，就是这种业务逻辑都变了。

[BeautifulSoap]

这是做梦呢，对于处理千变万化业务的代码，最好办法就是引入测试（单元测试、集成测试）然后根据需求持续重构代码，而不是不停在之前的代码上修修改改

代码即模型，你业务变了意味着模型也变了，想用一套代码处理所有业务意味着想用一套模型去处理所有业务，不存在这种神奇的银弹的

[zhangchongjie]

代码这玩意儿，感觉就和做生活中产品一样，单一的产品功能简单反而达到更好地效果，想必这也是以后发展的趋势吧。而不是像现在 bat 一样，恨不得一个软件所有功能都集成了

[Granado]

个人认为，这从来都不是代码的问题，根本在于没有一套合理的模型去处理业务；
每次开发的时候，leader 都说要抽象，要扩展，可是最开始的设计根本考虑不到以后的各种业务细分 case，只能不停修修补补。

[pengtdyd]

典型的程序员思维。如果出现千变万化的需求说明你们公司应该换一个带脑子的产品经理

[yunyuyuan]

@HENQIGUAI #10 少了个'亲'，差评。

应该是'亲，你好，有的'

[way2explore2]

无码

[CodeCodeStudy]

需求千变万化说明老板都不知道要做什么，赶紧跑路

[FranzKafka95]

个人认为不是代码问题，是架构问题

[maichael]

“没有银弹”