简单是一种美:提高项目成功率的一些方法
来源:互联网 发布:指定flashfxp端口 编辑:程序博客网 时间:2024/04/28 13:16
大家都希望自己参与的项目能够成功交付,然而影响每个项目是否成功的因素却千差万别。在此,根据自己的经验,说说一些在适当时候有用的方法,可以从一定程度上提高项目成功率的方法。就像设计模式一样,这些方法的使用过程必然是一个仁者见仁、智者见智的过程。
1. 尽量不要考虑项目外的重用
许多人认为能提高软件的重用度是最好的,然而每个项目实际情况都会有所不同,在设计项目中的某个模块、方法时,过多的考虑项目外的重用,必然会参加项目的复杂度,增加时间的开销。也许有人会说,这会减少下一项目的开销,试问,下一项目是什么项目?有什么需求?各方面有什么影响因素?有谁会在当前知道这一切。 如果真要重用,应该是在项目结束后再将可重用的部分提取出来,经过修改、优化后做为企业的可重用资产,而不是当前项目中的一厢情愿。
2.经常检查项目架构
项目架构通常是在项目实现开始前就已确定的东西,是一个总体的设计。然而,在这时,对项目需求的理解、复杂度的估计对还停留在一个初始阶段。如果在项目开发过程中不随着对项目的理解改进架构,必然让项目中的成员都按错误的方法开发项目。所以,必须经常检查项目的架构,进行必要的重构。
3.重构
有人说,都写了这么多了,再修改不是浪费时间嘛。他可能没有想过,一个下午的重构可以加快以后几个月的开发速度,这节省下来的时间是无法想象的。再者,通过重构,通常能想到更多简单的方法来代替现有的实现,这样的经验,同样可以简化其他模块的开发。
4.避免过度集成,让每个模块只做自己的事
一个常见的例子是,在业务系统中通常会有许多的审批,很多人一下子肯定会想到把审批做成一个通用的模块。这是没有问题的,然而通常的问题是,太多的人将审批结束后的业务处理也放到了审批模块的业务逻辑中,其实,那些是各业务模块自己的事,审批应该只完成审批即可,至于审批结束后怎么办,让该干这事的模块自己去处理。
5.避免过度灵活
设计和代码并不是越灵活越好的。一个常见的例子是,使用泛型时可以使类或者方法操作不同的对象,然而,在 .NET 常用的 N 层架构中,如果一系列的类本来就是针对某个特定实体的操作,就没有必要还指定为泛型,再在使用时指定为使用特定的实体类。这颇有画蛇添足的感觉。
6.减少锦上添花的功能
页面无刷新,更酷的显示效果等等,对于业务系统来说都是些锦上添花的事,如果因为这些而使业务界面非常复杂,给业务处理带来一系列的问题,极端情况是业务处理无法继续时,再漂亮的界面也是无用的。一个忠告时,仅在确保业务处理正确进行的前提下再考虑其他的。这一点有一个前提是与用户进行必要的沟通。
7.适当拆分
这一点与 4 类似。尽量降低每个模块的复杂度,让脑力劳动转化成体力劳动。一个常见的例子是,通常对某个表单都会有增加、修改、删除和查看的功能。但是,前三种操作通常仅在某个功能点上、特定状态和特定权限的人进行操作(也许仅在在系统中的唯一一个界面中)。而查看操作却会分布在项目的各个角落,如果将这四种操作都放在同一界面中,虽然可以减少界面数,但增加的却是这一界面的复杂度,要对各种状态、条件进行必须的判断来进行界面元素的只读设置,这个复杂度的增加是指数级的,而如果将查看拆分开,工作量将是线性的,就算要做10个查看界面,总比复杂度变成 10*10 要容易处理得多,况且还可以组件化。
这些都是由项目中的经验而来,总的来说,都是为了降低项目的复杂度,提高开发的效率。需要时可以适当的加以使用。
1. 尽量不要考虑项目外的重用
许多人认为能提高软件的重用度是最好的,然而每个项目实际情况都会有所不同,在设计项目中的某个模块、方法时,过多的考虑项目外的重用,必然会参加项目的复杂度,增加时间的开销。也许有人会说,这会减少下一项目的开销,试问,下一项目是什么项目?有什么需求?各方面有什么影响因素?有谁会在当前知道这一切。 如果真要重用,应该是在项目结束后再将可重用的部分提取出来,经过修改、优化后做为企业的可重用资产,而不是当前项目中的一厢情愿。
2.经常检查项目架构
项目架构通常是在项目实现开始前就已确定的东西,是一个总体的设计。然而,在这时,对项目需求的理解、复杂度的估计对还停留在一个初始阶段。如果在项目开发过程中不随着对项目的理解改进架构,必然让项目中的成员都按错误的方法开发项目。所以,必须经常检查项目的架构,进行必要的重构。
3.重构
有人说,都写了这么多了,再修改不是浪费时间嘛。他可能没有想过,一个下午的重构可以加快以后几个月的开发速度,这节省下来的时间是无法想象的。再者,通过重构,通常能想到更多简单的方法来代替现有的实现,这样的经验,同样可以简化其他模块的开发。
4.避免过度集成,让每个模块只做自己的事
一个常见的例子是,在业务系统中通常会有许多的审批,很多人一下子肯定会想到把审批做成一个通用的模块。这是没有问题的,然而通常的问题是,太多的人将审批结束后的业务处理也放到了审批模块的业务逻辑中,其实,那些是各业务模块自己的事,审批应该只完成审批即可,至于审批结束后怎么办,让该干这事的模块自己去处理。
5.避免过度灵活
设计和代码并不是越灵活越好的。一个常见的例子是,使用泛型时可以使类或者方法操作不同的对象,然而,在 .NET 常用的 N 层架构中,如果一系列的类本来就是针对某个特定实体的操作,就没有必要还指定为泛型,再在使用时指定为使用特定的实体类。这颇有画蛇添足的感觉。
6.减少锦上添花的功能
页面无刷新,更酷的显示效果等等,对于业务系统来说都是些锦上添花的事,如果因为这些而使业务界面非常复杂,给业务处理带来一系列的问题,极端情况是业务处理无法继续时,再漂亮的界面也是无用的。一个忠告时,仅在确保业务处理正确进行的前提下再考虑其他的。这一点有一个前提是与用户进行必要的沟通。
7.适当拆分
这一点与 4 类似。尽量降低每个模块的复杂度,让脑力劳动转化成体力劳动。一个常见的例子是,通常对某个表单都会有增加、修改、删除和查看的功能。但是,前三种操作通常仅在某个功能点上、特定状态和特定权限的人进行操作(也许仅在在系统中的唯一一个界面中)。而查看操作却会分布在项目的各个角落,如果将这四种操作都放在同一界面中,虽然可以减少界面数,但增加的却是这一界面的复杂度,要对各种状态、条件进行必须的判断来进行界面元素的只读设置,这个复杂度的增加是指数级的,而如果将查看拆分开,工作量将是线性的,就算要做10个查看界面,总比复杂度变成 10*10 要容易处理得多,况且还可以组件化。
这些都是由项目中的经验而来,总的来说,都是为了降低项目的复杂度,提高开发的效率。需要时可以适当的加以使用。
- 简单是一种美:提高项目成功率的一些方法
- 简单是一种美
- 提高项目成功率
- 如何提高项目成功率
- 撩妹子成功率提高99.89%的方法
- 提高sas安装成功率的方法
- 简单,是一种大美
- 简单是一种方法
- 毕业生提高求职成功率的3个方法
- 初恋是一种枯涩的美
- 欣赏是一种绝美的风景
- 好的代码风格是一种美!
- 坚持是一种别样的美
- 学会放弃是一种成熟的美
- 提高自己的一种方法
- 简约是一种美
- 阅读是一种美
- 思念是一种美
- 图片按比例缩放,可输入参数设定初始大小
- 颜色代码选择器
- 千万级数据分页详细设计
- 水晶报表的制作(图表)
- 试用EF开发WEB应用程序(4): 缓存Query String
- 简单是一种美:提高项目成功率的一些方法
- 管理软件开发项目关键风险
- 软件项目开发过程中应编写的十三类文档
- 软件项目管理-会议记录模板
- 解决aspx页面弹出对话框时,有时正常,有时出现乱码,有时弹出又马上关闭的问题
- 关于项目管理的一点体会
- 影响项目的因素及经验总结
- PL/SQL存储过程编程
- 优秀团队建设-美国式团队