这是一个创建于 1340 天前的主题，其中的信息可能已经有所发展或是发生改变。
每次设计时，都要求要考虑好未来的扩展性。结局就是要么没有未来，要么未来也全部推翻
 |
1
SaltyLeo 2021-04-28 11:08:49 +08:00
一开始就模块化，未来扩展就扩展组件横向扩展，会很方便。
|
 |
2
shyangs 2021-04-28 11:18:33 +08:00
問問 PM 未來的展望. PM 和老闆不給力. 你就兼職 PM, 看看競品. 反正 PM 也會看競品, 包裝成需求提出.
|
 |
3
golangLover 2021-04-28 11:24:32 +08:00 via Android
这是人的问题，不是技术问题。
|
 |
4
Mohanson 2021-04-28 11:34:26 +08:00 via Android  1
没有设计就是最好的设计
|
 |
5
SteinsGate 2021-04-28 12:02:18 +08:00 via Android
将有可能变化的模块（类）依赖接口
|
 |
6
kop1989 2021-04-28 12:11:11 +08:00
能做到的也就是功能解耦、性能冗余了。
因为你不管用什么精妙设计，都会有刁钻角度的需求一击既溃的。 |
 |
7
no1xsyzy 2021-04-28 12:47:26 +08:00 1
没有银弹
除非你允许插件替换你的二进制码（参考 Minecraft 的 mod |
 |
8
abcbuzhiming 2021-04-28 13:22:20 +08:00
别想了，你保证不了的，就现在互联网项目那种动不动推了重来的模式，你怎么弄都没有用，所谓扩展，是保证原有模块基本不变的情况下，新增功能，可现在的开发需求动不动玩的是“推翻”，还扯淡什么“拥抱变化”。这种换神仙也没用，推了重来是唯一方式
|
 |
9
baiyi 2021-04-28 13:33:32 +08:00
可以看看这本书作者提供的书单，虽然这本书讲的是重构，但重构和设计是分不开的
https://github.com/phodal/migration |
 |
10
PainAndLove 2021-04-28 13:38:34 +08:00
这个问题我之前也想过，如果基于目前我们项目的组织，让我自己提需求。 我可以变着花样让当前的扩展性=0
|
 |
11
312ybj 2021-04-28 14:03:48 +08:00
找到变化，封装变化。 在完成这一期需求的同时， 尽量地使用设计模式动态地抽象结构设计； 如果是增加功能，可以多加个节点就完事， 如果是改之前的需求， 那就得改之前的代码了。
|
 |
12
watcher 2021-04-28 14:09:11 +08:00
重构 - 有效改善之前装过的逼
|
 |
13
zhengxiaowai 2021-04-28 14:09:19 +08:00
keep to refactor
|
 |
14
kooze 2021-04-28 14:12:32 +08:00
这就是他们要的“经验”
|
 |
15
domodomo 2021-04-28 14:23:23 +08:00
向你推荐面向接口 /协议编程设计，用过的同学都说好，再也不怕产品经理拍脑袋的需求了。
|
 |
16
v2lhr 2021-04-28 14:27:48 +08:00
计划赶不上变化
|
 |
17
charten 2021-04-28 14:30:04 +08:00
既然计划赶不上变化，那就以不变应万变
|
 |
18
IvanLi127 2021-04-28 16:18:38 +08:00
微服务？让重构的时候负担小点？
|
 |
19
libook 2021-04-28 16:32:27 +08:00
https://www.v2ex.com/t/767139?p=1#r_10391487
先让产品设计人员做好未来的规划，在可预见的需求中进行扩展性的设计，有余力可以在不提高成本的条件下考虑一些未计划但可能大概率会有的需求。 然后就是要时刻意识到，你的代码是有生命周期的，一旦需求发生变化，生命周期结束，让项目经理在评估项目 ROI 的时候把这个生命周期考虑进去。 |
 |
20
s0nnse 2021-04-28 16:35:25 +08:00
DDD 领域驱动设计模式
|
 |
21
tairan2006 2021-04-28 16:40:05 +08:00
保证不了的
成本也不允许你保证 |
 |
22
fkdog 2021-04-28 16:44:45 +08:00
在国内的互联网项目就不要考虑扩展性一类的东西了。没必要也没有意义。
国内的互联网项目很大的特点就是高层为了抢市场，经常会去起各种各样的项目养着，能养大的话就继续做，养不大就放弃掉。 一般这类项目能做大的话，后期如果撑不住的就直接推翻重构了。 |
 |
23
jinhan13789991 2021-04-28 16:57:37 +08:00
转行可破
|
 |
24
996icu007007 2021-04-28 17:00:14 +08:00
借楼出域名 ofoer.com
|
 |
25
66beta 2021-04-28 17:01:45 +08:00
这就是互联网公司抛弃 35 岁以上员工而失去的东西之一
|
 |
26
xingguang 2021-04-28 17:25:21 +08:00
除非开始的时候就把每个组件拆分的很细，然后自由组合，否则基本就要重构
|
 |
27
akira 2021-04-28 17:28:06 +08:00
没有什么是中间加一层解决不了的
|
 |
28
SolaWing 2021-04-29 01:36:25 +08:00 via iPhone
扩展性是你把相关领域的问题想透，把核心能力和边界想清楚才有的。大部分敏捷开发，开发自己都没想清楚，老老实实按当前现状设计吧。别考虑什么扩展性。唯一需要考虑的，就是即时重构，依赖多的底层代码，记得拆分隔离。这样不至于需求改动时伤筋动骨。
|
 |
29
xuanbg 2021-04-29 05:17:39 +08:00
抽象，就是关注共性的部分，把他们正确的分离出来，并且正确的使用共性的部分。当特性都被共性取代后，就自然而然成中台了。
|
 |
30
LessonOne 2021-04-29 09:36:15 +08:00
@996icu007007 OFO 已经凉了 还欠着我 100 押金没退给我 兄嘚
|
 |
31
taowen 2021-04-29 13:43:55 +08:00
既然肯定是要推翻的，那就让代码写得更容易被删除啊。被依赖越多的代码，越难以被删除。
|
 |
32
maxbon 2021-04-29 17:25:50 +08:00
经验咯，碰到的坑多了，就会提前排坑了
|
 |
33
NUT 2021-04-29 19:20:14 +08:00
其实就是元信息抽象不够。最好的方式就是 产品懂技术。从技术的维度去构造需求。 可以把程序员理解为 实现，产品理解为 interface 。
|
Select Language