写在改造已有项目架构之前

作为一个Web应用系统的架构师,之前也做过两个比较成熟的架构,基本上都是从无到有,个人总结的主要流程有:

    1. 业务需求分析:分析整个公司对框架的需求,分析领导的信心如何,时间是否充裕,要实现那些目标。

    2. 制定详细的架构目标:在此阶段一定要明确架构的目标,作为日后架构是否成功的判定标准,否则很难跟领导交代你做的架构是否成功了。

    3. 架构设计:对整个架构进行层次设计,功能模块设计,理清设计思路,整理架构设计文档。

    4. 技术路线选择和可行性分析:根据设计目标选择不同的技术路线,比如:是选择开源的技术组建还是自己开发?

    5. 详细设计:设计完整细致的开发流程

        1) 数据库交互流程:设计如何跟数据库交互,实用实体还是sql?

        2) 业务请求处理流程:设计前后台应用如何交互,ajax,post,webservice等等

        3) 跟美工一起设计前台页面样式风格

            a) 整体系统布局风格。

            b) 单独控件功能设计和属性设计。

    6. 代码架构初始化:初始化目录结构,设定初始规则,搭建框架原型。

    7. 典型模块开发:在原型中,使用常用布局,常用控件,常用的请求流程开发开发常用功能。

    8. 进阶功能的设计与开发:开发一些计划中的高级模块。

    9. 整理框架使用文档,框架使用标准等。

    10. 寻找简单业务系统,进行测试,对系统开发过程中遇到的问题,进行进一步的维护和升级。

进入新公司之后,发现公司之前对架构不重视,造成现在公司内的系统架构几乎每个系统一套,无法公用。

领导最近发现此问题,希望尽快整理公司整个架构体系,考虑到现有业务系统,因此最近一段时间会对现有业务系统进行框架改造。

个人对这种老系统的改造,总有一种推翻重来的冲动,个人觉得最有效的办法就是重构,尤其是出现以下情况:

    1. 代码经过几个人维护之后,代码越来越难读。

    2. 新增一个功能不一定会碰见什么”地雷“。

    3. 遍地的if/else语句。

    4. 大量的无用代码和重复代码,甚至很多重复的第三方引用,仅仅版本一样。

但是实际情况是,领导在考虑人力成本,时间成本时,不可能让你把现有的系统改造,因此想办法在现有的基础上如何改造。初步思路如下:

    1. 先找出系统中现有的明显问题,在不影响架构的基础上,将能改的改掉。

    2. 在现有技术路线的基础上,制定相应的标准(在不影响整体架构的基础上可以适当的新技术)。

    3. 按照相应的标准,逐步将原有的重复代码去掉。

    4. 对新增功能严格按照标准开发。

    5. 在未来的一段时间内,实现所有代码都符合标准,变成一个有标准架构的系统。

    6. 在适合的时间,系统推翻重构,新重构的代码严格按照新的标准执行。

      PS:

            这么做的原因是,从旧架构改造成为新架构有成功的可能,如果是一个代码随意的系统想改造难度太大。

 

 

希望能在未来的一段时间内能有一些成果。

作者:sdjnzqr
出处:http://www.cnblogs.com/sdjnzqr/
版权:本文版权归作者和博客园共有
转载:欢迎转载,但未经作者同意,必须保留此段声明;必须在文章中给出原文连接;否则必究法律责任

写在改造已有项目架构之前

时间: 2024-11-14 12:23:55

写在改造已有项目架构之前的相关文章

.Net Core MVC 网站开发(Ninesky) 2.3、项目架构调整(续)-使用配置文件动态注入

上次实现了依赖注入,但是web项目必须要引用业务逻辑层和数据存储层的实现,项目解耦并不完全:另一方面,要同时注入业务逻辑层和数据访问层,注入的服务直接写在Startup中显得非常臃肿.理想的方式是,web项目近引用接口而不引用实现,在配置文件中进行配置实现程序集合类,注入业务逻辑层而不必注入数据访问层. 一.数据访问层 在项目中摒弃数据访问层或者使用EntityFramework作为数据访问层. 在项目中数据访问层主要实现数据的存储,仔细看一下EntityFramework发现DbContext

一种比较实用的iOS SDK项目架构

