编程思路 top down vs bottom up

scf

编程有两类思路：top down，从原理和整体出发，和bottom up从已有代码和局部出发。具体到量子化学程序开发上，哪种效率更好呢？ top down似乎适合自动化实现，但可能细节在开始的时候会疏忽，而且这种倾向似乎容易和祖传代码冲突；bottom up容易debug，但似乎步子太小，效率不够高。大家有什么心得体会吗？

lijingbai2009

我最开始写代码是top down，然后一旦有新需求就得从最外层或者最上层改，只能自己维护。后来改用bottom up，先写好核心模块，高级功能就调用写好的模块，新需求只用改底层模块，或者用新模块替换，还不用担心改动会不会引起其他模块冲突。这样还可以多人分工，开发不同的模块，维护成本低，拓展性也好很多。也可能是因为我主要写Python，所以感觉bottom up 更方便一下。别的语言有可能更适合top down。当然如果完全是自己写的代码，也可以两者结合，用top down思路设计整个程序的结构，然后bottom up实现每个功能。

ShangChien

lijingbai2009 发表于 2022-5-31 10:44
我最开始写代码是top down，然后一旦有新需求就得从最外层或者最上层改，只能自己维护。后来改用bottom up ...

我的感觉完全和你相反，一开始学编程估计都是先实现一个特定的小功能，然后围绕这个小功能核心慢慢拓展，对接其他程序接口，编写工作流，这个模式一般都是bottom up。时间长了，编写几个工作流后，你就想会想要把它们整合起来，删除重复代码，更好得组织复用逻辑，规范文件输出，同时也有利于维护更新。这个模式依然还是bottom up思维。有个弊端就是，如果一开始没有考虑做大或者子流程复杂度较大依赖多时，对于强迫症和完美主义者来说，整合代码还是很折磨的，这个时候就会考虑代码重构（前端恶人话术：用rust重写）。对于大项目（方向性阶段目标，申gover项目挣W）来说适合采用top down模式。top就是目标大饼，down就是各种已有的轮子，实在没有的轮子才会自己去造。良心一点的，把项目外包出去，最后结题时能一瘸一拐运行，这就算好的了。有些项目大饼方向画错了，以至于无法实施，最终阑尾，人家也无所谓，毕竟钱到手了。
对于完美主义者来说，做好一个top down新项目，不但需要全局性敏锐前瞻思维，也需要扎实的bottom up基础。因为现有的轮子仅仅只是能用，并不会完美适合，想要性能和流程（代码逻辑）直觉上过得去就需要自行review, fork, 修改。