主题：【原创】编程心得 -- 荆棘探兴

在后来就是看别人的代码，自己写代码摸索了。。。

书上的来终觉浅啊，还得实践。

掌握了它就掌握了硬件。打下了坚实的基础，学别的语言不过是几个小时的事情。

然后一番OOOOXXXXX，省力省功。对应用层开发比较迷糊的人路过。。。。。

俺一辈子就没法集中精神听课，听听就走神了。只能自己看自己想才能进入书中

恭喜：你意外获得【通宝】一枚

鲜花已成功送出，可通过工具取消

提示：此次送花为【有效送花赞扬，加乐善、声望、帖得花总数】。

我编程也有6年多了，在西西河应该不算多，不过最近天天猛写代码，遇到各种各样的需求，也写了各种各样的代码，对编程中同到的各种难题和各种相似的工作思考了很多，也说一说我的想法。

我暂且将普通人描述出的语言称为自然语言，自然语言具有模糊，逻辑不严密，不确定性非常多。人脑可以走一步看一步，具体问题具体分析，“如果这样就那样，如果再这样还可以再这样”，可以拥有所有的信息，“当XX在XX的时候就XX，当XX发生XXX的时候就XX，如果那个XX是XX的状态就XX；如果在XX的同时又发生XX且XX的状态是XX的时候就XX”之类；

但写好的程序不行，写的时候是什么样跑的时候就是什么样。计算机语言就是非常确定，不能看情况而定。程序没有人耳朵没有人眼，不能在需要时随时去查看发生的所有情况，除非程序预先将各种数据记录下来了（并及时保持更新）。

所以，编程主要解决两个问题：

1.将抽象的自然语言转换成严密的机器语言，不能错，不能漏，无不确定性;所有情况要考虑到，所有数据要组织好。

2.从需求中抽象出真正的需求，并建立相应的模型，然后用程序描述之。

1偏向于coding，而2更偏向于design一点，中间到没有明显界限。

在1里需要处理太多流程太多细节太多信息，以普通的人脑不可能同时装下所有东西，所以很容易遗露，要么是没考虑到特殊情况，要么是设计出的代码非常难懂难看难改难复用，要么就在一些小地方犯一些弱智的错误，比如变量名写错之类的。对于这些问题有一些解决办法，比如建立好的编程习惯编程规范（用习惯杜决意外的小错误），测试驱动开发（用测试保证在持续开发中没有新问题），耦合内紧外松（集中思维到部分点避免网状关系），面向对象编程（数据与操作的集中，并提高抽象层次），设计模式（现成成熟模式直接利用）。这些好东西都是尽量让程序员需要考虑的东西简单化，集中化，模式化；减少了写程序里程序员大脑里要考虑的东西,解脱程序的大脑，那就减少了出错的机会。

关于2，稍微偏设计一点，更多的像是对需求的一种翻译，建立起的模型既要灵活易扩展，又要简单易懂易实现，更重要是要很严密的实现需求（按1的标准）。这里的需求不只是指来自客户的需求，也有来自软件开发本身的，比如可复用功能，模块通信机制，模块生命周期管理等等。

编程中我还遇到的一个比较突出的问题就是重复机械劳动非常多，这里的重复并不是指完全的重复，往往很多需求是大体上基本一样，但细节却各不相同，程序员不得不花大部分时间去处理这类毫无新意的东西；而如果建立和实现一个能适合所有这类变化的模型的话，它需要的代价有时候却又远超过手工完成两个或三个需求的代价； 甚至有时候“细节是魔鬼”，一个细节分析深一点就会发现之前模型都不能复用了。把大部分时间花在这些毫无创新的事上让我很有挫败感，但感觉解放程序员唯一办法是继续提高程序的抽象层次，让程序员可以在更接近自然语言的层次上思考问题，避免过多细节，有一个思路就是走以前汇编-》C语言-》C++的路子，当然这要求底层有更好的支撑库，以及更好的硬件。

从数学角度说，软件需求如同一个方程式，而最终程序是一个解。从基本指令出发，对需求得出一个程序解，如同从基本定理出发，对一个方程推导求解一样。因此，理想化的编程应当如数学推导一样，每一行代码都经过严格证明，最终的程序才能说是正确的。但是这是一个非常难的问题，所以实际工作中只能靠程序员和用户不断测试修正来完善程序，这个过程类似于在数学中对方程无法求得解析解，而采用迭代法逐次逼近求数值解一样。

从工程角度说，软件的结构设计，编程规范决定软件是否易于维护，就是有了大致解法后如何施工的问题。结构设计良好的软件易于重用修改升级。现在程序员多数思考都着重于这一方面，如各种设计模式。

软件的数学性代表代码的正确性，而工程性代表代码的条理性。两者有一定相关度，但却没有必然联系。一个设计糟糕写法混乱的程序仍然可以是完全正确的，而一个设计优雅的程序却可以充斥大量错误。

所谓软件模块化，低耦合度，其实就是分而治之的思想，也就是所谓的分析。将一个大的复杂问题分解成若干相对独立的子问题然后逐次解决。这是对任何领域都有效的。

只要架构师抽象的足够好，找几个新手码字就可以了

降低了开发难度

至于线程方面，现在进入多处理器时代，虽然有一些库能实现与硬件无关的线程管理，但做的并不好。

erlang最近两年大受关注，也是源于其在语言层面上的对并发的支持。Scala既是受erlang启发而发明的语言，运行在jvm上，如果想学Java的话不如学下Scala。

特别是搞 MIS 方面的

不但在多线程和函数编程方面有优点，在多继承上也比Java灵活。个人来说我喜欢Scala超过Java。

Scala的缺点就是用的人不够多，光学个Scala自己玩玩还行，要真有要和别人一起合作的时候，恐怕不容易找一个也用Scala的人。而且Scala初学者不容易上手。其实要学Scala的话，先学Java再学Scala和直接就学Scala，在花费的精力上恐怕没啥区别，所以还不如先学Java，然后再决定是不是继续学Scala。

技术的发展史，你说的这些就很明白了，可惜啊，人总是要感悟好久才能明白这些道理。

目前就那么几种计算模型。

当然几个小时只是初步掌握，特别是相近的语言是很类似的，比如VB.net和C#背后的计算模型是一样的，差别就是关键字和语法。

要真正掌握一门语言，我的意思是说能用来做点严肃的程序，是需要付出非常大的努力的。主要精力是花费在学习和掌握各种程序库和框架，以及由最佳实践和惯用法，语言的设计哲学等等组成的社区文化。这些才是真正的power所在。

希望你没有误会，我只是强调上面这些东西比一门语言自身的语法关键字什么的重要多了。