对编程的一些认识

偶和你一个水平，这些东西都半生不熟的。比较规范的软件开发过程要到

有限的几个公司才能学到。偶现在所采用的方法都是圡方法，主程序员，

测试驱动，文档和代码写在一起，原型。但基本上坚持几个原则：


在工作上以实用为主导，哪个实用学哪个，要以最小的努力获取最大的成效。


偶学.net是因为管的几个asp网站要升级，学java是因为要写GIS或Spider，

C#没有类库，一起用C#写个类库不如用java写。偶写过的第一个实用程序是把一个

法律光盘导入到数据库中，光盘源文件格式需要分析。数据大概几万条。

一种方法是写程序直接导入，另一种方法是写一个界面，手工导入。偶选择

的是后者。程序界面如下：有一个文本框，有一个大按钮，按钮有一本书

那么大，这样设计的原则是让闭着眼睛就能够点中。然后在水木上发招聘

招聘就一个要求：会灌水！！然后让他ctrl + c, ctrl + v，不停的灌。

文本贴过去，自动解析，放入数据库。这个人就这样，左手alt + tab

ctrl + c/v， 右手点鼠标，这样有节奏的运动。很快，几个小时就把数据弄


完了。最初设计的一个文本框，一个按钮，很pp，但是老点不中。随即

偶才把那个按钮做成老大的，就这一个改变，生产力提高了1倍以上。

工作，就要坚持这样的原则。要能够分辨出价值，找能够提高价值的去做。

即使这样违背一般规律，违背技术教条。


学习上以简单，核心的东东为主。可学可不学的不要学。复杂的东西除非你

想要成为这方面的专家，就不要学。偶还是举自己的一个例子，前一阵做GIS


有需求，具体实现偶负责。预算很少。偶就定了开源GIS软件这条路，本来

想用C#的，但没有好用的开源GIS软件，偶决定用java写。偶手下还没会java

的。偶选择了一个开源lib，让一个哥们运行一个Demo，然后让他从那个Demo

的main函数画函数调用图一直画到数据库调用。偶呢，跑去看GIS规范，然后他

的图，结合偶的规范知识，很快就知道这个软件中间分了多少层，每个层每个

接口是干什么用的，怎么调用。这个软件的优点缺点。然后体系结构，设计就

出来了，然后招了几个会java的，很快就做出来了。以上面例子说说学习软件的技巧

要学一个东西，要学习该东西的两类知识：结构和细节。结构性的东东非常重要.

学习结构，就可以开始干事了，学习细节，能够把这件事情干好。结构不清楚，

细节再好都不算了解。结构很简单，就是纵，横两条线。纵的来说，就是一个

程序的执行，你得知道哪一步在做什么。以ASP.Net来说，就是从收到

Request到返回一个页面，中间的调用过程，这是主线，再进一步，程序的加载

