自顶向下，逐步求精--软件工程导论

a07f



说到topdown我觉得更多地是一种methdology，其实代码打的多了，会发现有的时候确实思维的广度没有办法让你能够把自己之前写的代码牢牢地记住每一步是干什么的，导致一旦一个需求的复杂性超过了你思维所能容纳的极限，就会造成出bug，这种bug体现在上下文的连接上。所以大家渐渐地有意识无意识地会使用一种分治的methodology来写这些代码，具体的操作就是（对于我来说）先想好核心的功能大概是怎么样的，可能需要考虑一下这么做是不是最合适的，会不会有更好的方法。然后就直接写main 函数，把一个个功能用函数的形式先占着坑，等全部main函数写完之后再进行下一个层次的实现。

就像下面这样的代码

int main()
{
rootBrunch theRootBrunch;
int arr[30]={6,15,43,3,82,78,47,-1,27,101,-1,-1,69,-1,-1};//its a full binary tree to store for data and initialize
treeMethod.build(theRootBrunch,arr,5);
treeMethod.show(theRootBrunch);
treeMethod.interchange(theRootBrunch);//change the tree
treeMethod.show(theRootBrunch);
}

确实这样写我觉得会比先投入进去写具体细节功能这种bottom-up的方法会更好，因为这样可以在你写的时候一直给你提供一个大方向，让你一直保持清晰的大局观，不会迷失在细节之中。如果一直一个个功能地那么写最后链接起来的时候可以要在原来代码基础上改很多东西会造成不必要的时间开销。

但是看一些搞竞赛的同学的代码会发现人家的代码压根不是那么一回事，能用循环绝对不用递归减少时间开销，这种代码逻辑上绝对是没错的甚至可以对某些人来说称得上优美？但是我觉得真的写工程代码为了可读性可能应该是能递归就不循环吧应该，比较现在的开发可读性和维护性才是最top的要求。