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

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

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

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

没有设计就是最好的设计

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

能做到的也就是功能解耦、性能冗余了。
因为你不管用什么精妙设计，都会有刁钻角度的需求一击既溃的。

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

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

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

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

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

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

keep to refactor

这就是他们要的“经验”

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

计划赶不上变化

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

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

https://www.v2ex.com/t/767139?p=1ROI 的时候把这个生命周期考虑进去。

DDD 领域驱动设计模式

保证不了的
成本也不允许你保证

在国内的互联网项目就不要考虑扩展性一类的东西了。没必要也没有意义。
国内的互联网项目很大的特点就是高层为了抢市场，经常会去起各种各样的项目养着，能养大的话就继续做，养不大就放弃掉。
一般这类项目能做大的话，后期如果撑不住的就直接推翻重构了。

转行可破

借楼出域名 ofoer.com

这就是互联网公司抛弃 35 岁以上员工而失去的东西之一

除非开始的时候就把每个组件拆分的很细，然后自由组合，否则基本就要重构

没有什么是中间加一层解决不了的

扩展性是你把相关领域的问题想透，把核心能力和边界想清楚才有的。大部分敏捷开发，开发自己都没想清楚，老老实实按当前现状设计吧。别考虑什么扩展性。唯一需要考虑的，就是即时重构，依赖多的底层代码，记得拆分隔离。这样不至于需求改动时伤筋动骨。

抽象，就是关注共性的部分，把他们正确的分离出来，并且正确的使用共性的部分。当特性都被共性取代后，就自然而然成中台了。

OFO 已经凉了 还欠着我 100 押金没退给我 兄嘚

既然肯定是要推翻的，那就让代码写得更容易被删除啊。被依赖越多的代码，越难以被删除。

经验咯，碰到的坑多了，就会提前排坑了

其实就是元信息抽象不够。最好的方式就是 产品懂技术。从技术的维度去构造需求。 可以把程序员理解为 实现，产品理解为 interface 。