开发前的设计要怎么保证扩展性呢，感觉怎么设计都赶不上突然的变化

[Renco]

每次设计时，都要求要考虑好未来的扩展性。结局就是要么没有未来，要么未来也全部推翻

[SaltyLeo]

一开始就模块化，未来扩展就扩展组件横向扩展，会很方便。

[shyangs]

問問 PM 未來的展望. PM 和老闆不給力. 你就兼職 PM, 看看競品. 反正 PM 也會看競品, 包裝成需求提出.

[golangLover]

这是人的问题，不是技术问题。

[Mohanson]

没有设计就是最好的设计

[SteinsGate]

将有可能变化的模块（类）依赖接口

[kop1989]

能做到的也就是功能解耦、性能冗余了。

因为你不管用什么精妙设计，都会有刁钻角度的需求一击既溃的。

[no1xsyzy]

没有银弹

除非你允许插件替换你的二进制码（参考 Minecraft 的 mod

[abcbuzhiming]

别想了，你保证不了的，就现在互联网项目那种动不动推了重来的模式，你怎么弄都没有用，所谓扩展，是保证原有模块基本不变的情况下，新增功能，可现在的开发需求动不动玩的是“推翻”，还扯淡什么“拥抱变化”。这种换神仙也没用，推了重来是唯一方式

[baiyi]

可以看看这本书作者提供的书单，虽然这本书讲的是重构，但重构和设计是分不开的
https://github.com/phodal/migration

[PainAndLove]

这个问题我之前也想过，如果基于目前我们项目的组织，让我自己提需求。 我可以变着花样让当前的扩展性=0

[312ybj]

找到变化，封装变化。 在完成这一期需求的同时， 尽量地使用设计模式动态地抽象结构设计； 如果是增加功能，可以多加个节点就完事， 如果是改之前的需求， 那就得改之前的代码了。

[watcher]

重构 - 有效改善之前装过的逼

[zhengxiaowai]

keep to refactor

[kooze]

这就是他们要的“经验”

[domodomo]

向你推荐面向接口 /协议编程设计，用过的同学都说好，再也不怕产品经理拍脑袋的需求了。

[v2lhr]

计划赶不上变化

[charten]

既然计划赶不上变化，那就以不变应万变

[IvanLi127]

微服务？让重构的时候负担小点？

[libook]

https://www.v2ex.com/t/767139?p=1#r_10391487

先让产品设计人员做好未来的规划，在可预见的需求中进行扩展性的设计，有余力可以在不提高成本的条件下考虑一些未计划但可能大概率会有的需求。

然后就是要时刻意识到，你的代码是有生命周期的，一旦需求发生变化，生命周期结束，让项目经理在评估项目 ROI 的时候把这个生命周期考虑进去。

[s0nnse]

DDD 领域驱动设计模式