->接收Request(->缓存，Session机制）->返回一个Page，这个过程清楚，Asp.Net

也就差不多了。纵向一般是通过接口调用的，看源代码很快就可以搞定。

横向就是看看重要的接口，重要的抽象类有哪些实现，知道哪个实现用于

什么地方，有什么优缺点。那么就算在结构上学好了。剩下的就是细节问题了。

细节问题熟练自然很好，不熟练google都能google到，只是要花很多时间。

这样学习我觉得是最有效的学习，不必去跟踪技术前沿，当一个技术在你眼前

你很快就可以看出它的骨架，优点缺点，性能，至少能估计到大致的范围。

这样慢慢培养对一个技术的悟性，做到举重若轻，知道什么地方可能有陷阱，

什么地方可能有创新。把握住重点和脉络。


细节上就是不断实践，不断重构。一个有用的软件，你不断提出更高的要求，

不断重构，用不了几遍，几种重要的设计模式就了熟于心了。单为学习模式

而去学习模式是不可取的。每个模式都针对一定的问题。深入理解这些问题

才是学习的关键！技术是多种多样的，是变化非常快的，但是技术所要解决

的问题却并不多。


从架构级别来说，所面临的问题主要有：（1）解决复杂性－－如何把复杂变得

简单？这里的观点就是封装，OO是一种封装，还有别的封装方式。重构书中

讲了很关键的一点，就是要使你的类名，方法名能清晰表明它的身份和功能。

（2）解决程序演化与扩展的问题－－组合优先继承，怎么暴露API，怎么写文档，

总之，让程序演化与扩展越简单越好；（3）性能问题－－80/20原则，性能测试

怎么测试，怎么评估，不同使用场景中的性能，缓存机制；（4）功能问题－－

主要功能总得实现吧，这个和业务有关；（5）易用性；（6）纵向扩展，横向

扩展，并发......（7）自己开发还是采用第三方插件还是外包以及选择问题。


具体的学习，偶推荐问题导向，案例为基础的学习，不要拘泥于语言，要学习

能学习到的最好的东东。比如，性能的关键在调度，这时候可以看看资源

调度模式，hibernate算是把资源调度玩到了极致。基于事件的调度（如.net中的

web cache），进程调度，线程调度，工作流，这些都算是行为调度，要是把这些

东东融会贯通，掌握每一种实现的优点缺点。那么软件设计中所有和时间、并发、

资源相关的东东都不在话下了。行为调度可以看看.net 中的cache实现，找一个工

作流软件看看，找找几个线程框架看看，看看几个典型操作系统的进程调度机制。


具体到实现上，所面临的问题无非是：

（1）对象的创建及销毁；（2）对象的封装和继承体系；（3）对象的粒度和语义划

分；（4）对象的复用；（5）对象的测试；（6）对象的持久化；（7）具体的API

暴露；（8）常用Collections；（9）算法问题；（10）性能问题；（11）回调；

（12）消灭语义沟；（13）我想要和你一起变懒......；（14）我能采用哪些API


（15）对象的管理；（16）异步调用；（17）远程调用


具体问题不多，每一个问题又有一些使用场景，每一个场景可以采用几种模式实现，

每种模式有哪些变种，模式和变种有哪些优点缺点......要了解这些可不容易

拿对象的创建来说吧，有这些情况：

（1）一锤子买卖：直接new就行了

（2）你是我的唯一：单例

（3）千年等一回：对象池，原型，缓存

（4）似曾相识燕归来：享元

（5）我看过GOF：工厂，抽象工厂

（6）不要问我从哪里来：IOC

具体到实现中，细节也很重要。但所谓的细节，涉及的方面扯过来扯过去就那几点。


再向上一级别的实现，无非就是UI，业务，数据接入这三层，再加入一个集成层也可以。

UI无非就是那几种模式，用的多无非就是以模板为主的和以控制为主的，业务上耷拉耷拉

还有一些主要的模式，数据接入主要就是那三种模式。ADO.Net细分下去也有两种使用模

式。数据库有要钱的有不要钱的有进程外的有进程内的有复杂的有简单的。文件有普通文件

有带索引的文件有html,xml等有特定格式的文件，碰上这些怎么操作。


软件过程控制方面主要也是解决一些问题。代码、Bug，需求，文档，交流，发布，风险


偶从MSF中学到的唯一的东东就是Tradeoff（权衡/取舍），MSF的最有价值的思想应该

就是取舍。要达到什么目的，给定什么，选择什么，放弃什么。偶两年前对MSF有过很

长一段时间研究，写过一篇Case（放在网上某库，看要花钱买，嘿嘿）。以前软件主要

用于工业用途，稳定性很重要，程序老挂可不得了。90年代初软件应用从工业领域过渡

到普通应用领域，功能和可获得性变得很重要，稳定性大家不看重，Windows脱颖而出。

MSF最初版本就是那几年成型的，从那开始，微软的Trade-off基本上是进度优先于功能，

功能优先于稳定性，安全性。最近微软的Trade-off变了，稳定性，安全性排的比较靠前。

当年背景是微软开发队伍变大了，开发管理有些混乱。于是微软组织了一批高手，总结

开发过程中的经验，形成MSF最初版。随着时代发展，MSF逐渐演化成现在的版本。当前

的MSF被微软当作一个过程方法，向外界推广。偶的看法是，MSF首先是微软自己成功经

验的总结，其次才是一种可参考的过程方法。MSF是教怎么成功的开发软件产品，而不是

怎么达到项目需求。并且，MSF不是普适的。有一本书，叫做《自适应软件开发》，那本

书实际上是MSF的最佳诠释，只有在什么样的组织里应用这种方法那本书分析得很透彻。


归纳起来，大概偶觉得有用的方法就是这四种：


拜师学艺：以案例为主的学习，第一手资料最可靠。多看源码，多看现有方案。没事

多写代码。


左右互博：同样的问题，多学习多研究几种解决方案。只学习一种容易障目，不通过

比较，不能清楚某种软件，某种解决方案，某种设计模式的优缺点。在时间可能的

情况下，多试一试不同的解决方法。


庖丁解牛：拿到东西就横竖两刀，分成横向的肋骨和纵向的脊椎，剩下的都是皮肉。

对于绝大多数OO软件都实用。不实用不是你的问题，是软件写的有问题。对于自己写

的软件，没事也可以试一试劈一下，软件没哗啦哗啦散开证明写的有问题。


吸星大法：任何软件都有历史问题，任何方法都有历史问题。软件要兼容呀，公司要

宣传呀，所以很多东东不是它表面的那样。.net对底层绑定的那么厉害，这些都是历

史遗留问题。所以，学习一个东东，最好向前翻几个版本，看看在该软件演化过程

中发生了哪些故事，这些故事的背景是什么，每个故事都意味着一些trade-off，

从中间可以学习很多软件设计知识，这样学习，相当于把别人的实战经验据为己有，

多爽啊。这样做的另一个意义是可以培养自己对技术的预测能力，比别人多看一步

就是一个很大的优势。


说了半天说的都是一些虚的问题，不过，OO不就是抽象嘛。老外有一门OO课程的名

字叫做什么“OO技术－－对世界的模拟”。从这个角度看OO比从技术的角度看至少要

好玩一些。


偶现在在技术水平上其实和你差不多。2000-2002:ASP，2003，Asp.net,c#,

2004 C++，2005 java， 预计2006 c++。感觉自己在水平上有2次大的

进步。在2003年仔细琢磨了MSF和微软几个产品的开发Case，感觉水平有了提高。

第二是2004年对底层折腾了个翻天，对一些机理性的东西有了很大的了解，对源

代码不抵触了。2003,2004两年没怎么深入接触.net，今年上半年没事翻了翻.net，

写了写程序，头脑中一下就清晰了。拿起java也是轻车熟路，1天生，2天熟。

不过偶对细节的把握不是很好，变量命名啊，具体模式的实现啊，2006年的重点

就在细节了。

转自 : http://my.opera.com/changfeng/blog/?id=73223