软件开发的难点及一些应对方法

1.“没有银弹”

对付狼人的终极武器是银弹。然而，在软件开发领域，这样的“银弹”似乎并不存在。

软件开发活动可以分为2个部分：

1. 根本部分，即打造构成抽象软件实体的复杂概念结构。这是软件特性中的固有困难。
2. 次要部分，即使用编程语言表达这些抽象实体。这是出现在目前生产中，但并非与生俱来的困难。

软件生产率在近些年取得了巨大进步，这主要得益于硬件性能的提升，以及编程语言的日益丰富和灵活，使得次要部分的实施变得更加容易。然而，根本部分中的困难依然存在，包括以下几个部分：

1. 复杂性：规模上，软件内部结构十分复杂，因为没有任何两个软件实体是相同的。如果有相同的情况，我们会把它合并成供调用的子函数。而且，软件实体的扩展带来的复杂度增加也不是线性的，因为这些实体以非线性递增的方式交互。复杂度导致了许多技术上和管理上的问题，使开发慢慢变成了一场灾难。
2. 一致性：软件工程师所面对的复杂度很多情况下是随心所欲、毫无规律的，它们来着若干缺乏一致性的人为惯例和系统。
3. 可变性：软件实体经常会遭受到持续的变更压力，特别是那些成功的软件。软件产品扎根于文化母体中，如各种应用、用户、自然及社会规律、计算机硬件等，后者的持续变化也强迫着软件随之变化。
4. 不可见性: 软件的客观存在不具有空间的形体特征，也就没有已知的几何表达方式。这种缺陷不仅限制了个人的设计过程，也严重的阻碍了思路相互之间的交流。

下面2节将介绍一些应对软件开发中的困难的方法，包括管理上的和技术上的。

2.敏捷开发

2001年初,由于看到许多公司的软件团队陷入了不断增长的过程（software development process）的泥潭,一批业界专家聚集在起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观( value)和原则。他们称自己为敏捷( Agile)联盟。在随后的几个月中,他们创建出了一份价值观声明。也就是敏捷联盟宣言( The Manifesto of the Agile Alliance)。

敏捷开发的价值观：

1. 个体和交互胜过过程和工具：合作、沟通以及交互能力要比单纯的编程能力更加重要。
2. 可以工作的软件胜过面面俱到的文档：没有文档的软件是一种灾难，然而，过多的文档比过少的文档更糟。编制以及维护众多的文档需要花费大量的时间，如果代码和文档之间失去同步，那么文档就会变成庞大的、复杂的谎言。对于团队来说，编写一份一二十页的系统原理和构架文档是一个好主意，更细粒度的文档应该以注释和单元测试的形式存在于源代码里。
3. 客户合作胜过合同谈判：成功的项目需要有序、频繁的客户反馈，合同中的条款很有可能在项目完成之前就变得没有意义了。成功的的关键在于和客户之间真诚协作，而不是试图去规定项目范围的细节和固定成本下的进度。
4. 响应变化胜过遵循计划：响应变化的能力常常决定一个软件项目的成败。

从上述价值观中引出了下面12条原则，它们是敏捷实际区别于重型过程的特征所在：

1. 最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2. 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3. 经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
4. 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
5. 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
6. 在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。
7. 工作的软件是首要的进度度量标准。
8. 敏捷过程提倡可持续的开发速度。責任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9. 不断地关注优秀的技能和妤的设计会增强敏捷能力。
10. 简单——使未完成的工作最大化的艺术——是根本的。
11. 最好的构架、需求和设计出自于自组织的团队。任务应该分配给团队，然后再由团队来确定完成任务的最好方法。
12. 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

上面只是讨论原则和价值观，下面来讨论具体该怎么做。

现在已经有许多敏捷过程可供选择，包括：SCRUM，Crystal，特征驱动软件开发（FDD）,自适应软件开发（ADP），以及最重要的极限编程（eXtreme Programming，简称XP）。

极限编程由一系列简单却相互依赖的实践组成，这些实践结合在一起形成了一个胜于部分结合的整体。如下所示：

