持续集成的核心概念

CI 过程会经常构建软件组件；在许多情况下，每当源代码存储库（比如 Subversion 或 ClearCase）中的代码发生变化时，都要构建软件组件。CI 的好处是：经常构建软件可以确保尽早遇到问题（比如代码缺陷），避免问题在软件开发周期晚期变复杂时才被发现。

工具与过程

尽管 CI 实际上是一个过程，但是持续集成 这个词常常与一个或多个工具相关联。在本教程中，讲解如何安装、配置和使用 Hudson 作为 CI 服务器，但是要记住，CI 远不只是个工具。实际上，使用的工具可能是 CI 比较次要的方面，因为 CI 工具所做的仅仅是在代码存储库中探测到修改时运行构建。构建过程本身比用来运行它的工具重要得多。

开始使用 CI

开始使用 CI 需要三个组件：

• 用 Ant 或 Maven 等工具建立的自动构建过程
• 一个代码存储库，比如 CVS 或 Subversion
• 一个 CI 服务器，比如 Hudson，但是 cron 作业也可以满足需要

我们来详细讨论这些组件。

自动的构建

CI 过程会经常集成软件，这需要通过构建来完成。在 Java 环境中，Ant 是常用的构建平台。可以使用 Ant 可靠地自动执行编译、测试等任务，甚至可以执行软件检查和部署。在掌握了 CI 的所有组件之后，您会发现构建策略是成功的 CI 过程最重要的方面。如果缺少适当的构建过程，CI 就难以发挥作用。

源代码管理

为了让 CI 正确地发挥作用，需要一个源代码管理（SCM）系统或存储库，比如 Subversion 或 CVS。CI 服务器向 SCM 存储库查询代码修改。在找到修改时，CI 服务器执行签出（即更新本地沙箱）并执行构建。除了执行得更频繁之外，构建过程与在本地环境中执行的构建相同。

CI 服务器

对于成功的 CI 过程，需要用一个自动的过程监视 SCM 存储库并在探测到修改时运行构建，这也非常重要。对于 Java 平台，有许多可用的 CI 服务器，包括开放源码软件和商业产品。它们的基本配置都很相似，适合监视特定的 SCM 并在探测到修改时运行构建。所有 CI 服务器都有自己的优缺点。Hudson 尤其让人感兴趣，因为它容易配置而且具有强大的插件，这些插件可以显示测试结果趋势等信息。

二.Hudson 简介

Hudson 是一种革命性的开放源码 CI 服务器，它从以前的 CI 服务器吸取了许多经验教训。Hudson 最吸引人的特性之一是它很容易配置：很难找到更容易设置的 CI 服务器，也很难找到开箱即用特性如此丰富的 CI 服务器。Hudson 容易使用的第二个原因是它具有强大的插件框架，所以很容易添加特性。例如，一个 Hudson 插件可以随时间的推移跟踪 FindBugs 和代码覆盖。它还可以报告测试结果的趋势（来自 JUnit 或 TestNG）以及构建结果和对应的执行时间。

Hudson 需要运行 Java 5。如果需要使用 Hudson 附带的嵌入式容器（Winstone）之外的其他容器，那么只需使用一种 Servlet 2.4 容器。对于大多数情况，Winstone 就足够了。

三.Hudson使用

CI 过程的最后一个方面是 CI 服务器本身。CI 服务器在整个开发过程中的主要作用是控制者：当服务器在代码存储库中探测到修改时，它将运行构建的任务委托给构建过程本身。如果构建失败了，那么 CI 服务器将通知相关方面，然后继续监视存储库。它的角色看起来是被动的；但是，它是快速反映问题的关键。

安装 Hudson

使用 Hudson 的主要好处之一是它的设置很简单。在最简单的情况下，Hudson 只需要两个步骤：

1. 下载最新的版本（它打包为一个 WAR 文件）。 hudson官方网址:https://hudson.dev.java.net/
2. 运行 java -jar hudson.war。

这样就可以了。因为下载的是一个 WAR 文件，所以如果愿意，可以将它部署在 Tomcat 或 JBoss 等容器中。这完全由您自己决定。当然，Hudson 假设在安装它的机器上运行着 Java 5，而且如果定义了 JAVA_HOME 环境变量，Hudson 就会使用它。（正如前面提到的，Hudson 需要 Java 5。）

在安装并运行 Hudson 之后（将 WAR 文件部署到 servlet 容器或从命令行执行 java -jar hudson.war），启动浏览器并访问默认安装位置。如果通过命令行运行 Hudson 而且您在本地机器上，那么可以访问 http://localhost:8080/。

配置 Hudson

如果访问 Hudson 主页的本地实例并单击左上角的 Manage Hudson 链接，应该会看到图 3 所示的可配置选项列表。

参数说明:
system.message 填写一些说明信息
Quiet period:hudson定时构建工程的时间(秒)
 Enable security:设置hudson登陆的规则(默认为匿名登陆)
TCP port for JNLP slave agents:不了解JNLP不敢胡写总之就是三种方式:固定(fixed) 随机(Radom) 不使用(disabled),使用固定时可以填入JNLP信息

还可以配置服务器的其他几个方面，比如向 Hudson 提供一个电子邮件服务器的位置，以便在构建失败时接收电子邮件。根据您的组织设置电子邮件的方式，可能需要让系统管理员帮助设置这个特性。设置电子邮件并不是必需的；Hudson 还支持以 RSS 作为通知机制，对于某些人来说，这种方式比电子邮件更好。究竟选择哪些通知机制完全取决于您。（注意，这里说的是 “哪些”，也就是说，可以同时使用多种通知机制！）

在 Hudson 中配置项目

既然 Hudson 已经能够与 SCM 存储库通信了，就该配置项目了。这个示例所用的项目称为 solar-ci。在 Hudson 主页上单击左上角的 New Job 链接。这时会看到图 5 所示的屏幕：

