项目旧代码常见问题
来源:互联网 发布:切糕淘宝湖南 编辑:程序博客网 时间:2024/04/29 17:28
公司一直在强调编程规范,但编程规范只能规避一些程序编写浅层次的问题,至于一些深层次的问题,只能靠人的自觉和开发能力的提升了。
以下都是我以为的在程序设计开发中普遍存在的深层次的问题,这些问题光靠编程规范等文档的指导是无法避免的。
程序中充斥了大量相同或相近的代码。这样做在开发的时候会省时,省力,因为只要copy一下既有代码,就很容易的添加了新的功能项,而且即不用费太多的脑筋,又可以有很多的代码量,用的时间也很短。但是,这样的程序放到维护阶段就可以说是噩梦了,因为同一个功能要修改好几个地方。而且很容易漏改,或者引入新的问题。
我们现在评估工作量是按照代码量,而不是按照代码的质量。如果盲目的看重代码量,就很容易造成COPY/PASTE泛滥的现象。
重构理论强调“事不过三,三必重构”,同样的代码如果出现了三次,那么出现四次,五次的几率就很大了。为了长远的方便,现在多做一些优化整理的工作也是值得的。软件出现bug的概率并不是随着软件规模呈线性增长的,而是呈指数级的增长。如果有2处重复,出错概率是2的话,那么3处重复,概率就为4;4处就为8... 重复次数少的话,出现的错误还可以处于可控范围内,如果重复次数到了一定程度,那么软件即使能维护,其成本也是极其高的。
在出现第二次重复,或者第三次重复的时候进行相应的重构工作是最容易的,而且可以将出错的概率一下从2或4降为1。如果重复次数多了,再重构的话,那所要付出的工作量就不是一般的大了,因为要协调适配各种相近的情况。
编写程序,一开始不要涉及太多的设计模式,要本着简单快速的原则。在发现有重复情况出现,开始重构的时候再引入合适的设计模式。因为设计模式的本质就是将重复或易变的地方提取出来,便于以后的维护,扩展。出现第二次重复的时候,你才能发现这些地方,所以这时才是应用设计模式的最好时机。
IF/ELSE,SWITCH/CASE 泛滥。使用了面向对象的程序语言,编写出来的并不一定就是面向对象的程序。这一点可以从我们程序中的if/else, switch/case 使用的情况看出来。它们使用的越多(因为没有使用多态),那么程序面向对象的特性就越差。经常可以在程序中看到4,5个if/else组合,switch下十多个case的情况,这些开发时的图一时之轻松,都为以后版本的难以维护埋下了伏笔。(维护人员埋怨以前的开发质量差也不是没有道理的)
程序没有分层规划,不管前台,后台,程序按照功能来划分,就是3个层次,数据持久层,数据控制层,业务逻辑层。前台程序还要在最后添加上显示层。前台的代码经常可以看到在界面程序中直接调用前后台交互命令,数据转换,显示处理,一气呵成。后台据说也是业务逻辑和数据持久化都写在一起。
这样的坏处显而易见的,写不了或者不好写测试代码;加大调试难度;bug在整个程序范围内泛滥。
大而化小,分而治之。越大越复杂的东西越不好管理,越小越简单的则相反。软件设计要讲究颗粒度,粒度太大太小都不好,最重要的就是掌握好合适的度。在方便性和数量上取一个合适的平衡。一般来说分3层就很合适了,数据持久层,数据控制层,业务逻辑层,每一层各司其职,每一层的功能实现对其他层都是透明的。
如果采用了分层可以取得以下几点好处:更方便的写出测试代码;调试更方便;BUG禁锢在某一层上,不会向整个系统蔓延;每个界面可以脱离主框架单独运行;可以使用界面纪录工具进行通用功能的自动化系统测试。
类之间的交互,多使用接口,尽量少用继承和具体类。使用接口,进可攻,退可守,完全是随需应变,不会将自身绑定在某种条件下,利于程序的变化,扩展。
以下都是我以为的在程序设计开发中普遍存在的深层次的问题,这些问题光靠编程规范等文档的指导是无法避免的。
程序中充斥了大量相同或相近的代码。这样做在开发的时候会省时,省力,因为只要copy一下既有代码,就很容易的添加了新的功能项,而且即不用费太多的脑筋,又可以有很多的代码量,用的时间也很短。但是,这样的程序放到维护阶段就可以说是噩梦了,因为同一个功能要修改好几个地方。而且很容易漏改,或者引入新的问题。
我们现在评估工作量是按照代码量,而不是按照代码的质量。如果盲目的看重代码量,就很容易造成COPY/PASTE泛滥的现象。
重构理论强调“事不过三,三必重构”,同样的代码如果出现了三次,那么出现四次,五次的几率就很大了。为了长远的方便,现在多做一些优化整理的工作也是值得的。软件出现bug的概率并不是随着软件规模呈线性增长的,而是呈指数级的增长。如果有2处重复,出错概率是2的话,那么3处重复,概率就为4;4处就为8... 重复次数少的话,出现的错误还可以处于可控范围内,如果重复次数到了一定程度,那么软件即使能维护,其成本也是极其高的。
在出现第二次重复,或者第三次重复的时候进行相应的重构工作是最容易的,而且可以将出错的概率一下从2或4降为1。如果重复次数多了,再重构的话,那所要付出的工作量就不是一般的大了,因为要协调适配各种相近的情况。
编写程序,一开始不要涉及太多的设计模式,要本着简单快速的原则。在发现有重复情况出现,开始重构的时候再引入合适的设计模式。因为设计模式的本质就是将重复或易变的地方提取出来,便于以后的维护,扩展。出现第二次重复的时候,你才能发现这些地方,所以这时才是应用设计模式的最好时机。
IF/ELSE,SWITCH/CASE 泛滥。使用了面向对象的程序语言,编写出来的并不一定就是面向对象的程序。这一点可以从我们程序中的if/else, switch/case 使用的情况看出来。它们使用的越多(因为没有使用多态),那么程序面向对象的特性就越差。经常可以在程序中看到4,5个if/else组合,switch下十多个case的情况,这些开发时的图一时之轻松,都为以后版本的难以维护埋下了伏笔。(维护人员埋怨以前的开发质量差也不是没有道理的)
程序没有分层规划,不管前台,后台,程序按照功能来划分,就是3个层次,数据持久层,数据控制层,业务逻辑层。前台程序还要在最后添加上显示层。前台的代码经常可以看到在界面程序中直接调用前后台交互命令,数据转换,显示处理,一气呵成。后台据说也是业务逻辑和数据持久化都写在一起。
这样的坏处显而易见的,写不了或者不好写测试代码;加大调试难度;bug在整个程序范围内泛滥。
大而化小,分而治之。越大越复杂的东西越不好管理,越小越简单的则相反。软件设计要讲究颗粒度,粒度太大太小都不好,最重要的就是掌握好合适的度。在方便性和数量上取一个合适的平衡。一般来说分3层就很合适了,数据持久层,数据控制层,业务逻辑层,每一层各司其职,每一层的功能实现对其他层都是透明的。
如果采用了分层可以取得以下几点好处:更方便的写出测试代码;调试更方便;BUG禁锢在某一层上,不会向整个系统蔓延;每个界面可以脱离主框架单独运行;可以使用界面纪录工具进行通用功能的自动化系统测试。
类之间的交互,多使用接口,尽量少用继承和具体类。使用接口,进可攻,退可守,完全是随需应变,不会将自身绑定在某种条件下,利于程序的变化,扩展。
- 项目旧代码常见问题
- 项目旧代码常见问题
- 项目旧代码常见问题
- 项目旧代码常见问题
- 项目旧代码常见问题
- 项目旧代码常见问题
- 如何国际化旧项目
- bug之旧项目
- 旧代码 - 手写堆
- 旧代码 - 高精度加法
- 旧代码 - 高精度乘法
- 旧代码 - 高精度阶乘
- PHP旧代码迁移
- 图片上传代码-旧的实现方式,项目中已删除,发表做备用
- 维护系统旧代码有感
- 旧代码 - 最短路 Floyd
- 旧代码 - 最短路 Spfa
- 旧项目好像有了点转机
- iOS ASIHTTPRequest详解
- error: QApplication: No such file or directory
- FAT长文件名 校验和算法 例子分析
- 实习两月总结一下
- Mac OS X使用之——基本操作及常用App整理
- 项目旧代码常见问题
- 岁末总结,永不放弃!
- 一些信息保存
- openstack keystone
- 新站可以考虑从长尾关键字来做SEO
- 机器学习中的各种距离
- 发布高质量外链的绝佳时间点
- [IOS] viewDidLoad
- .NET 下使用 log4net