1. 客户作为团队成员：客户和开发人员在一起紧密工作，以便于知晓对方所面临的问题，并共同去解决这些问题。
2. 短交付周期：每2周交付一次实现了部分需求的软件，以得到客户的反馈。
3. 验收测试：验收测试使用某种可以让它们自动并反复运行的某种脚本语言编写，这些测试共同来验证系统按照客户指定的行为运转。
4. 结对编程：所有的代码都是由两个程序员,并坐在一起在同一台机器上构建的。结对人员中的一位控制键盘输入代码，另一位观察输入代码并寻找代码中的错误和可以改进的地方。他们可以随意的互换角色，且至少一天改变一次。这样可以提高软件质量、增进交流，进而提升开发效率。
5. 测试驱动开发：编写所有产品代码的目的都是为了使失败的单元测试能够通过。首先编写单元测试，然后再编写使单元测试通过的代码，二者在项目开发中共同演变。这样不但能快速测试代码，还有利于解除不同模块的耦合。
6. 持续集成：团队总是使系统完整地被集成。结对人员在完成某个功能并通过测试后会尽快提交代码，使代码仓库保存最新的状态。
7. 集体代码所有权：任何结对的程序员都可以在任何时候负责任何代玛。
8. 可持续的速度：团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作,他们保存精力，她们把项曰看作是马拉松长跑,而不是全速短跑。XP的规则是不允许加班，除非在版本发布前。
9. 计划游戏：其本质是划分客户和开发人员的职责。客户决定特性的重要性，开发人员决定实现一个特性所花费的代价。随着项目的短周期迭代，很快客户和开发人员就会适应开发节奏。
10. 简单设计：团队保持设计恰好和当前的系统功能相匹配，不去过多的关心未来要实现的功能。极限编程者对冗余代码零容忍。在消除冗余代码的过程中会提炼出很多抽象，这会进一步减少代码间的耦合，使得系统构架易于改进。
11. 重构（refactoring）：重构就是在不改变代码行为的前提下，对其进行一系列小的改造或变形，使得代码结构变得简单、易于理解、无冗余、低耦合。重构需要持续进行，是每天、每小时都要做的事情。
12. 隐喻（metaphore）：通过某种比喻，形象的概括系统的结构或运行方式，使得项目易于理解。

极限编程是一种优良的、通用的软件开发方法。项目团队可以直接采用，也可以增加一些实践，或对其进行一些修改后使用。

3.敏捷设计

为了保证软件的敏捷性（agility），我们需要避免一些软件设计中可能出现的问题。如下所示：

1. 僵化性（Rigidity，naive）：单一的改动会导致许多其他部分需要改动，使得难以对系统进行改动。
2. 脆弱性（Fragility）：对系统的改动会导致系统中许多概念上与被改动部分无关的部分出问题
3. 牢固性（Immobility）：设计中包含了对其他系统有用的部分，但难以把这些部分从系统中分离出来。
4. 粘滞性（Viscosity）：系统难以使用，导致做正确的事情比做错误的事情困难。
5. 不必要的复杂性：设计中包含不具备直接好处的基础结构。
6. 冗余：设计中包含重复结构，而这些重复结构本应该使用单一的抽象统一。这样重复使得系统的改动代价变高。
7. 晦涩性（Opacity）：难以阅读和理解。

上述问题的存在可能导致软件在迭代过程中迅速腐化，难以理解、维护及改进。在软件设计中遵循下述原则可以很大程度的避免这些问题：

1. 单一职责原则（SRP）：就一个类而言,应该仅有一个引起它变化的原因或功能。也就是说，一个类或模块应该只负责一个功能。
2. 开放一封闭原则（OCP）：软件实体(类、模块、函数等)应该是可以扩展的,但是不可修改。也就是说，可以通过增加类来扩展已有功能，而不需要直接修改已有的代码。OCP背后的主要机制是抽象和多态。
3. Liskov替换原则（LSP）：子类型必须能够完全替换掉它们的基类型。也就是说，子类实现抽象接口时，不应该擅自改变软件系统对接口行为的规定。
4. 依赖倒置原则（DIP）：高层模块定义底层模块需要实现的抽象接口，让底层接口来适应高层模块定义的抽象。这样方便于替换底层模块。
5. 接口隔离原则（ISP）：不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构.
6. 重用发布等价原则（REP）：重用的粒度就是发布的粒度。
7. 共同封闭原则（CCP）：包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响,则将对该包中的所有类产生影响,而对于其他的包不造成任何影响。
8. 共同重用原则（CRP）：一个包中的所有类应该是共同重用的。如果重用了包中的一个类那么就要重用包中的所有类。
9. 无环依赖原则（ADP）：在包的依赖关系图中不允许存在环。
10. 稳定依赖原则（SDP）：朝着稳定的方向进行依赖。也就是说，稳定的包不应该依赖不稳定的包。
11. 稳定抽象原则（SAP）：包的抽象程度应该和其稳定程度一致。也就是说，稳定的包应该包含一些抽象类，以方便功能扩展。