谈谈技术原则，技术学习方法，代码阅读及其它

一、选用技术的原则

比较规范的软件开发过程要到有限的几个公司才能学到。偶现在所采用的方法都是圡方法，主程序员，测试驱动，文档和代码写在一起，原型。但基本上坚持几个原则：

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

偶写过的第一个实用程序是把一个法律光盘导入到数据库中，光盘源文件格式需要分析。数据大概几万条。一种方法是写程序直接导入，另一种方法是写一个界面，手工导入。偶选择的是后者。程序界面如下：有一个文本框，有一个大按钮，按钮有一本书那么大，这样设计的原则是让闭着眼睛就能够点中。让一个会灌水的哥们，ctrl + c, ctrl + v，不停的灌。文本贴过去，自动解析，放入数据库。左手alt + tab ctrl + c/v， 右手点鼠标，这样有节奏的运动。很快，几个小时就把数据弄完了。最初设计的一个文本框，一个按钮，很pp，但是老点不中。随即偶才把那个按钮做成老大的，就这一个改变，生产力提高了1倍以上。

工作，就要坚持这样的原则。要能够分辨出价值，找能够提高价值的去做。即使这样违背一般规律，违背技术教条。

学习上以简单，核心的东东为主。可学可不学的不要学。复杂的东西除非你想要成为这方面的专家，就不要学。偶还是举自己的一个例子，前一阵做GIS有需求，具体实现偶负责。预算很少。偶就定了开源GIS软件这条路，本来想用C#的，但没有好用的开源GIS软件，偶决定用java写。偶手下还没会java的。偶选择了一个开源lib，让一个哥们运行一个Demo，然后让他从那个Demo的main函数画函数调用图一直画到数据库调用。偶呢，跑去看GIS规范，然后他的图，结合偶的规范知识，很快就知道这个软件中间分了多少层，每个层每个接口是干什么用的，怎么调用。这个软件的优点缺点。然后体系结构，设计就出来了，然后2个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等有特定格式的文件，碰上这些怎么操作。

三、对MSF的一点心得

软件过程控制方面主要也是解决一些问题。代码、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来说,一般一个500~1000个类的库/软件,主要的类或接口大概在10~20个左右,一般来说,这些类构成一个层次关系.每一层,这些类或接口会有一大堆子类/实现.大概在数百个左右.剩下的类基本上都是工具类,辅助类,获取特定资源的类.第一步应该是找到这些主要的类和接口,找出主要的调用过程,清楚这个过程.这样,差不多就明白这个软件/库是怎么工作的了.第二步,是看这些主要类,接口的继承/实现,这样可以了解这个软件/库可以做什么,怎么扩展.这样,一个数M代码量的东东,可以在2~3天的时间里把它弄清楚.

阅读代码的主要难度就是代码量太大,但是OO极大的减低了代码阅读的难度,好的OO软件一看见namespace, 类名,方法名就知道干什么的(在阅读较多代码后就能形成这种直觉)就不必要去阅读具体的代码了.阅读的难度通过工具能降低很多:通过逆向工程获得类图和主要调用过程的序列图,通过这两图的阅读,就差不多了.Ndoc，Visio，doxygen，甚至word都是有用的辅助工具。实在不能明白的就看代码.软件的骨架大概就是这些,除此之外,每个软件可能会涉及到一两种核心的算法或它独特的数据抽象(数据结构),实现某种规范或者某种已知的算法,这时候看看这些规范或已知的算法,结合代码很快就理解了.此外,还有一些细节性知识分散在那些辅助类里面,了解骨架后,对这些东东大概有个底了,但不能准确的确定.这时候google,看看大家怎么用的,有什么注意事项.阅读代码如果顺序不对,第一头就扎进这些细节,那就完了.对主要流程的掌握和对层次的掌握是第一位的.对设计模式的了解还是其次. 还有很多非OO软件,采用这种方法,也是很容易读的.比如,阅读协议栈代码,跟着一个包走一圈.在企业中,围着一个订单走一圈.这些都是非常有效的处理复杂系统的方法.在OO中嘛,就是跟着方法走一圈.选中一个方法,跟着它走一圈.这个方法选的好的话,这一圈基本上就把这个软件/库转个差不多了.在这个过程中可能要碰到几十个对象,上百个方法调用,搞懂了,就差不多了.但是,阅读主线不能乱.

支持