该页面可以使我们通过hudson来管理cvs里的一个对应的工程

Project name:工程名称

Description:描述信息

Discard build:如果选择此项可以设置build记录保存的天数,或者build记录保存的数理,或者只保存最新的build记录,一般不需填写

Advance project options:可以设置hudson定时检查cvs工程的时间间隔,还可以指定cvs工程check out到本地的工程路径,一般不需要填写

Source code management:我们选择cvs将出现以下参数:

Cvsroot:将写cvs登陆字符串,格式(:protocol:user:password@host:path),例如: :pserver:cvsadmin:1@127.0.0.1:2401:/CVSNT/Repository,使用cvs必填
 

Modules:填写cvs仓库下的具体工程名, 使用cvs必填

Branch:填写分支名称,也可以勾选this is a tag,no a branch指定标记名称
 

选择subversion可以进行相应的subversion设置

Build trigger可以设置hudson自动执行的一些动作,build after others projects are built指定hudson构建完成后需要继续构建的工程名

Build periodically 根据hudson定义的语法规则来设定自动构建工程的时间间隔

Post-build actions

设置一些构建完成后的动作,如放邮件,打包,产生测试报告,产生java doc 等.

点击ok保存设置

使用hudson
进入刚配置的项目,可以在左侧build history看到历史的build记录,点击build now 可以手动执行构建动作,完成后可以通过记录标记的颜色来看是否出错,红色有错,蓝色成功.点击记录查看详细信息,如果有变化hudson将列出类信息

成功的大型企业需要其 IT 部门通过跟上技术发展来保持高水准的竞争力。这通常需要代价很高的经常性投资以维护当前的 IT 投资和增添新的投资。然而，中小型企业通常只有有限的预算来设法现代化其 IT 基础设施和资产。通常可以注意到，中小型企业只有在充分利用当前 IT 投资以后才会考虑重大的升级。他们每隔几年进行一次较大规模的现代化投资，而不是连续地进行投资。

“中小型企业”（small and medium business，SMB）这个术语非常主观并取决于若干因素，例如年度营业额、员工数量、业务的地理分布等等。就本文而言，我们的虚构公司 Mod Communications , Inc.（以下也称为“该公司”）是一家为中西部若干个城区的家庭客户和当地企业提供高速 Internet 接入、有线电视、本地和长途电话以及无线通信服务的电信服务提供商。该公司是需要现代化其 IT 系统的中小型企业的代表。该公司拥有 200 名员工，已有 20 年的经营历史，分支机构不超过 10 个，并拥有大约 75 名 IT 人员维护其当前的 IT 解决方案。

面对新的竞争，他们感觉到了为当前客户维持较高服务级别的压力。该公司希望着手进行遗留系统转换活动。该公司准备为转换活动做出重大投资，并正在寻求现代化路线图规划方面的帮助。本文是为 IT 顾问、架构师和解决方案开发人员准备的，并解释了如何分析该公司的当前现状、组织动力和挑战，并提供了一组 IT 转换活动建议。本文还演示了一些可在该解决方案开发过程中提供帮助的 IBM 产品和服务。

Mod Communications Inc. 的大多数应用程序都是客户信息控制系统（Customer Information Control System，CICS®）应用程序，这些应用程序使用 COBOL 编写并运行在 IBM System z™ 系列中的 IBM 中端大型机系统上。虽然这些应用程序继续尽最大可能地提供核心业务服务，但是它们非常庞大、独立并且难于修改。替换或从头重新构建这些应用程序会对当前业务流程产生破坏性的影响，并需要收集在过去 15 年里加入到系统中的业务智能和规则。采用某个基于面向服务的体系结构原则的渐进式遗留系统转换过程，是有选择地替换该公司的应用程序组合的更加经济合算和风险更低的方法。此方法的一个示例是使用 Java EE (Java™ Enterprise Edition) 来开发将在诸如 IBM 推出的 Websphere® Application Server 等应用程序服务器上运行的应用程序。新的应用程序将在可能和适当的任何场合重用现有的功能。在构建和部署新组件时，其使用范围超出目前应用程序的部分组件将公开为服务，以便在以后的开发工作中重用。

下面几个部分将解释 IT 架构师或顾问如何执行数据收集、分析和建议活动，并将遗留系统转换过程告知公司的重要高层管理人员。下面将从数据收集期间的各个步骤、分析阶段得出的各种输出、所确定的建议备选解决方案和针对转换规划的指示等方面对相关活动进行描述。

数据收集

数据收集的重点在于获得关于业务活动、所使用的 IT 技术和 IT 投资等事项的当前状态的信息。然后可以分析该数据以确定转换机会。以下步骤将准备并执行有效的数据收集工作：

步骤 A. 获得或准备公司的组织结构图

务必要了解公司的组织结构图，以便确定重要的团队成员和权力人物。Mod Communications, Inc. 的组织结构图表明，总裁和首席运营官（Chief Operating Officer，COO）以及执行副总裁（Executive Vice President ）将负责监督重要的业务和技术活动以及投资。对于日常职能和活动，该组织拥有诸如“操作组”、“业务服务组”、“财务服务组”和“通用开发组”等小组。其中每个小组都具有业务和技术人员。这些小组的负责人将向执行副总裁报告，并且是主要的业务和技术相关决策的权力人物。

步骤 B. 获得有关公司经营的初步信息

此步骤将为准备用于数据收集的详细问题集奠定基础。起初，可以从与高级人员进行的讨论中获得有关公司经营的粗略概况。在非正式的气氛中提出有关公司背景、公司发展、公司所属行业、优势、弱点、新机会、察觉到的竞争威胁、所获奖项以及类似主题的诱导性问题。

