大家编程，是自上而下还是自下而上？
整了2年嵌入式了，在初学的时候都是先编函数，然后搭主程序（自下而上）最近才体会到，自上而下的编程方式可以清晰不少！~先写结构框架、想好需要哪些函数和参数、最后只是实现的过程了~
这样不容易犯错
呵呵 ，坛子里大家都是怎么处理这个问题的呢？ 好像EDA 的大部分都是自上而下的编程方式，做硬件的貌似都是自下而上，呵呵！个人观点！ 我通常是自顶向下，先把骨架搭好，再丰富血肉。不知道这种方式是否ok，这种方式最大的缺点就是后期修改功能很麻烦，需要动架构，有时候不得不推到重来，当然只是部分，而不是全部。 我一般是把底层的驱动函数一个一个编好、测试，没有问题了再往上编写上层函数，这样有个好处就是程序出了问题的话首先排除底层的可能，集中精力把上层的函数写好 I do it top-down: start with the main structure, and a framework of modules, with artificial return values. and then once I have the framework done, I will move to fill in the modules. 看出来了~
原来写功能软件之类大多是自上而下，写硬件驱动大多是自下而上！
不知我总结得对不对 一般实现分析要实现这个功能需要哪些外设和功能，然后针对这些外设和功能写出对应的子函数，然后再考虑整体上每个子函数如何调用。 现在习惯：
1、先上部，将整体框架写好，是粗的框架，不需要实现具体功能。
2、然后加上某个模块的下部，再中段，进行第1次测试修改。
3、继续另一模块的下部，再相应的中段，第2次测试修改。
4、然后不断地下部、中段、测试修改，循环往复，直至所有功能模块都完成。
5、整体再测试修改。
这样的步骤的好处可以有整体规划，但是又能不断看到成果，给自己信心，又不容易积累大的问题。 一般的正规的企业里面,初级设计工程师一般只适合做最底层的模块设计和调试,而有经验的工程师或者高级工程师往往设计架构. top to down 我先写框架，各个子函数是一个个的空函数这样编译就能通过，要什么功能就在里面加 自上而下谓之道
自下而上谓之器
哈哈 回复【10楼】zhuyi25762
先写框架，各个子函数是一个个的空函数这样编译就能通过，要什么功能就在里面加
----------------------------------------------------------------------- 一会自上而下....一会自下而上....
上下上下...上上下下... 骨架在心中 It's worth emphasizing that bottom-up design doesn't mean just writing the same program in a different order. When you work bottom-up, you usually end up with a different program. Instead of a single, monolithic program, you will get a larger language with more abstract operators, and a smaller program written in it. Instead of a lintel, you'll get an arch.
需要强调的是自下而上的设计并不仅仅只是调个方向来写出同样的代码。当你自下而上的工作时，往往最后写出来的代码也是不一样的。程序不再是很大一坨，而语言会变得更强大，拥有更多的抽象操作符，这样程序本身将会变得更小。换斗移星，去直梁，得弧拱。
In typical code, once you abstract out the parts which are merely bookkeeping, what's left is much shorter; the higher you build up the language, the less distance you will have to travel from the top down to it. This brings several advantages:
通常写代码时，当我们从一些流水帐般的逻辑（如增删改查）中抽象时，其实其它逻辑所剩无几。对于语言层面的构建层次越多，每次所需其它表达越少。这带来诸多好处：
1. By making the language do more of the work, bottom-up design yields programs which are smaller and more agile. A shorter program doesn't have to be divided into so many components, and fewer components means programs which are easier to read or modify. Fewer components also means fewer connections between components, and thus less chance for errors there. As industrial designers strive to reduce the number of moving parts in a machine, experienced Lisp programmers use bottom-up design to reduce the size and complexity of their programs.
1. 让语言来承担更多的工作，自下而上的设计逼着程序更简洁与灵活。一段本来就简短的代码不需要再被切分成更小的模块了。更少的模块数量也意味着程序更易读和修改。更少的模块也意味着更少的模块间的依赖和耦合，也减少了错误发生的可能性。就像工业设计者努力的减少机器中运动部件的数量一样，资深的Lisp程序员用自下而上的设计来减少代码的大小与复杂度。
2. Bottom-up design promotes code re-use. When you write two or more programs, many of the utilities you wrote for the first program will also be useful in the succeeding ones. Once you've acquired a large substrate of utilities, writing a new program can take only a fraction of the effort it would require if you had to start with raw Lisp.
2. 自下而上的设计能促进代码重用。当你写很很多的程序时，往往为第一个程序写的Utility类也可以应用到其它后来的程序上。当你积累了很多底层Utility类之后，比起用最原始的Lisp，写新的程序往往只需很少的工作了。
3. Bottom-up design makes programs easier to read. An instance of this type of abstraction asks the reader to understand a general-purpose operator; an instance of functional abstraction asks the reader to understand a special-purpose subroutine.
3. 自下而上的设计能让程序更易读。读程序的人只需理解抽象出的通用操作符，与抽象出的底层逻辑即可。
4. Because it causes you always to be on the lookout for patterns in your code, working bottom-up helps to clarify your ideas about the design of your program. If two distant components of a program are similar in form, you'll be led to notice the similarity and perhaps to redesign the program in a simpler way.
4. 自下而上的工作可以帮助你更专注于代码的设计模式，从而理清程序设计思路。比如你很容易就能注意到，同一个程序中的两段八杆子打不着的代码居然长得很像，并且能用简单的方式重新设计。
Bottom-up design is possible to a certain degree in languages other than Lisp. Whenever you see library functions, bottom-up design is happening. However, Lisp gives you much broader powers in this department, and augmenting the language plays a proportionately larger role in Lisp style-- so much so that Lisp is not just a different language, but a whole different way of programming.
自下而上的设计不仅仅只能在Lisp中才能达到。任何当你看到库函数的时候，自下而上的设计就自然出现了。但是Lisp能给你更大的力量，在Lisp编程风格中，代码量的增加能带来对应功能的增加。因此Lisp不仅仅是种语言，也是一种全新的编程方式。
——自下而上的编程 | Programming Bottom-Up Paul Graham http://www.paulgraham.com/progbot.html 心中想好架构后，先写底层。 自顶向上和自底向上同时使用，一般是先搭好框架，然后底层每部分功能实现好了，验证过了，在放到框架里面去调试。 有经验的当然是自上而下。没经验的，做自上而下时的设计，把握不大。因为有些具体实现会遇到困难，影响架构的总体设计。 小工程下而上，大的上而下，这样比较好吧~ 1、“驱动”都有，自然是自顶向下了。
2、某个外设需要写“驱动”的话，我一般是先写好“驱动”，测试好。然后归入1。 Ian11122840 发表于 2010-9-18 08:33 static/image/common/back.gif
看出来了~
原来写功能软件之类大多是自上而下，写硬件驱动大多是自下而上！
{:handshake:} 我认同你的观点 学习，围观{:shy:} 自底向上，先调通所有模块，然后整合 喜欢先搭骨架,然后再补充血液.
页:
[1]