快速开发
刚刚组里开会讨论如何进行项目的快速开发,并且可以让客服人员很好地维护我们的系统.
老人们讨论得热火朝天,我没什么经验,也没有成熟的观点,还是在属于自己的领地里谈自己的看法吧,哈哈.
我觉得要讨论快速开发,首先要弄清楚瓶颈在那里,能大幅度提高桶容量的是最短的木板.去掉Wrapper类除了可以少拷贝一次函数的定义,彻底放弃了分布 式部署外,还会有多大的效率提升那?正如以前我总是抱怨增加了Wrapper类除了多拷贝了一次函数和增加了一个看起来似乎永远不会用到的分布式外,没有 其他用处一样,其实这一进一出之间根本没多大出入.在把接口,Wrapper中的方法定义好以后,后来的业务逻辑和后台数据库的改变只会影响到 Facade和Manager这两个CS文件,修改的时候只需要修改这两个文件.按照我的想法,完全可以Manager里的SQL语句放到XML文件里, 这样修改的时候只需要修改XML文件,后台的代码根本不需要变动,Manager写一个统一的方法选取XML中的结点值,其实Palau早就支持这样的做 法了,不知道为什么大家宁可一行行地粘SQL也不愿意采用直接采用XML文件那?说到效率问题,从XML文件中读取一个字符串真的就比把N多的字符串拼在 一起快吗?
有一个事实很让我寒心,分层的意义是什么?不就是为了隔离设计,在变化来临的时候可以"拥抱变化"吗?就像典型的Internet网络传输的分层设计,换 用不同类型的网卡和网线,传输层根本不需要做什么改动一样.当然Martin Flower他老人家也承认企业软件比通信软件有更多的变化,可是这不能成为放弃的理由吧.
我觉得现在的项目不能快速结案,绝不是因为多拷了几个函数定义造成的!
我总是不喜欢查询条件今天多出一个来,明天又要干掉一个的做法,这样的改动如果不把where条件在前台拼装的话,改动量很大.我十分赞同Alan Cooper的说法,一个项目一旦进入实质的编码阶段如果再做改动代价是巨大的,他举了一个非常生动的例子,好莱坞拍大片,没有哪个编剧或者导演会傻到在 开始拍戏的时候才想到一个爆炸的镜头应该在闹市区,海里,还是天上拍摄,更少有人在闹市区拍到一半改变主意改成到天上爆炸的,因为他们知道这样的代价是惨 重的.页面上需要几个查询条件这很难确定吗?不是吧?这个东西对于一个特定的项目有必要变来变去的吗?不是的吧?从我的角度看,我们系统80%的页面的查 询条件都是顾问和RD的杰作,没有哪个用户会喜欢我们现在给他安排的查询条件,不信你自己去用一下好了,堆砌了大量没用的垃圾查询条件,最重要的查询条件 要么没有提供,要么隐藏在大量的垃圾查询条件之中,众里寻它千百度,可它死也找不到.
所以我的看法是,快速开发的根本在于编码之前的需求确定,在能够确切地了解自己作出来的东西应该是什么样子之前最好不要动手编码,很少有盖楼的在大楼盖起 来才恍然大悟,哦,不好意思,我原来想要的不是这个样子的......对于查询条件这样的变动,如果可能完全可以在需求阶段搞定,而对于业务逻辑的变化, 只需要修改Facade.在动手之前界面是什么样子,有多少查询条件这些是必然应该订死的,在编码阶段业务逻辑可以进行必要的迭代,界面也可以微调,查询 条件就大可不必修改了吧?
说到编码阶段的开发速度的提高,也绝不是少拷贝一个函数能够解决的.试想一下拷贝三次函数的定义l占我们开发总时间的多少那?我想我们是不是把这个时间过 于放大了?当然我很讨厌把函数拷来拷去的做法,但我始终觉得这样或许有它的好处,至少在感觉上偶们是在作分层设计吧,或许哪一天偶灵光一现,说不定就领悟 到了分层的妙处,如果彻底退回到代码和页面文件混杂在一起的做法,我想我再也没机会领悟分层的好处了,人是有惰性的,对于可做可不做的事情,往往采取不做 的做法,况且跟自己没有关系的事情.现在之所以还会去关注一下分层啥的实际,是觉得自己做的东西号称采用了分层设计,真不知道回到代码和页面混杂的写法, 我还有没有动力去看这些东西,不要笑我懒,你也好不到哪里去,哈哈.
我觉得开发最多的时间用在了界面设计,找一些公用方法以及编译上.
1.界面设计的加快有待于采用xhtml和Css的标准化开发,实现内容和表现的分离以及一些常用控件的组件化.
2.公用方法,其实这很好解决,每个模块通过接口暴露需要暴露的方法,需要的人们去接口中找就好了,这不就是接口的作用吗?有人说我要把所有的方法放到一起,好找!我觉得这是很好理解的一件事情啊,数据库为什么要建索引?分散放到各个模块里有什么不好?
3.其实每个人只要包含自己的页面就可以了,大可不必编别人的页面,这样编译的速度快多了,并且不会经常出现dll被占用不能替换的问题,所以这个问题也好解决.
老人们讨论得热火朝天,我没什么经验,也没有成熟的观点,还是在属于自己的领地里谈自己的看法吧,哈哈.
我觉得要讨论快速开发,首先要弄清楚瓶颈在那里,能大幅度提高桶容量的是最短的木板.去掉Wrapper类除了可以少拷贝一次函数的定义,彻底放弃了分布 式部署外,还会有多大的效率提升那?正如以前我总是抱怨增加了Wrapper类除了多拷贝了一次函数和增加了一个看起来似乎永远不会用到的分布式外,没有 其他用处一样,其实这一进一出之间根本没多大出入.在把接口,Wrapper中的方法定义好以后,后来的业务逻辑和后台数据库的改变只会影响到 Facade和Manager这两个CS文件,修改的时候只需要修改这两个文件.按照我的想法,完全可以Manager里的SQL语句放到XML文件里, 这样修改的时候只需要修改XML文件,后台的代码根本不需要变动,Manager写一个统一的方法选取XML中的结点值,其实Palau早就支持这样的做 法了,不知道为什么大家宁可一行行地粘SQL也不愿意采用直接采用XML文件那?说到效率问题,从XML文件中读取一个字符串真的就比把N多的字符串拼在 一起快吗?
有一个事实很让我寒心,分层的意义是什么?不就是为了隔离设计,在变化来临的时候可以"拥抱变化"吗?就像典型的Internet网络传输的分层设计,换 用不同类型的网卡和网线,传输层根本不需要做什么改动一样.当然Martin Flower他老人家也承认企业软件比通信软件有更多的变化,可是这不能成为放弃的理由吧.
我觉得现在的项目不能快速结案,绝不是因为多拷了几个函数定义造成的!
我总是不喜欢查询条件今天多出一个来,明天又要干掉一个的做法,这样的改动如果不把where条件在前台拼装的话,改动量很大.我十分赞同Alan Cooper的说法,一个项目一旦进入实质的编码阶段如果再做改动代价是巨大的,他举了一个非常生动的例子,好莱坞拍大片,没有哪个编剧或者导演会傻到在 开始拍戏的时候才想到一个爆炸的镜头应该在闹市区,海里,还是天上拍摄,更少有人在闹市区拍到一半改变主意改成到天上爆炸的,因为他们知道这样的代价是惨 重的.页面上需要几个查询条件这很难确定吗?不是吧?这个东西对于一个特定的项目有必要变来变去的吗?不是的吧?从我的角度看,我们系统80%的页面的查 询条件都是顾问和RD的杰作,没有哪个用户会喜欢我们现在给他安排的查询条件,不信你自己去用一下好了,堆砌了大量没用的垃圾查询条件,最重要的查询条件 要么没有提供,要么隐藏在大量的垃圾查询条件之中,众里寻它千百度,可它死也找不到.
所以我的看法是,快速开发的根本在于编码之前的需求确定,在能够确切地了解自己作出来的东西应该是什么样子之前最好不要动手编码,很少有盖楼的在大楼盖起 来才恍然大悟,哦,不好意思,我原来想要的不是这个样子的......对于查询条件这样的变动,如果可能完全可以在需求阶段搞定,而对于业务逻辑的变化, 只需要修改Facade.在动手之前界面是什么样子,有多少查询条件这些是必然应该订死的,在编码阶段业务逻辑可以进行必要的迭代,界面也可以微调,查询 条件就大可不必修改了吧?
说到编码阶段的开发速度的提高,也绝不是少拷贝一个函数能够解决的.试想一下拷贝三次函数的定义l占我们开发总时间的多少那?我想我们是不是把这个时间过 于放大了?当然我很讨厌把函数拷来拷去的做法,但我始终觉得这样或许有它的好处,至少在感觉上偶们是在作分层设计吧,或许哪一天偶灵光一现,说不定就领悟 到了分层的妙处,如果彻底退回到代码和页面文件混杂在一起的做法,我想我再也没机会领悟分层的好处了,人是有惰性的,对于可做可不做的事情,往往采取不做 的做法,况且跟自己没有关系的事情.现在之所以还会去关注一下分层啥的实际,是觉得自己做的东西号称采用了分层设计,真不知道回到代码和页面混杂的写法, 我还有没有动力去看这些东西,不要笑我懒,你也好不到哪里去,哈哈.
我觉得开发最多的时间用在了界面设计,找一些公用方法以及编译上.
1.界面设计的加快有待于采用xhtml和Css的标准化开发,实现内容和表现的分离以及一些常用控件的组件化.
2.公用方法,其实这很好解决,每个模块通过接口暴露需要暴露的方法,需要的人们去接口中找就好了,这不就是接口的作用吗?有人说我要把所有的方法放到一起,好找!我觉得这是很好理解的一件事情啊,数据库为什么要建索引?分散放到各个模块里有什么不好?
3.其实每个人只要包含自己的页面就可以了,大可不必编别人的页面,这样编译的速度快多了,并且不会经常出现dll被占用不能替换的问题,所以这个问题也好解决.