在 Mod Communications, Inc. 进行的有关转换活动的总体目标的讨论过程中，一名高级员工提到该公司作为中小型企业区段中的最佳员工工作场所之一而感到自豪。大多数员工都已经为该公司工作了 15 年以上。另一位高层管理人员提到实现面向服务的体系结构在公司日程上处于优先位置。该信息可以在分析阶段中提供重要的输入，以评估关于组织更改和准备情况的可能建议所具有的影响。

步骤 C. 准备用于详细信息收集的问卷调查

此类问卷上的问题应该跨越广泛的主题，例如业务目标、当前流程评估、应用程序组合评估、企业数据体系结构、基础设施和操作体系结构、面向服务的体系结构，以及治理。以下问题类似于一个样本集。

• Mod Communications, Inc. 在未来三至五年的业务目标是什么？
• 当前用于为各方（例如客户、供应商等等）提供价值的业务流程（由人员和/或系统执行的活动集）是什么？请列出并提供简要的叙述。
• 业务流程是否具有文档记录？其中每个业务流程是否存在端到端的业务流程视图？
• 为未来三至五年计划的主要业务目标和远景是什么？其中一些示例包括改进服务请求周转时间、收入增加 x 倍、操作成本降低 y 倍、改进客户满意度指标等等。
• 所确定和分析的业务流程是否与业务目标和远景持续一致？当前，哪些业务流程可以认为是与业务目标和远景保持一致的，哪些是不一致的？
• 当前的应用程序是什么，它们支持哪些业务流程？
• 是否计划在即将到来的一年里设计、开发或实现任何新应用程序？请根据情况提供详细信息。
• 在当前应用程序中，业务逻辑关注事项是否与操作关注事项分离，从而支持操作上的松散耦合并促进软件和信息资产的重用？
• 是否存在针对遗留应用程序或功能子集的既定策略？遗留代码中是否存在将导致难于随时间推移而停用遗留系统的代码依赖性？
• 请提供有关当前企业数据体系结构、数据模型、维护以及增强方法、数据管理方面、数据仓库等的详细信息。
• 对于您的操作的某些方面，您是否必须依赖批处理数据传输？如果是，请详述。
• 请提供有关当前存在的硬件和软件基础设施的详细信息。
• 提供当前网络界面方法的详细信息。什么功能通过网络提供，以及在使用什么体系结构和产品？为将来的网络界面计划了什么附加功能？
• 请提供当前的设计、开发、测试和生产应用环境的详细信息。
• 是否准备了足够和有效的流程来处理以下有关当前操作环境的事项？这将包括用于变更管理、引入新技术和服务管理（如果适用的话）的流程。
• 您是否与第三方服务提供商或代理建立连接？如果是，该连接的性质是什么（例如，同步、异步、单向、双向）？
• 是否存在促进基于服务的体系结构的基础设施（例如，帮助实现应用程序之间的消息交换、消息转换、独立服务查找等技术）？如果是，请详述。
• 是否有团体在考虑跨功能应用程序的可重用性？
• 您关注 SOA 采用的动机是什么？是定位于实现附加的收入产生渠道（例如实现更快的新产品上市或获取新客户），还是通过促进当前应用程序及系统的更好可重用性和维护来降低成本？
• 您当前的 SOA 方向是什么？您计划将要使用的技术是什么？是否存在任何用于目标 SOA 体系结构的现有高级设计？
• 您是否有任何现有的 Web 服务实现？如果是，请提供详细信息。

来自 Mod Communications, Inc. 的高级人员群策群力，一起合作回答上述问题。

步骤 D. 计划安排与重要客户端团队成员的后续访谈

从问卷答案中，确定进一步的信息需求领域，并计划安排与重要人员的后续访谈。使用组织结构图来确定要访谈的其他人员。完成后续访谈时，数据收集阶段差不多就完成了。随后的解释说明可以通过电子邮件或电话来获得。

对于 Mod Communications, Inc.，将准备一个关于访谈成果的报告。该报告提供了公司 IT 环境和基础设施、IT 组织、主要角色和职责的当前状态摘要、应用程序组合概述、系统和功能摘要，以及当前治理、未来三至五年的业务远景和目标的简要概述。这可用作将来的所有工作的参考。

数据分析

在数据分析过程中，研究收集到的相关资料和文档信息，以分析各种备选解决方案，从而提供建议。按以下几个方面对信息进行组织：

• 对 IT 转换的成功最重要和最关键的业务远景和目标，以及指标。
• 难点。这些是公司正在尝试解决的关键业务和技术问题。
• 解决方案建议所要考虑的约束。
• 应用程序组合分析的发现结果。

对于 Mod Communications, Inc.，以下是重要的业务远景和目标：

• 实现业务各方之间改进的信息流，包括客户、客户服务代表、技术人员以及销售和市场代表。计划通过此目标削减 7 - 10% 的业务开支。
• 通过现代化活动和新技术采用来处理公司的客户保留问题。创建现代化路线图。向重要客户和员工传达该路线图。
• 提高软件和应用程序开发这个重要流程的效率。公司需要简化活动和任务，以推动更高的团队成员效益和工作效率。目前，预计要发布的实际软件或应用程序要在发布日期之前一个星期才能准备就绪。通过提高流程效率将此时间提前为两个星期。满足此目标可以降低压力级别，同时还可以提供更多的时间进行有关该发布的附加测试、交流和其他活动。
• 通过新技术和更好的直观用户界面降低培训和支持成本。预计通过此目标将培训成本削减 15%。
• 最近的一项调查表明，该公司的内部应用程序供应感觉非常缓慢，尽管该解决方案所提供的全面功能获得了好评。开发团队需要使用最新技术使业务解决方案对用户更有吸引力。公司应该通过更好的用户界面设计来促进易用性和工作职能效率改进。
• 提高市场竞争地位，同时吸引更多销售潜力。通过遗留资产的现代化，使销售主管能够吸引更多销售潜力并赢得更多业务。

