也谈编程本质
by johnnyxia
最近在网上看到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）
设计软件不是凭空的，你总是要以某一种编程语言来设计。和语言无关的设计，只能算是概要设计，只能做到一定的程度。要做详细设计必须和某一种语言相关。
以上只是我的一家之言，希望能给其他的初学程序设计的程序员一些帮助。
