2010技术应用计划

导读:

“2010技术应用计划”是去年3月中心部门头脑风暴“成果”的一部分,现在重新回顾一下,当时的许多计划或许对现在及以后还有一定的意义,故放在我的博客“朝花夕拾”分类中。

1 架构参与方案以及计划

1.1 解决的问题:

代码质量差、Bug多

注:这个问题只是从架构工作的视角,帮助开发人员改善代码质量,降低Bug数量的方案。

1.2 参与方案:

1.2.1 树立架构意识

通过各种形式,介绍软件架构的概念,使用架构的好处,在开发人员中树立使用架构的意识。这些形式可以是平常技术交流(Coffee Time ),专题培训,论坛文章,编写演示代码,项目架构代码ReView等。

1.2.2 对开发人员进行架构培训

开发人员应该熟悉掌握项目使用的软件架构,但在进行详细的开发之前,应该先对架构有所了解,这就需要进行架构培训。培训的目的不是为了详细掌握架构的方方面面,而是架构可以提供什么,不能提供什么。让开发人员明白遵循架构的意义,是为了开发更规范,维护行更好,代码复用率更高。

1.2.3 在编码开发之前,指导项目架构的搭建

在确定项目需要使用某种架构之后,在项目进入正式的编码开发之前,指导开发人员进行项目架构的实际搭建过程,这样能够使开发人员对架构有更深的印象,明白架构是如何工作的,了解搭建架构过程中的细节,从而在开发过程中遇到问题的时候有助于找到原因。

1.2.4 在编码开发过程中,帮助开发人员熟悉使用架构

尽管开发前进行了架构培训,但“说的永远比做的容易”,开发人员进行实际的项目开发过程中总会有各种各样的问题,架构组除了提供必要的架构文档支持外,也应该做开发人员的“贴身顾问”,随时解决他们棘手的问题,帮助他们熟悉使用架构。

1.2.5 不定期架构规范检查

确保架构规范得到遵循是软件质量的重要保证,架构组必须检查开发人员使用架构的情况,比如是否直接在业务层代码中直接写了SQL语句,是否在UI层直接调用了DAL层代码,是否正确的使用了事务,实体对象,是否自己重复实现了一些架构框架本已经实现的功能。发现这些问题后,架构组会以“架构代码ReView”的形式发出检查报告,并请开发经理督促开发人员改正。

架构规范的检查时间点严则上开发中期和项目进入SIT测试前各进行一次,不排除在整个编码开发时间内,不定期的进行架构规范检查。

1.2.6 架构总结

在项目开发完成以后,架构组和开发组一期进行一次架构使用情况的总结,评估架构的实际作用,总结架构的使用情况,比如使用的经验,遇到的问题,对架构的认识,架构需要改进的建议等。

对项目开发中使用架构的总结是树立架构意识的重要途径,对架构的完善和开发技能的提高有很重要的意义。

1.3 工作计划:

改善代码质量的架构工作计划的具体时间随各个项目计划的时间而定,这里仅仅列出一些计划的步骤。

序号

工作项

项目阶段

1

树立架构意识

全程

2

对开发人员进行架构培训

编码开发前

3

指导项目架构的搭建

编码开发前

4

帮助开发人员熟悉使用架构

编码开发阶段

5

架构规范检查

编码开发中期一次 进入SIT测试前一次 其它时间为不定期进行

6

架构总结

项目开发完成

2 应用平台计划

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 开源和破解资源利用方案计划 3.1 解决问题

开发人员缺乏热情

3.2 计划内容

l 鼓励开发人员提供开源的技术框架

l 鼓励开发人员提供技术相关破解资源

l 鼓励开发人员提供技术问题解决方案

l 鼓励开发人员分分享技术经验

3.3 实施方式

对于开发人员提供的解决方案(见计划内容部分), 如经项目采纳并起到良好效果, 即对开发人员进行相应奖励, 以示鼓励及提高其工作热情.

如: 发放小礼品, 提供相关福利待遇等. 如有重大贡献的可给予适当奖金.

3.4 相关案例

Pet Shop 4.0

由微软开源的一套WEB宠物商店系统, 其中运用了大量asp.net2.0的新特性.

Composite UI Application Block

由微软设模式与实践团队提供的一套开源的开发框架, 用于解决不同业务间界面组合等诸多问题, 其中运用了大量的设计模式.

Unity Application Block