在SDK开发中,一般会需要经过几个流程,开发SDK,测试SDK,把SDK交付给使用人员,这些东西看似步骤多,过程繁琐,而且每修改一次SDK就需要重复一次上述的过程,增加了一些不必要的操作.当然,如果我们在SDK设计之初就有一个好的项目架构,就可以极大简化开发流程,提高开发效率,本文将带读者一步一步设计搭建一个个人认为比较好的SDK开发架构. 创建基本的工作空间 工作空间这个概念对于很多人并不陌生,平时使用得很多的CocoaPods里面其实就使用到了工作空间,具体一些原理在我的另外一篇博客. 打开

项目架构开发:服务层(下)

之前我们已经完成了服务层,因为当时展现层还没有出来,所以只做了简单介绍.传送门:项目架构开发:服务层(上) 这次我们通过一个维护系统用户的场景来介绍一下服务层真正的设计用意. 1.新增用户场景 新增用户可能会有以下步骤 实现以上需求,开发人员一般情况下可能就是以上 蓝红黑紫绿 几种选择 1.有些写在Controllers.有些写在Application 2.都写在Controllers或都写在Application 3.有些写在DAL层.甚至存储过程 特别是新手以及那些拿来主义的人,他们不会花更

项目架构

项目架构 阅读目录 前言 六边形架构 终于开始建项目了 DDD中的3个臭皮匠 CQRS(Command Query Responsibility Segregation) 结语 一.前言 上一篇我们讲了DDD的核心概念(附上链接),并且设计了我们的上下文映射图,那么接下来就准备开始立项了,本篇文章的部分知识点可能对一部分人来说比较基础,可以选择性的阅读. 在这之前我们平常用的最多的应该就是3层架构了,这里也不展开描述了,大家都是在3层的陪伴下一路走来的~ DDD所使用的传统分层架构是松散分层,也

项目架构开发:数据访问层之Query

接上文 项目架构开发:数据访问层之Repository 上一章我们讲了IRepository接口,这张我们来讲IQuery 根据字面意思就可以知道,这次主要讲数据查询,上一章我们只针对单表做了查询的操作,多表联查并没有实现 其实对于任何一个项目来说,多表联查都是比较麻烦的地方,因为项目的“读”操作,特别是多表的“读”,至少占据所有“读”的一半以上 然而至今,据我所知还没有哪一款ORM工具可以灵活处理多表联查:想要不写sql语句,又想性能高,还想用强类型的ling查询方法:这对于多表查询来说比较难

项目架构开发:异常处理及日志

上一篇我们完善了多层开发的效率问题,传送门:项目架构开发:展现层(下) 这次我们完成架构的异常处理功能,异常处理一般都与日志分不开的,因为分析及定位问题需要一些详细信息: 稍微正规一点的公司,都会分开发.测试及生产环境.在本地及测试环境出BUG了,问题很好解决 调试跟踪问题,三下五除二就搞完了:但是在生产环境出问题,基本上是不允许直连数据库调试的: 这时候如何没有足够的异常信息参考,那你就悲催了,你等着加班熬夜吧. 为了解决这个问题,所以异常信息的捕捉及记录就显得非常重要了,一个完善的系统,出问

改造已有的A类里面的aa方法

    继承 写一个类继承A类,改造aa方法,必须保证A类没有子类,才能用继承改造方法.如果已经有了一个A类对象了,用继承是不能改造已有的A类对象.    装饰 写一个类实现和A类相同的接口,保证装饰者和被装饰者具有相同的方法.提供构造方法,允许用户在构造装饰者对象时候把被装饰者得对象传入,对不想改造的方法调用原A类的方法,对想改造得方法自己去写就可以了.   动态代理 已经有了A类的一个对象了,对其中的aa方法不满意.创建一个代理对象,代理对象直接调用A类中不需要改造的方法,代理者自己写一个方

iOS项目架构

关于项目架构的问题,我想,作为已经具有两年开发经验的本人来说,还是有一些不大不小的问题,下面来总结一下这些问题. 目录结构 AppDelegate Models Macro General Helpers Vendors Sections Resources 一个合理的目录结构首先应该是清晰的,让人一眼看上去就能大概了解目录的职责,且容易应对新的变化. AppDelegate 这个目录下放的是AppDelegate.h(.m)文件,是整个应用的入口文件,所以单独拿出来. Models 这个目录下

将已有项目提交到github/从github上pull到本地

之前都写过一篇github常用命令的文章,可是这些日子来,发现自己根本没掌握,真是很讨厌github这种提交方式,如果能够使用界面操作多好啊. 添加已有项目到github 新建repository,可以在github网站上直接新建或者使用windows github工具. 进入github repository 项目 在github windows工具中使用git Bash打开项目,使用cd命令进入已有项目根目录下 touch README.md //新建说明文件git init //在当前项目