最近在网上看到leezy_2000的一篇文章,《编程本质》,读了之后颇有感触。有些观点,我非常赞同,但是,有些我却有不同的看法。觉得在文章之后的讨论区不能一吐为快,另外,也早有许多相关的想法想表达,所以就干脆打开Word,敲下了这篇文章。希望能和leezy_2000,以及其他的程序员朋友一同分享。 leezy_2000把程序设计归结为四大要素:问题、概念、逻辑和技巧,并且举了一个例子加以说明。问题是程序的目的,概念是在解决问题时用到的抽象事物(或者说是术语),逻辑是描述如何解决问题的,技巧等同于实现,使用何种计算机语言或框架等。这四大要素其实是程序设计的四个步骤,分析、抽象、概要设计、实现。从程序开发的过程上来说,的确如此。 但是,作者把程序的本质归结为概念和逻辑,我并不赞同。我倒是有些赞同cppTrier的观点,“编程的本质是问题模型到编程语言的映射”。但是这样描述的话,程序员变成了翻译员,抹杀了程序员的创造性。所以我觉得编程的本质更应该是以编程语言的思想描述、解决现实问题。Thinking in Programming Language。 关于语言和框架,leezy_2000的描述非常的经典。“语言是逻辑的载体和描述工具,框架是对逻辑和概念的一种封装”。使用不同的语言解决相同的问题,他们的逻辑是不同的。一个极端的例子是Prolog语言,这是我见到过的最奇怪的一种语言,但是用它来解决一些离散数学的问题却很方便。如果同样的问题让一个Prolog程序员和一个C++程序员来解决,他们的逻辑显然是不同的。大师说“语言磨砺了我们的思维方式,也决定了我们的思考范围”,就是这个道理(感谢weihere的引用,有时间我要去读读《The C++ Programming Language》)。每一种语言都有它内在的一种描述问题的思想和方法。 作为一个程序员,对于所使用的语言应该有一个全面、深刻的认识,掌握它的思想,学会用它来思考和解决问题。这也是Bruce Eckel在他的系列书籍Thinking in Java,Thinking in C++所提倡的。 那么如何掌握语言的思想呢?看看Bruce的书就行了吗?那样只能学到一些皮毛。你必须实践,写上几千,几万行代码。只有在水里才能学会游泳。一本好书只能帮助我们缩短学习的过程,它不能代替实践。我不能想象一个人如果从来没有写过面向对象的程序,他是如何理解UML之类的东西的;更不能想象一个初学C++或是Java的程序员是如何通过读读《Design Pattern》就能掌握设计模式的。 计算机是一门实践的学科。当我们在讨论编程的本质时候,决不能忘记实践是重要的。本质固然重要,如果少了实践,就会变得形而上学。即使是微软的高级副总裁,Rick Rashid,仍然每年坚持编写大约50 000行代码。他认为,用最新的技术编程可以使他保持对计算机最前沿的技术的敏感。(摘自李开复《给中国学生的一封信》)。而在我的周围,一些只带几个程序员的小官,就以编程为耻,他认为象他这样的官(也叫项目经理)写程序,太丢份。真让人汗颜! 我们是程序工人(Coder)还是软件设计师(Designer)?在回答这个问题之前,我们首先要明白,什么是设计?设计是工程上的概念,设计的结果是一组文档,制造团队可以依据这份文档,准确的构建出产品。源代码是满足这一要求的惟一的软件设计文档。和一般工程不同的是,根据源代码构建产品的成本非常低廉,它无须什么工人,计算机可以代劳。现在流行的看法,似乎只有画UML图才是设计,而使用设计模式编码的设计倒不算设计。这其实是本末倒置了,UML图只能算是辅助设计文档,真正的设计文档是源代码。因此,我们都是软件设计师,我们是在设计软件,而不是构建软件。(这一观点出自于Jack Reeves的《源代码就是设计》,《敏捷软件开发-原则、模式与实践》附录D) 设计软件不是凭空的,你总是要以某一种编程语言来设计。和语言无关的设计,只能算是概要设计,只能做到一定的程度。要做详细设计必须和某一种语言相关。 以上只是我的一家之言,希望能给其他的初学程序设计的程序员一些帮助。 |