|
|
文件有普通文件有带索引的文件有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中嘛,就是跟着方法走一圈.选中一个方法,跟着它走一圈.这个方法选的好的话,这一圈基本上就把这个软件/库转个差不多了.在这个过程中可能要碰到几十个对象,上百个方法调用,搞懂了,就差不多了.但是,阅读主线不能乱. |
|
发表于 
提升卡
置顶卡
喧嚣卡
变色卡