标签：style ar os 使用 sp 文件 数据 on art
Part 1 No Silver Bullet - Essence and Accidents of Software Engineering（没有银弹）
完读brooks的《没有银弹》这篇文章，我觉得他的主要观点就是：即使改进编程语言，软件工程的生产率在10年内也不能获得数量级上的提高，因为软件工程最大的问题在于解决概念完整性和处理沟通。作者在对问题进行分析时，并不是人云亦云，他反对很多流行的论断，他做出判断的依据通常是基于常识和经验的理性推理，他这种客观的分析方式同样值得学习，一下几点是我对这篇文章的总结和一些心得，如若有误，还劳烦批评指正。
一个相互牵制关联的概念结构，是软件实体必不可少的部分，它包括：数据集合、数据条目之间的关系、算法、功能调用等等。我认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概念进行表达和对实现逼真程度进行验证。当然，我们还是会犯一些语法错误，但是和绝大多数系统中的概念错误相比，它们是微不足道的。如果这是事实，那么软件开发总是非常困难的，天生就没有银弹。
软件工程牵涉的问题是非常复杂的，不似于大多说日常事务。由于软件产品特有的复杂度导致了成员之间的沟通非常困难，带来了软件产品的进度，质量和成本多方面的问题。特别是在软件规模增加的时候复杂度往往成倍上升。同时复杂度不仅仅导致技术上的困难，还引发了很多管理上的问题。它使全面理解问题变得困难，从而妨碍了概念上的完整性。而且
必须遵循各种接口，考虑到各种环境的兼容，这些特性是无法通过设计改变的。
不仅如此，软件开发的过程必须要考虑如何适应变化，在需求，设计和编码过程中都需要考虑如何快速响应变化，如何提高软件产品的可扩展性。但是这些问题目前也没有行之有效的解决方式。而且软件结构上的限制和简化方面的进展，软件仍然保持着无法可视化的固有特性，这种缺憾不仅限制了个人的设计过程，也严重地阻碍了相互之间的交流。
所以就目前来讲，我们所做的项目只能按部就班，按照目前软件工程的既定步骤，逐步地完成。除了认真学习所学知识，团结协作，没有什么捷径可用。
Part 2 big ball of mud你的项目有一个大泥球么? 有什么解决办法？
所谓大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这些年来，为了对付这个泥球，多种指导方法一起出现，然而实际情形没多大变化，“大泥球”看起来仍然是设计软件架构的最常见方法。我们现在惯用的敏捷性开发的很多方面会直接导致泥球，包括：缺少前期设计、应对需求变化过晚、应对架构变化过晚、碎片式增长。
我们理想中的代码是清晰的，优雅的，坐在电脑前深呼吸，都能闻到雨后泥土的芬芳。但是现实是，一打开编译器就头痛。代码看得眼花，整天去修BUG，还要花半天时间先读以前的代码。好不容易改完提交了，第二天却报出更多的新BUG。
其实，我们的软件，在发布前，其实就已经百病缠身了，随着功能的增加，便有了BUG，老的BUG改了，可能引入新的BUG。复杂的商业软件多少都会有BUG。我们思考这样几个问题：我们如何发现烂代码？烂代码要不要改呢？应该怎么改？如果烂代码不是先天性的，那是不是可以预防？
很多时候无论花费多少时间试图去找出完美的软件结构,客户总是引入一个变化破坏这个结构,不存在完美结构,只存在那些试图平衡当前的代价和收益的结构。有时候,我们会把原因归咎于客户,责怪他们总是改变需求。有些人认为,只要客户的需求仅限于他们最初所声明的,那么我们的设计就是没问题的,所以错就错在客户改变了他们的需求。需求变化是非常正常的，JOBS说“用户根本不知道他想要什么，直到你把产品交到他的手中”。这种情况也是或多或少存在的。但是，客户连源代码都看不到，这种怨念却是没道理的。
结合我自己的编程经验，可以将其产生的原因总结为：一次性代码，碎片式增长，缺少前期设计，应对需求和架构变化过晚，程序员的经验，技巧，眼界的限制。
我们团队的代码中也肯定存在着大泥球，有些已经被发现的我们都已经尽力优化，当然在这个ALPHA版本中肯定还存在一些还没被发现的大泥球，我们将在剩下的一周测试的时间和BETA版本中，对这些问题进行处理。
Part 3 CatB – Cathedral and the Bazaar
我认为作者写这篇文章，是鉴于当时的自由软件开发的现状。他不满于当时开发软件的低效率，而且，他认为，低效率的原因在于除错阶段花费了大量的时间。由此，他把开源软件的开发模式分为两种，一种是大教堂模式，源码公开，但是开发过程有一个团体控制；一种是市集模式，同源源码公开，且源码放在互联网上供人阅览，并可以贡献代码，进行开发。并且提倡市集模式，认为在足够的人的检视之下，BUG将无处藏身。
在我来看，市集模式既然能为全世界所接受，必有其优点所在。所谓“众人拾柴火焰高”，当然软工工程不能类比于“拾柴”，不过道理确实是这个道理。不论是市集模式还是大教堂模式，都有其优缺点所在，关键是找到其适用的场景。这个观点虽然中庸，不过确实是实话。我以为，大教堂模式，适用于小的项目，或者是团队中有一个技术大牛带领，不需要过多的人来指点。而市集模式，则是那种涉及的方面比较广泛的项目，且不论如何，应该有一个几个人的团体对于项目的整体走向、代码有绝对的控制力，否则，会造成难以预料的混乱局面。
我们当前的项目可以说是类似于大教堂模式。我们的源码是完全由自己开发的，而且除了本组的人外，也并没有人其他的一些人关注这个项目，不具备市集模式的要求。
Part 4 Lost in CatB这些情况在你的团队中出现过么?
作者主要讲述了开源软件中的过度依赖问题，这个问题在实际问题中我也遇到过，有的程序包含了各种库，包括图片库png，jpg等，压缩库zlib，其中图片库中又包含了压缩库zlib，主程序中光zlib这一部分代码就有3个版本，非常混乱。而有一天看到了一个游戏依赖的运行库竟然有十多个，既有C++运行时库，又有.net，而且还需要各种不同的版本，给用户安装造成了很大困难。而我们项目的上一版本中的开发存在一些问题，上一个版本的文件格式非常混乱，同时使用了纯文本，xml，二进制文件和数据库4种不同的方式存储数据，这不但增加了复杂度，同时也是一种浪费，文件加载的代码就非常多，也增加了运行时开销。
Part 5 Managing the development of large software systems: concepts and techniques
我觉得瀑布模型的其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。
瀑布模型有利于大型软件开发过程中人员的组织及管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。而对于我们这种较小规模的软件开发项目，瀑布模型并无裨益。
Part 6 软件工程的方法论到底有多少用处?
由于以计算机为基础的系统在数量、复杂程度、应用方面的增长，对无处不在的计算机软件提出了更高的要求：更广，以解决层出不穷的应用问题；更精，以安全可靠地完成各项任务；更简便，以适应千家万户的使用普及。要达到这一目标，仅依靠的现有的思想方法是不够的。
在软件技术的发展道路中，方法论起着决定性的作用。软件技术人员有必要站在哲学的高度、从方法论的角度，重新审视软件开发过程中各个环节，深刻体会软件工程和方法论的联系，从而改进和发展的现有的软件工程技术，消化吸收先进的思想、方法和技术，提高软件的质量和生产率，以适应现实世界对软件产业新的要求。软件工程应运而生。为了更好地发展和改进软件工程技术，我们有必要从方法论的各个角度分析软件工程的方法、工具和过程，从而有的放矢地改进软件工程中各个过程的思想、方法、模式和规则。
标签：style ar os 使用 sp 文件 数据 on art
原文地址：http://www.cnblogs.com/ksven/p/4094759.html
