未分類
15 2 月 2021

写代码时你更倾向于自上而下 (Top-Down) 还是自下而上 (Bottom-Up) ？

写代码时你更倾向于自上而下 (Top-Down) 还是自下而上 (Bottom-Up) ？

資深大佬 : Biwood 3

  • Top-Down: 先设计和规划，划分好模块后，建好每个细分模块、组件的空文件，先构建一套完整的库 /框架，即便有些组件暂时用不到，也要先写好，然后再写业务代码

  • Bottom-Up: 先不急着划分模块，起手就写主要逻辑，在写的过程中发现当前模块过于庞大，或者发现有两个或两个以上的模块有共用的部分，再考虑提取公共代码，这些可复用的公共部分慢慢积累，就形成了一个库 /框架

你更倾向于哪一种？

大佬有話說 (6)

  • 資深大佬 : NexTooo

    我个人目前更多是 2……可能一些细分的模块里面会按照 1 的方式设计
    很容易因为某些细小的知识点掌握的不够扎实，在开发到一半才发现和预想的不太一致，推到重来且浪费时间（

  • 資深大佬 : kop1989

    我一般是不充分的执行第一种，然后转向第二种。先根据经验抽象或者沿用一些工具和逻辑。然后上工作量保证主逻辑，然后在确保可用的前提下逐步扩展、抽象、优化。

    这样做的优势是，在需求还不稳定的前提下，项目的 deadline 最大化可控。而且在项目可运行当作风向标的前提下，也能帮助我快速确认哪些优化、抽象是合理、正确的。

  • 資深大佬 : lightjiao

    如果对做的东西没啥经验，我选择自下而上

    如果对做的东西有一些经验了，选择自上而下，不过也只会划分个大概，以声明接口或者注释的方式先保留

  • 資深大佬 : imn1

    两者结合，后者更多
    总规划肯定要有的，但如果能做到预设每个空组件，那我也只能膜拜这个人的脑容量

  • 資深大佬 : penghuaifa

    主要 Top-Down，中间穿插 Bottom-Up，这两种设计方法是相结合的。单独用哪个都很难受

  • 資深大佬 : leaveeel

    看需求大概规划下组件，然后撸主要代码，到那部分切到组件里写，然后引用。这样最重要的一点好处是中期问你进度的时候可以说整体都做完了，只剩些小功能需要完善下。这对不了解你的技术的 leader 很管用