基于与团队成员进行的有关该公司使用的当前流程和实践的详细讨论，以下是重要的难点和问题场景：

• 随着时间推移，代码变得日益难于维护。因此，引入更改将要花更多的时间。这导致维护成本增加，给定版本所接受的增强功能请求数量减少。开发人员的工作效率有待提高。
• 公司不能容易地招募新的开发人员来从事 COBOL 方面的工作，COBOL 是目前使用的主要编程语言。此外，要让新的开发人员在短期内高效地工作也非常困难。
• 技术文档和信息非常有限，并且构建和发布过程很不可靠。
• 需求、设计以及代码和测试需求之间的可跟踪性非常有限。这导致维护和代码修改工作非常耗时，并且无法准确预测时间和成本。
• 公司拥有几名对公司的业务、遗留系统和数据库非常了解的过程开发人员，但他们不具备使用现代编程语言所必需的面向对象技能。
• 公司缺乏用于测试发布准备情况的测试用例主集，并且缺陷跟踪也不够全面。缺陷的根源分析跟踪非常随意，没有进行广泛的文档记录。

对于 Mod Communications, Inc.，解决方案建议需要考虑的各种约束如下：

• 公司在技术方面拥有几名非常了解业务方面、代码结构和数据库的团队成员。然而，由于目前的应用程序维护和对增强功能的承诺，不能期待这些资源在转换工作期间的大规模可用性和参与。
• 该公司的几乎所有技术团队成员在 COBOL 编程方面都非常优秀。然而，他们缺乏有关面向对象的方法和最新技术的知识。该公司希望保留大多数技术人员，因为他们非常了解该业务解决方案。该公司还因为善待员工而获奖，据行业调查表明这是个工作的好地方。
• 该公司的代码文档非常有限。

该公司的应用程序组合分析提供了以下信息：

• 应用程序主要基于大型机。
• 20 个主要应用程序。
• 15 个应用程序有 7 年以上的历史。
• 所有应用程序都随着时间推移而进行了大量的自定义。

该公司一直使用 IBM Host Access Transformation Services (HATS) 来将某些应用程序从已有基于字符的屏幕界面转换为 Web 用户界面。这使该公司可以快速将现有的基于字符的屏幕界面转换为网页和表单，从而将 Web 通道用于其遗留应用程序。该公司应该通过创建基于最终用户输入、易用性、导航和上下文内容呈现的新用户界面来对此进行改进。

解决方案建议

下一步是为客户交付一组解决方案建议。

基于对信息的分析，为重要的 Mod Communications, Inc. 高层管理人员准备一个解决方案建议，以从资金和项目决策方面说明后续步骤。

核心建议是让公司在保留其当前遗留应用程序组合的价值的同时，逐渐地迁移到可促进松散耦合的体系结构的新技术。一个建议是采用 Java Enterprise Edition (Java EE) 作为进行遗留系统转换的合适应用程序技术。Java EE 方法使公司可以开发能够提供出色的图形和多通道用户界面的应用程序，同时还为面向服务的体系结构做好定位。这导致对各种方法进行分析以实现 Java EE 环境。这些方法如下：

a) 替换：将诸如服务订单管理、问题报告和管理及计费系统等当前核心应用程序替换为商业化现成（commercial off-the-shelf，COTS）应用程序。然后自定义和配置该应用程序和界面。这是实现转换的快速方法，但它在客户接受、对现有业务流程和功能的影响、组织变更和培训需求方面引入了风险。

b) 重新编写：使用 Java EE 方法重新编写应用程序。优先重新编写将经历转换的应用程序。对这些应用程序执行基于方法的完整软件生命周期开发，包括需求分析、设计以及开发和测试。已知当前应用程序的数据库层结构非常良好和高效。在可能的情况下，新组件可以重用数据库层的功能。

c) 大规模转换然后客户化定制：这是选项 b) 的一种变化形式。在此情况下，将使用自动化的工具执行所有应用程序到 Java EE 组件的大规模转换。然后修改所得到的组件以适合需求。

d) 渐进地转换到目标平台组件：使用基于 Java EE 的体系结构来构建过渡环境。从当前遗留系统中公开的“幕后”模块将提供实现。渐进地在目标平台上编写代码以取代对遗留模块的依赖。

e) 使用第 4 代语言（4th Generation Language，4GL）方法渐进地转换：在此情况下，将使用某种 4GL 语言来定义应用程序。使用工具将 4GL 结构自动转换为 Jave EE 组件，然后将后者部署在目标平台上。例如，此方法可以使用 IBM 企业生成语言（Enterprise Generation Language，EGL）来实现，并且很适合于非常精通诸如 COBOL 等程序语言的程序员，他们将不必学习诸如 Java 等面向对象的语言。

从诸如成本、工作量、时间和复杂性等方面分析上述建议，然后按照下面图 1 所示的方式对这些建议进行归类：每个参数都具有一个优先级名称——“高 (H)”、“中 (M)”或“低 (L)”。

下面是一些补充建议：

