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