Top-Down: 先设计和规划,划分好模块后,建好每个细分模块、组件的空文件,先构建一套完整的库 /框架,即便有些组件暂时用不到,也要先写好,然后再写业务代码
Bottom-Up: 先不急着划分模块,起手就写主要逻辑,在写的过程中发现当前模块过于庞大,或者发现有两个或两个以上的模块有共用的部分,再考虑提取公共代码,这些可复用的公共部分慢慢积累,就形成了一个库 /框架
你更倾向于哪一种?
1
NexTooo 2021-03-01 16:18:20 +08:00
我个人目前更多是 2……可能一些细分的模块里面会按照 1 的方式设计
很容易因为某些细小的知识点掌握的不够扎实,在开发到一半才发现和预想的不太一致,推到重来且浪费时间( |
2
kop1989 2021-03-01 16:23:47 +08:00
我一般是不充分的执行第一种,然后转向第二种。先根据经验抽象或者沿用一些工具和逻辑。然后上工作量保证主逻辑,然后在确保可用的前提下逐步扩展、抽象、优化。
这样做的优势是,在需求还不稳定的前提下,项目的 deadline 最大化可控。而且在项目可运行当作风向标的前提下,也能帮助我快速确认哪些优化、抽象是合理、正确的。 |
3
lightjiao 2021-03-01 16:24:11 +08:00
如果对做的东西没啥经验,我选择自下而上
如果对做的东西有一些经验了,选择自上而下,不过也只会划分个大概,以声明接口或者注释的方式先保留 |
4
imn1 2021-03-01 16:24:14 +08:00
两者结合,后者更多
总规划肯定要有的,但如果能做到预设每个空组件,那我也只能膜拜这个人的脑容量 |
5
penghuaifa 2021-03-01 16:25:11 +08:00
主要 Top-Down,中间穿插 Bottom-Up,这两种设计方法是相结合的。单独用哪个都很难受
|
6
leaveeel 2021-03-01 16:32:16 +08:00
看需求大概规划下组件,然后撸主要代码,到那部分切到组件里写,然后引用。这样最重要的一点好处是中期问你进度的时候可以说整体都做完了,只剩些小功能需要完善下。这对不了解你的技术的 leader 很管用
|