1. 采用模型-视图-控制器（Model-View-Controller，MVC）体系结构模式以确保体系结构的灵活性。使用此方法，数据（模型）和用户界面（视图）将彼此分离，以便对一个方面的更改不会影响另一个方面。控制器处理并响应用户操作。
2. 优先考虑要转换的应用程序，以便在对业务具有最少中断的情况下获得递增的业务好处。优先考虑影响客户感受的应用程序，例如服务订单管理、故障单管理和新服务的供应。这样可以将重点充分集中在从客户和业务用户角度看来最重要的应用程序上。这样可以帮助获得客户信任、采用、保留和改进的满意度。
3. 建立 IT 治理管理委员会，确保 IT 投资处于正轨，以在可接受的风险预测内产生预期的投资回报。该委员会应该监督技术活动、重要参与者之间的交流、标准化活动和体系结构审核。
4. 采用方法驱动的步骤进行软件开发。这会提供更好地规划和管理各种转换项目的任务、日程安排、预算的能力。这还有助于更好地管理风险，例如成本超支、时间和功能覆盖率风险。IBM GS-Method 和 Rational® Unified Process (RUP) 就是此类方法的示例。
5. 对于从需求到设计以至开发和测试的每个开发生命周期阶段采用最新的工具。这可以实现更好的文档、可跟踪性和控制，并具体化方法驱动的步骤。IBM Rational 产品和工具组合具有满足软件开发生命周期和治理需求的丰富工具集。请参见参考资料部分以获得指向更多信息的链接。
6. 构建和主动管理服务模型：各种应用程序组件将是在其他应用程序中重用的直接候选组件。通过主动辨别跨部门边界所需的服务，将来的开发和维护工作将会得益不少。这还可以推动功能的重用。
7. 执行遗留资产的审核：这可以帮助从当前系统中获得重要信息，例如业务规则。它还有助于了解业务功能和模块化工作。一些现有的遗留代码可以组件化，并公开为服务以供新系统使用，直到将遗留代码替换为新组件。
8. 对于中长期而言，应评估可在应用程序之间的消息交换、消息变换和转换以及独立服务查找方面，进一步促进整个组织中的面向服务的基础设施软件的采用。在这方面，IBM WebSphere 组合提供了若干个产品。请参见参考资料部分以获得指向有关这些产品的网页的链接。
9. 评估规则引擎技术的采用，以在捕获和使用业务规则方面引入效率。目前，该公司的代码资产非常脆弱，因为在这些年来，代码中已引入了各种对业务规则的更改。目前，业务规则与主代码紧密耦合，使得在做出更改时必须小心谨慎，同时还增加了测试需求。
10. 在初始项目中利用外部专家或顾问：这允许更好地集中于现代化工作，并为现有人员提供更多时间来跟上新技术的发展步伐。在现代化工作期间，完全使用现有人员也许无法应付过去，因为团队成员将会忙于满足当前承诺。此建议可以通过与服务提供商的一个或多个服务约定来实现。例如，IBM Global Services 就拥有这方面的各种解决方案。

提供一组在现代化期间优化内部操作的建议，以便为当前人员提供更多参与机会。这些建议包括：

1. 减少软件发布周期数量，同时将重点更改为仅集中于最关键的增强功能领域：这允许将资源集中于对客户满意度、保留和获取非常关键的领域。
2. 根据逻辑相关的领域对维护项目进行分组：这有助于提高开发人员的工作效率。
3. 创建并使用一套全面的测试用例：在开发和维护周期中，会发生以下一种或多种情况：1) 更改现有的功能/数据结构，2) 引入新的功能/数据结构，3) 在完成项目 1 和/或 2 的同时确定并修复错误。由于应用程序具有如此多相互关联的部分，必须以有组织的方式执行测试以实现全面的覆盖率。在这方面，全面的测试套件可以提供好处。
4. 评估所要采用的帮助台工具：以便提高快速查找、分析和解决问题的能力。此类工具还可以通过分析问题趋势，从而帮助确定问题正在增多的应用程序领域。用于处理问题的知识库的更好文档记录和创建也是非常有益的成果。

请注意，这些建议会因情况而异，并且应该基于与某个情形有关的相关信息。上述案例研究只是一个用作指导原则的示例。

转换规划

基于所选的建议，为执行团队草拟出详细的转换计划。这包括短期（一至两年）、中期（两至三年）和长期（五年）的项目计划。创建活动（项目）、活动的业务价值、持续时间、大致成本和资源需求的摘要。这有助于推动资金分配决策和成果。

转换规划期间的重要考虑事项之一涉及到硬件或遗留平台的现代化。在这一点上，评估重用可能性也是最有利的。例如，客户拥有一个 System z 系列中的 IBM 中端大型机系统。该系统的功能之一是能够在运行 AIX® 和 WebSphere Application Server 的单独分区上运行 Java 工作负载。该系统的此功能可用于实现重用，并且是确定投资需求时的一个重要考虑事项。请参见参考资料部分以获得指向更多信息的链接。

结束语

本文提供了深入的见解，说明了如何为中小型企业的主要高层管理人员提供遗留系统转换和现代化活动的建议和指导。本文介绍了如何通过执行数据收集、分析和建议步骤，并提供转换规划信息以支持资金分配决策，从而有条不紊地完成该任务。

经常会听到这样的抱怨，我做出的架构设计，下面的人能力不够，无法实现。这个架构是XX推荐的，为啥做下来问题会这么多？ 我们的架构师只会说，其实水平不行，做出来的东西很难用等等。

其实认同我说的1的人应该已经明白，架构既然是渐进验证的，那么架构的可行性就是一个必须考虑的问题。架构师需要熟悉自己的团队成员的构成和技术特点，在此基础上对设计做权衡，再好再优秀的架构也要取决于团队成员的理解能力和执行能力，这点对很多人来说居然完全不理解。

和现在的各路有志青年一样，我也曾经努力奋斗要做一个架构师，我在01年参加了sun的架构师认证考试。那时候的SCEA考试并没有什么参考资料和贩卖答案。各路精英只能在一个国外论坛上泡着交流经验，经常看到某某高分过了的消息，又看到某某平常表现不错，又差了多少分没过云云。

我看了很多书，也颇有些项目经验，通过成绩却一般，80分左右，所以很想知道别人的设计是如何做的，什么样的设计可以得到更高的分。 经过协商，我和一个挪威人，一个德国人（有20年的开发经验）交换了通过考试的作业。让我震惊的是德国人设计的粒度，他的架构设计几乎想日本人做的详细设计一样，只要简单的翻译工作就已经可以run，即便是对德国人的严谨细致早有所闻，我还是难以想象这是一个小项目的架构设计。 和德国人做了交流，他说他必须做得这么细，否则他的团队成员理解会产生偏差， face to face的交流也不能弥补这个问题，因为他的小伙子不是都足够聪明。
 