Unity是微软模式与实践团队开发的一个轻量级、可扩展的依赖注入容器, 用于解决对象创建以及对象间依赖关系.

Asp.net MVC 1.0

由微软开发并开放源代码的一个套B/S的开发包, 以其清晰的逻辑划分、良好的测试支持等诸多优点深受广大开发者喜爱.

基于插件式开发框架

这个是由本人(丁一宸)开发的一套插件式开发框架, 此框架用于解决项目中功能组件的插拔等诸多问题, 基于面向对象开发并具有良好的扩展性.

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 参考

本章节的内容来自下面网页内容的收集和整理:

软件开发流程

http://www.360doc.com/content/08/0123/23/10034_999271.shtml

敏捷思维—架构设计中的方法学

http://www.360doc.com/content/08/0123/23/10034_999271.shtml

架构设计的10条经验

http://www.bookfm.com/courseware/coursewaredetail.html?cid=100416

架构重构改善既有代码的设计

http://www.51edu.com/it/2009/0405/article_18203.html

架构设计中的方法学(6)——迭代设计

http://www.examda.com/soft/zhongji/soft/20070808/135821538.html

演进式架构设计在敏捷开发中的使用(2)

http://developer.51cto.com/art/200906/128678_1.htm

炫目的敏捷架构师

http://news.csdn.net/n/20080730/117754.html

在敏捷开发中采用演进式架构设计

http://www.phpchina.com/?action_zendinfoview_itemid_34567.html

敏捷和架构

http://book.csdn.net/bookfiles/1036/100103631172.shtml

软件的架构设计

http://www.mscto.com/SoftEngin/analyze/2009012317496.html

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏技巅

系统架构和代码实现的高可控性

25340
来自专栏程序你好

微服务开发中5个惨痛教训

基于微服务的开发正在改变我们整个行业,超过70%的人正在尝试开发基于微服务的软件。微服务简化了业务、流程、技术和人员的集成,将大爆炸的整体问题分解为一个可以独立...

12630
来自专栏云计算D1net

基础设施即代码让混合多云管理更为复杂

对于任何一个力,都存在着一个与其大小相等方向相反的反作用力。这个物理学上的牛顿第三定律也同样适用于IaC:虽然这一服务是有优势的,但它也带来了一些问题。 本文是...

30780
来自专栏DevOps时代的专栏

一篇文章搞清楚 CI, CD AND CD

CI, CD AND CD 当我们在谈论现代的软件编译和发布流程的时候,经常会听到CI 和CD这样的缩写短语。CI很容易理解,就是持续集成。但是CD既可以指代码...

39480
来自专栏云计算D1net

助力云部署简化的六款云解决方案

由于云采用率急剧提高,市面上用来保护、管理和监控云环境的解决方案多得让人眼花缭乱。为了帮助你简化这个过程,我们建议使用下列产品来满足采用云方面的所有要求。 ? ...

38460
来自专栏网站设计制作、数字营销

做网站留后门的网站制作公司不能选

无论是做公司网站还是其他类型的网站,如果你发现做网站的公司做的网站留有后门,在网站上线后,网站制作公司仍可以自由通过后门权限对网站后台进行操作的,最好还是换一家...

13200
来自专栏腾讯大讲堂的专栏

如何系统性地保障软件的性能

一个正在持续增加新功能的软件,尤其是类似QQ这种做为一个超大规模客户端软件,又随时需要适应用户要求和发展的需求,需要不断的做快速的更新,开发节奏非常快。而且因为...

24960
来自专栏WeTest质量开放平台团队的专栏

Now 直播应用的后台服务器性能测试实践

直播的火爆带来了海量的用户,也带来了海量的服务器并发。本文分析了目前直播行业存在的难点,从腾讯目前的新直播产品的 NOW 直播出发, 了解直播应用背后的那些事...

2.4K10
来自专栏技术墨客

multi-tenant solution(多租户方案)说明

今天在研究vertx-Metrics时碰到了一个multi-tenant solution的概念,特此整理记录相关资料。

31620
来自专栏企鹅号快讯

到底小程序为何而生?一章纯文解释

小程序制作|网站建设 贵阳同城信息交流平台 小程序是为了弥补服务号的不足而设计的。2016年初张小龙在宣布“应用号”(小程序前身)的设想时,是这样说的:“我们开...

32370

扫码关注云+社区

领取腾讯云代金券