代码质量差、Bug多
注：这个问题只是从架构工作的视角，帮助开发人员改善代码质量，降低Bug数量的方案。
通过各种形式，介绍软件架构的概念，使用架构的好处，在开发人员中树立使用架构的意识。这些形式可以是平常技术交流（Coffee Time ），专题培训，论坛文章，编写演示代码，项目架构代码ReView等。
开发人员应该熟悉掌握项目使用的软件架构，但在进行详细的开发之前，应该先对架构有所了解，这就需要进行架构培训。培训的目的不是为了详细掌握架构的方方面面，而是架构可以提供什么，不能提供什么。让开发人员明白遵循架构的意义，是为了开发更规范，维护行更好，代码复用率更高。
在确定项目需要使用某种架构之后，在项目进入正式的编码开发之前，指导开发人员进行项目架构的实际搭建过程，这样能够使开发人员对架构有更深的印象，明白架构是如何工作的，了解搭建架构过程中的细节，从而在开发过程中遇到问题的时候有助于找到原因。
尽管开发前进行了架构培训，但“说的永远比做的容易”，开发人员进行实际的项目开发过程中总会有各种各样的问题，架构组除了提供必要的架构文档支持外，也应该做开发人员的“贴身顾问”，随时解决他们棘手的问题，帮助他们熟悉使用架构。
确保架构规范得到遵循是软件质量的重要保证，架构组必须检查开发人员使用架构的情况，比如是否直接在业务层代码中直接写了SQL语句，是否在UI层直接调用了DAL层代码，是否正确的使用了事务，实体对象，是否自己重复实现了一些架构框架本已经实现的功能。发现这些问题后，架构组会以“架构代码ReView”的形式发出检查报告，并请开发经理督促开发人员改正。
架构规范的检查时间点严则上开发中期和项目进入SIT测试前各进行一次，不排除在整个编码开发时间内，不定期的进行架构规范检查。
在项目开发完成以后，架构组和开发组一期进行一次架构使用情况的总结，评估架构的实际作用，总结架构的使用情况，比如使用的经验，遇到的问题，对架构的认识，架构需要改进的建议等。
对项目开发中使用架构的总结是树立架构意识的重要途径，对架构的完善和开发技能的提高有很重要的意义。
改善代码质量的架构工作计划的具体时间随各个项目计划的时间而定，这里仅仅列出一些计划的步骤。
| 序号 | 工作项 | 项目阶段 |
| 1 | 树立架构意识 | 全程 |
| 2 | 对开发人员进行架构培训 | 编码开发前 |
| 3 | 指导项目架构的搭建 | 编码开发前 |
| 4 | 帮助开发人员熟悉使用架构 | 编码开发阶段 |
| 5 | 架构规范检查 | 编码开发中期一次 进入SIT测试前一次 其它时间为不定期进行 |
| 6 | 架构总结 | 项目开发完成 |
2 .1 解决的问题：
缺少应用平台
调查反馈
张鹏：目前我最想要的就是公共类库的创建与使用,其它的暂时还没有想到
周燕龙：常用的web操作or winfrom类库，目前有的好像不太够
2 .2 计划内容：
2 .2.1 公共类库建设
包含Web应用的类库，WinForm应用的类库。每一类类库都划分合理的命名空间，各个类都保持最小的外部程序集引用，比如，避免在WinForm的类库中引用Web方面的程序集。
目前对于公共类库的初步划分为：
l 文件目录操作
l 压缩解压
l WinAPI调用
l 消息处理
l HTML文件处理
l 大文件上传
l HTTP下载
l Web缓存
l FTP客户端
l 邮件发送接收
l Word文件操作
l Excel文件操作
l 通用对话框
类库源码在TFS上面开辟专区管理，作为一个单独的解决方案开发，不在和现有的项目混合编译。只有架构组拥有类库源码完全的控制权，其他开发人员可以查看和获取源码。
2 .2.2 示例代码库
对公共类库中的每个组件，类的使用，都要有相应的示例代码，这些示例代码也在TFS上面管理，并且示例代码的摘要包含在帮助文档中，便于迅速查找使用。
2 .2.3 架构文档库
对架构文档，组件设计使用说明文档，公共类库使用文档进行详细的编写和分门别类的管理，做到有程序，有源码，有文档，而且三者同步更新。
2 .2.4 版本管理
公共类库，示例代码，架构文档等都使用TFS进行版本管理，对每一次比较大的变更都做一次版本标记，确保开发人员能够获取到最新的版本。
2 .2.5 推行组件管理流程
在开发规范中已经制订了组件管理流程，架构组协助推行组件管理流程，使得组件的功能需求，设计，开发，使用培训等有顺畅的流程，让开发人员把框架，组件用起来。
2 .2.6 辅助开发工具
研究和开发一些辅助开发工具，比如代码生成工具，IDE外接程序，可视化参数管理工具等。使用这些工具，能够很方便快速的搭建相应开发框架，减少手工代码编写量，提高开发效率。
开发人员缺乏热情
3.2 计划内容l 鼓励开发人员提供开源的技术框架
l 鼓励开发人员提供技术相关破解资源
l 鼓励开发人员提供技术问题解决方案
l 鼓励开发人员分分享技术经验
3.3 实施方式对于开发人员提供的解决方案(见计划内容部分), 如经项目采纳并起到良好效果, 即对开发人员进行相应奖励, 以示鼓励及提高其工作热情.
如: 发放小礼品, 提供相关福利待遇等. 如有重大贡献的可给予适当奖金.
3.4 相关案例l Pet Shop 4.0
由微软开源的一套WEB宠物商店系统, 其中运用了大量asp.net2.0的新特性.
l Composite UI Application Block
由微软设模式与实践团队提供的一套开源的开发框架, 用于解决不同业务间界面组合等诸多问题, 其中运用了大量的设计模式.
l Unity Application Block
Unity是微软模式与实践团队开发的一个轻量级、可扩展的依赖注入容器, 用于解决对象创建以及对象间依赖关系.
l Asp.net MVC 1.0
由微软开发并开放源代码的一个套B/S的开发包, 以其清晰的逻辑划分、良好的测试支持等诸多优点深受广大开发者喜爱.
l 基于插件式开发框架
这个是由本人(丁一宸)开发的一套插件式开发框架, 此框架用于解决项目中功能组件的插拔等诸多问题, 基于面向对象开发并具有良好的扩展性.
5 渐进迭代和Morphing 开发 5.1 解决的问题：
客户响应慢
5.2 架构设计中的方法问题
源自需求、团队设计、简单设计、迭代设计这4种过程模式归类为架构设计的第一层次，这4种模式能够确定架构设计过程的框架。
5.2.1 源自需求
源自需求提供了架构设计的基础。在软件过程中，架构设计是承接于需求分析的，如果没有良好的需求分析活动的支持，再好的架构设计也没有用。因此我们把这一模式放在首位，做为架构设计的目标。
5.2.2 团队设计
敏捷方法提倡优秀的沟通，因此团队设计是必要且有效的。而团队设计的另一个意图，是保证架构设计的下游活动得以顺利的进行，例如详细设计、编码、测试等。由于开发团队中的人大都加入了架构设计，因此最大程度的减小了不同的活动间的信息损耗和沟通效率低下的问题。如果说源自需求模式是起承上的作用，那么团队设计模式则是扮演了启下的角色。
在软件设计的过程中，沟通往往扮演着非常重要的角色。团队设计对沟通的贡献在于它能够把设计意图以最小的代价传播到开发团队的每个角落。这样，设计和下游的活动间由于沟通不畅产生的问题就能够得到缓解。
5.2.3 简单设计
在设计中，我们发现，当设计信息转换为编码信息需要一定的时间，这个时间包括设计的组织时间，设计被理解的时间。如果设计比较复杂，或者说设计的文档比较复杂，编码人员花在理解上的时间就会大大增加。
简单的思路还会用在软件开发的各个方面，例如文档、设计、流程。坚持简单的原则，并不断的加以改进，是降低软件开发成本的一种很有效的做法。
5.2.4 迭代设计
需求的变化将会导致设计的不稳定，而需求的复杂性又会导致简单架构设计的困难。为了解决这个问题，我们引入了迭代的方法，将问题分割为多个子问题（把一个复杂的问题分解为多个较简单的子问题是计算机领域最常见的处理方法）。这样，问题的范围和难度都大大降低了。而更关键的是，由于对用户需求理解不充分或用户表达需求有错导致的设计风险被降到最低点。迭代和前面几个模式都有关系。
（中间的若干内容5.3-5.8 由于篇幅较长，将另外开贴讨论）
5.9 总结：Morphing 之中的架构问题
Morphing作为我们公司倡导的一种敏捷开发模式，与XP，RUP，Scrum，FDD有很多相似之处，架构也是遵循渐进迭代模式的。这里总结一下Morphing之中的架构：
ü 需求分析是架构设计的基础
ü 架构设计来自团队的力量
ü 简单适用的架构
ü 根据业务的发展不断完善架构
ü 架构=分层+分区+机制提取
ü 不断对架构进行重构
5 .10 参考
本章节的内容来自下面网页内容的收集和整理：
软件开发流程
敏捷思维—架构设计中的方法学
架构设计的10条经验
架构重构改善既有代码的设计
架构设计中的方法学(6)——迭代设计
演进式架构设计在敏捷开发中的使用(2)
炫目的敏捷架构师
在敏捷开发中采用演进式架构设计
敏捷和架构
软件的架构设计