这让我第一次意识到，架构师的工作的一个中心，并不是直接面对客户，面对老板而是面对技术团队成员。其后的工作中我又多次碰到类似的问题， 同样的需求，一个架构师面对不同的团队成员的时候，很可能作出截然相反的设计。架构师必须针对团队成员的特点，认真考虑团队成员的技术能力和学习能力，有针对性的选择和平衡，甚至是牺牲，才能保证架构的可行性。

在一个理想的技术团队，架构师固然可以只关心技术，但是这样的团队现实中存在的概率有多少？ 就如death to march 2nd中所说，现实的软件开发团队，大部分都要面对一个资源短缺问题，

不能说服老板给你足够的资源，那么只能选择充分使用现有的资源，菜刀也是刀，对不对。

我不知道有多少项目架构师脱离开发团队能获得真正的成功，一般来说，强调架构设计的项目都是中等以上规模的项目，人数一般都会超过10个以上，对项目管理，对技术人员有着更高的要求。不少公司都乐意高薪聘请外援进行架构设计来解决问题，但是结果都不理想，原因即如此。

我非正式的咨询过2个项目，架构设计都由大堆钱的工程师完成，pm哭丧着脸跟我抱怨，我们的架构没问题，都是大堆钱做的, 国外啥啥都这么用，但是我们的程序员不行，无法很好的将架构实现。

姑且不谈大堆钱为了推销自己的产品加塞的东西，单就这种丝毫不考虑团队成员构成，千人一面的拷贝设计，都已经注定成功只能是偶然了。这样的架构，又如何说没问题？一个架构师最低限度的责任，既是将这种大众face裁剪调整到适合自己团队的面孔，交钥匙的做法是没戏的。我只能很无奈的告诉他们，这样复杂的过度设计，如果不做裁剪，即便我给你找到合适的程序员，你也无法承担时间上的成本，何况性能始终都会是个大问题。

不少中小公司的同胞们敬仰着大堆钱公司，指望他们能解决根本的问题，殊不知，某种意义上，架构设计的工作，是没法外包的，你可以咨询，可以顾问，但是干活是另外一回事。这点和互联网应用什么的，还是挺大差别的。

某方面讲这是对的，但又不全对，因为技术工作只是架构师工作做的一个核心关注点而已。一个ｎｂ程序员可能在技术方面是ｎｂ的，但是在很多方面确实欠缺的，并不适合做架构师。

做企业应用的，牵涉的面太广，加上行业生存环境又不是很好，企业管理普遍也不规范，所以很难象某些领域，架构师就是一个纯粹的技术工作。

首先，如何获取项目经理和管理层对你的信任和支持， 是你开始工作的起点， 这一块和技术并没有直接的关系，取决于你的表达能力和主动性，你如何展现你的实力，你做事是否足够主动，是否有意识和能力去推动项目。不能让老板感觉你就是一个greek，这一条是很多不错的技术人员难以做到的。而实际工作中，你也绝不能把所有时间都花在技术上，你至少要拿出4分之一的时间去和pm，和老板沟通，协商问题， 才能得到你的生存空间。

其次，如何获得团队成员对你的信任和支持，是你展开工作的基础，如果你不够传奇，就需要你做一个牧师或者善于聆听的人， 通过熟悉自己的团队成员的构成和技术特点，才能充分发挥他们的所长，赢得他们的信任和支持，看起来这好像是pm的工作，但是不尽然，如1所诉，架构设计并非是一个个体脱离团队的行为。和团队成员打交道，多半又要花掉你4分之一以上的时间。

好吧，你还要明白，为啥要叫架构师而不是高级工程师（这个已经out了）， 是因为你还需要承担售前售后任务， 如何简单清晰的向不懂技术或者半懂技术的客户讲清楚技术问题，这是个学问，要做到这点，按我以前的老板说法，你必须有常识， 常识要多道可以用一些简单的故事例子把东西讲出来，所以有空要多看看电视，多和销售学学，顺便还得学点基本礼仪，上次我差点把某公司来给我们推销产品的工程师给踢出去了，在我提了意见以后，丫居然坚持跟我说他们东西是最好用的，你敬业没错，但是好歹我才是用户吧。

如果你的公司是做项目为主的，恭喜你，你还要学会如何和客户周旋，如何回避到客户内部以及客户和其他供应商之间的矛盾里去。因为某方面，作为架构师，你就代表了技术上的权威，你要明白一点，管理上出了问题，从来都是往技术上推是最简单的。项目之外的话，说起来一定要谨慎，再谨慎。比如如果有客户不愿意购买设备和软件实现负载均衡，找你咨询，你随口一说，啥啥免费软件可以做，好吧，你完蛋了，你要么就是得罪了某供应商（搞不好还就是你们公司卖的），要么，就是等着将来客户给你套口子吧。

而且，作为一个企业应用的架构师，你不可避免的要和各类厂商打交道，这里面也是大堆的学问，虚虚实实的东西大把，偶尔你甚至会受到美色或者银弹的攻击（记住，只是偶尔，人家一般不乐意在你这个级别上下血本）你要一不小心分不出真假，很可能就做了大堆钱公司的小白鼠，搞的在客户和公司间里外不是人。

还有，架构设计往往还需要考虑到技术的生命周期问题， 那么你对客户公司，对开发公司的状况的了解，对整个行业的发展趋势的了解，也会影响到你设计的决策，这种东西往往跟市场有关，并不取决于技术，这考核的就是你的视野和对问题的敏感程度。 打个比方，你开发了一个很好的系统，但是到了你离职的时候，客户却发现你选择的这种技术已经淘汰了，现在很难再找到合适的人员进行维护了，这样的架构师，算合格么？

