从编程序看分析和综合,以及用于写作和做报告

最近,不得不来指导一下学生编程序。除了

  1. 给程序加执行参数(例如linux命令cp后面的文件名就是用来满足适于用任何文件的要求,例如ls后面的-a就是用来显示隐藏文件等等)来增加程序的功能而不是完成非常特定的功能,然后每次不得不去修改程序本身
  2. 运行参数包含测试功能的开关,这样测试起来简单
  3. 程序尽量要做到命令行下可执行,不要依赖于集成环境IDE,可以用makefile
  4. 变量名要有意义
  5. 程序要加上说明,看的出来每一行在做什么
  6. 合适的时候,做一下优化,例如用矩阵代替循环之类的
  7. 一般的编程,以及每一种语言,基本上都会有一些风格习惯,要稍微了解和遵循

这些基本的要求之外,最重要的是Divide and conquer的思想,也就是分解和综合的思想:把每一个程序分解成合适的步骤,每一步完成特定的功能。甚至在主程序这样的高等级程序里面,完全不应该有具体的计算,只能有每一段应该完成什么的流程;甚至在比较高级的功能性模块里面,也只能由每一段应该完成什么的流程;仅仅在最底层的程序里面才应该有具体计算,核心计算。也就是程序应该长成这样:

main{
   get some run-time parameters #meaning of every parameter
   to do task1 #what is this task, why it is needed here
   to do task2 #what is this task, why it is needed here
   to do task3 #what is this task, why it is needed here
   testcode #activated when the designated run-time parameter is called
   print results #to serve what purpose
}


task1(parameters){
   to do task11 #what is this task, why it is needed here
   to do task12 #what is this task, why it is needed here
   testcode #activated when the designated run-time parameter is called
   return something back to the calling program
}


task11(parameters){
   Realcode, core code #how this task is done
   testcode #activated when the designated run-time parameter is called
   return something back to the calling program
}

这样的程序,尽管初看起来,会云里雾里,发现,每个子程序都没有在干活啊,就是在调用下一级子程序,好像只有搞懂最底层的子程序,才能看懂这个上一级程序。但是,只要稍微习惯一下,改变一下思考问题的方式,就会发现,这样的程序比把核心程序和流程程序放在一起的,要好懂的多好懂的多。关键的思考问题的方式就是分析和综合,或者叫做Divide and conquer,或者WHWM分析方法(What,How,Why,Meaningful)。具体来说,就是,在看上一级程序例如主程序的时候,每一个子程序只要明白在完成什么功能,这个功能和当前程序的目的是什么关系,就行了。不需要取搞清楚子程序是怎么做的。也就是说,What(完成什么功能)是最主要的,然后是Meaningful(起到什么作用),How(怎么做的)和Why(为什么这样做,为什么做这个)是次要的。只有当真的需要的时候才进入下一级子程序,而且就算进入下一级子程序,还是一样,先搞清楚这个子程序下面的流程,也就是每个子子程序的功能以及它们和这个子程序的功能的关系,而不去管这些子子程序是怎么实现的,有没有更好的实现。当然,这样的阅读依赖于程序员的注释,因此,每一个功能模块,都要做好注释,完成什么功能。

记住:很多细节我们都可以不懂,只要我们懂得这个东西做了什么,在整体中起到什么作用。当然,如果我们真的想搞懂整个问题,那么,自然,底下的How和Why也是重要的。

这样来做还有什么好处呢?方便测试,方便协作。测试的时候,可以单独来针对特定的子程序,而且可以设定一个针对这个子程序具有精确解的情况来测试。协作的时候,每一个贡献者可以只管当前任务的细节,而不去管这个任务之上的子程序和之下的整合,当然,在把任务分解准确以后。

只要做好分解,不断地分解——每一次都只有流程直到不得不写下来核心程序,做好注释,做好测试,无论编程水平(例如语言包的熟悉程度、算法的创造性运用)本身多烂,都能够编出来好程序。

同样,写作和阅读的时候,也是如此:首先是整篇文章想说什么主要信息,为什么说这个;接着把整篇文章分解成一个一个的部分,每一部分说了什么主要信息和整篇文章的关系是什么;再接着,还可以把每一个部分再次分成一个一个的部分,每一步分说什么主要信息和它的上一层关系是什么。也就是在每一个层次上,问What和Meaningful的问题,然后依靠在下一层问What和Meaningful的问题来回答上一个层次的How和Why。

同样,做学术报告的时候,更加要如此:首先是整个报告想说什么,为什么说这个;接着,用什么例子或者结论来展开论证和表达这个主要信息,以及反过来,在介绍这些例子和结论的技术细节的之前一定要让你的听众明白,你为什么将这些例子和结论,它们和主要信息的关系是什么;然后,对每一个例子和结论,做同样的事情,先搞清楚需要用哪些进一步的细节来展开这些例子和结论,在具体进入这些进一步的细节的具体技术细节之前,能不能交代清楚这些细节和这些例子和结论的主要信息是什么关系。不断地重复这个分解的过程、明白起到对上一级的内容什么样的支撑作用、然后才是细节的展开。为什么要这样做?因为你的听众基本上不会一下就明白最底层的细节,每一次的封装都能够降低你的听众的记忆和信息处理负担。

当然,有的时候,这个层次会有交叉。这也是为什么要依靠概念地图——整体是层次结构,但是跨越层次的联系是最重要和核心的联系。这也是系统科学,物理学,或者说科学的核心思想之一——分析和综合。除了学习物理学、系统科学,你还可以通过练习编程来体会这个分析和综合,只要完成一个需要300行以上的程序,你就不得不体会到。任何语言都可以,但是,不要直接就是图形界面的例如VB之类的,试试C、Python、Java等,尤其是Java(接口,而不是具体程序)。

发表评论

电子邮件地址不会被公开。 必填项已用*标注