说完了外面的东西，再说里面的。

一个成熟的企业应用的架构师，除了对行业技术应用有准确的把握和经验积累之外至少还需要有丰富的业务知识。

一般来说，架构设计由几个面构成，其中一个面是技术架构，还有一个面是业务架构， 技术架构必须通过后者的验证。积累一个行业的业务知识，少则一年半载，多则3年5年，这都不是单纯看书阅读资料可以获得的。客户可不会只因为你的技术如何先进，nb 就验收项目的。

再有， 再好的架构，也需要向程序员沟通和推广， 那么你至少也要是个合格的技术讲师吧？ 兄弟们管你叫那个师，你总还得有能力教人家一点东西吧？

某些项目，技术甚至可能根本就不是关注点，我曾经参与的一个项目，在我加人的时候架构设计和开发工作都已经完成，而且是基本构建在相对错误的道路上，基于项目进度的压力，我已经没有可能重新推到再来，所以我把工作的重心转移到如何培养提高团队成员的技术能力，降低不成熟架构对他们工作的干扰，换句话说，我干的工作就是打补丁。这些看实不够nb的工作大部分都和技术无关，和流程图，模式无关，但是有效的弥补了架构的缺陷，保证了项目的顺利进行。

既然不能选择离开，那么菜刀也是刀，对吧。

最最后，你还要有点人脉，有在天涯海角到处混的兄弟，这样你搞不定问题的时候，卡住的时候，或者他们一个小小的提示就可以救你于水火之中。不会不是你的错， 解决不了问题才是你的错。

在我看来架构师的工作，是一个混合了各种知识和经验的工作，架构师更象酒店里的行政大厨，只会炒菜那是绝对不行的，很难单纯的定义为技术工作。当然，动不动就把架构师抬举为艺术家，开口闭口XX的艺术，哪还是过了，你以为画画的都是艺术家么？ 我家狗仔还能用嘘嘘画地图来着。

指望多读书，多写代码，一个人对着电脑就能迅速成长为架构师，嗯， 我觉得可能性不是很大。

前几天看到一篇架构师已死的文章，颇为有趣，仔细想想，架构师之所以兴盛和之所以必死，多半是因为太多的人对软件架构师的工作存在诸多误解的缘故。而诸多媒体和原厂商出于自身利益在国内行业进行的过度吹捧，给予了架构和软件架构师太多的光芒，程序员们自然而让的就把个人的职业规划扔到了聚焦点上。

写一些自己对架构设计和架构师的一些不是很成熟的看法，写到哪算那，全当口水了。

架构的概念非常广泛，解决的问题域空间也各有差距， 不能从一而论， 此处单指企业应用的范围而已，和互联网应用等其他范畴有较大差距。

1. 架构是设计出来。

这是很多人对软件架构的一个最大误解。

传统的瀑布模型里，人为的划分设计和编码实现过程，也划出了设计和验证过程的鸿沟，整体设计（概要设计）的可验证性，要在项目的中后期才能得到体现，这时候为时已晚。而为了保证设计的质量，回避中后期风险，又往往会强调加强设计粒度和评审粒度，这样一来，无形中又继续加大了设计和验证的鸿沟，拖长了问题反馈周期，规模越大的项目，问题越为突出。

据我的印象，业界中最早的最有影响的关于架构和架构师的界定其实来源于RUP.有别于传统的瀑布模型的中的概要设计，软件架构很难再说是按流水线方式设计出来。架构设计和概要设计的最大差别在于架构设计更看重反馈和验证过程，更看重架构师在整个软件开发过程中的由始而终的参与。在rup中，项目早期的关键迭代都和架构设计有直接关系。

架构设计应该强调通过更好的反馈-沟通-验证机制， 能在项目的较早期就得到技术和业务上的验证，为整个项目打下稳定的基础。 在某些敏捷开发过程中，架构设计并不会作为一个显著的KPI提出，更多是作为一种隐喻。通过使用迭代和其他更好的反馈交流机制，让项目的架构设计在在项目的前期以验证和演进的方式完成。可以说一个真正的架构设计，必须是可以有效验证的。

而现在很多公司和组织流行的先让大拿组织做设计，设计做完再评审，然后丢给小兵去干活的架构设计流程，实际是对瀑布模型的继续，我个人认为是完全背道而驰的。我多次参加过这样的架构设计评审，基本上可以说没有什么有真正营养的东西，只是一些流行概念的堆砌，昨天EJB,今天SSH，明天又是OSGI，这样的架构设计作出来也有可能会大幅度修改，或者坚决不修改让下面的人痛苦不堪，所谓的评审和存档过程只是自欺欺人而已。再考虑现在各大公司流行的CMM/CMMI，过程改进管理，这些paper的工作还可能会因为引入复杂的审批修改流程把人拖入泥潭。

这种做法，在java圈子里面，因为早期sun和一些大公司对架构和模式概念的极力鼓吹，大为盛行。某些人甚至只是看完了blueprint，做了几个tutorial，就摇身一变架构师，开始了架构设计生涯。

这样的架构师也往往很少编写代码（我们可以理解，一个人写完300页的设计文档以后，还有多少意愿再去写实现代码？），很少参与项目的开发工作，只满足做一些试验性质的代码工作（对呀，现在开源东西这么多，流行的东西组装一下架构设计就算over了么，还实现什么设计）和指导工作，甚至有些paper的架构师，完全就是靠粗读各种pattern和x宝典来做设计，设计的可行性和高风险性，可想而知，早期大量EJB的滥用导致的项目失败，其实根本原因在于甚少有架构师以验证演进的手段来决定是否应该使用EJB，怎样合理的使用EJB，将架构设计草率的外包给各大原厂商鼓吹的概念或者各种blueprint。而小兵们在面对架构+模式两顶大帽的时候也只会怯懦的怀疑自己的个人能力，然后坚持不懈的向架构师这一伟大位置继续奋斗。

而另一方面项目管理者也往往会误以为有了正规的架构设计就可以更好的保证软件项目质量，可以将项目的重心放置在需求和非技术工作之外，可以不用再考虑一般程序员的技术能力问题， 可以大幅度的xxx，xxx， 最后一堆苦水，然后再把责任归咎于架构师不成熟。

我早年经历过的几个项目就有此方面沉痛的教训，事后我个人复审设计，发现基本上整个方向都是错误的，个别项目设计者甚至连EJB的一些基本概念都没有了解，自己重头实现了一遍。过长的验证周期导致后期已经无法再做任何修改，只能咬牙吞下。

真正实用的架构是以逐步严谨的方式验证出来的，即便是自称中国java NO.1的袁红岗告诉你EJB非常好，没有EJB的架构就不是真正的J2EE架构，你也要验证以后再说，在此顺便bs一下csdn。

在那篇架构师之死的小品里，boss问小兵，你如何说服大家要使用hibernate？ 其实答案很简单，架构又不是设计出来的， 为什么要说服？

A：
软件工程里面有个著名的brook定理，大意就是向一个进度落后的项目加人，只会让这个项目更加落后，引申开来就是应该避免在项目的中后期大幅度加人。 这里面的主要的原因有几点。

1. 新人加入团队以后需要获取团队成员的信任和尊重，这需要比较多的沟通和交流成本，软件开发说到底是一种群体活动。
2. 新人要理解，认同团队的文化，也需要很大的成本
3. 新人需要对项目进行学习和了解，过程会拖累其他开发人员
4. 新人太多，有可能会彻底摧毁原来团队已经建立的平衡结构，比如团队文化， 团队间的角色定位。
5. 管理者会因此大幅度的增加管理成本，另外，管理者很可能并未做好管理这样团队的准备，有可能会因为不合适的行为和决定导致团队崩溃
6. 人员增加以后，彼此之间的交流沟通成本会大幅度增加，超出一般人的想象。

因此一般正确的做法是避免在项目中后期加人，虽然这么显然简单的道理大部分老板都不相信。

所以表面上看，逐步圈地的做法是违反brook定理的。但实际情况，恰恰因为结对工作在很大程度上克服了上述的问题，所以你要是理解了结对的收益，就可以明白为什么结对可以保证“队伍具有非常一致的目标和想法，保证团结”


1. 结对可以让新人之间加快了解过程，尽快的融入团队， 不使用结对的方式，一个新人可能需要1，2周才能和团队相处融洽， 使用结对的方式以后，1，2天就可以很熟悉。

2.结对降低了新人的学习成本，在结对过程中，原团队的成员采取人盯人的方式尽快的将技能和团队文化传递给新人，而新人一开始就可以上手工作（即便是菜鸟，在结对过程中也可以通过质疑和提问对老人提供帮助和监督，而出于维护个人的自尊，团队成员一般都会急于向新人推销，证明自己），更有成就感和归宿感。对团队也就更容易认同。

3. 结对是分而治之的，有助于避免新人因为陌生环境产生分离感，建立自己的帮派。 有助于强制性的向新人灌输团队的目标，保证团队的团结。习惯了结对的工作模式以后，程序员之间必须强制性的进行沟通和交流，也可以避免产生帮派和内耗。

4.作为boss更关心的一点就是，通过结对这种方式，可以获得足够的backup，可以避免因为人员流动给项目带来毁灭性的风险。因此可以大幅度的降低管理成本。我们项目中期流失了近三分之一的人，进度没有受到任何影响，所以前期boss极力反对做pp，后期大力支持。我们自己有过一个大致统计，正常情况下离职一个人，要损失至少半年的人工。

通过结对这种方式，互相之间建立了沟通和信任机制，再划分如果有目的的小团队，就比较自然，另外在不同的小团队之间交换结对伙伴也可以做激励和监督作用。而一次性投入的建设新团队，碰到的问题会更多。

这个项目其实失败的一个地方就是中期迫于人员流动而放弃了结对，最后导致帮派和内耗，纠正过来化了血本，否则还能做的更好。人员流失有一部分是因为个人当时管理经验不足，对问题的解决欠妥，还有一个原因是原材料不合适，老板在团队组建之初盲目的招来了一些并不适合的人（后来碰到一个老板，居然跟我提招10留1的理论，Orz），也为后来的内耗埋下了隐患。这也算是一个经验，团队成员的选择leader一定要过问，对于那些性格比较偏激，难以控制的人应该尽量回避，绝不可以因为资源紧迫就充数。

按：pp的工作方式，对团队成员性格有一定要求。
Q：
任何团队的组织划分，一定不是用技术最好的人来做leader。对技术好的人要进行压制。不管有多出色，都要尽力扶持听话的人。
找技术好的人是对的，但是他技术好，你技术不好，就面临挑战了。何况技术好，不听话的，到哪里都是干活的命，没有人会重视他们的。

A：
你老外说话也不真见外，按你这样管， 几天大家就造反了。

软件团队和一般的团队区别非常大， 对软件团队来说，最好的管理模式就是不管理， 让大家自己发挥，做好足够的引导工作就好。小团队leader身先士卒起个带头示范左右，大团队， leader要躲在后面做好后援当保姆。 技术好的人的做leader是非常自然的，不懂技术的人做负责人倒是比较容易引起问题，技术人员都比较骄傲，除非是个美女mm带头，那还可以忍忍。 不是说不懂技术的人做不好pm，但是没有技术背景的人天然就和技术人员有鸿沟，技术人员背后搞的小九九，花样那个多，所以没有技术背景，管理成本会比较高。

有个老外专门写了本书论证为啥技术好的人就该做leader， 你可以找找看。