一个朋友移民到了澳洲,在那里的一个
软件
公司做了4
年,回来休假
的时候我们做了两
次交流,第一次2
小时,第二次
4
小时
。在
成都的夜色
下
狮子山边的一个烧烤店,
我们
就着
烧烤和
啤酒
,
谈到软件开发问题和方法,感觉获益匪浅。他
所在的
公司大约有200
多人,
公司主要
做银行理财软件,大约有10
年历史,并且占有澳洲这个领域市场份额的
50%
,他们的软件的历史大约也有
10
年了。说起来,一个
10
年的软件,如同一个老房子,如果不经常的做些修修补补,就会很快的烂下去
。
听起来他们也遇到了类似的问题
,
并且看起来还很严重。
给他印象最深的是他们的主执行文件有 80M
的
exe
(实在说,我难以想象怎么会这么大,因此疑问重重的确认了
3
次,但是他确定的给我说,就是这个大小),
并且也谈及了软件存在的主要问题
:
1.
软件
内有几千个
F
orm,都是控件摆上去,然后双击编写代码,连按钮名称和事件名称都不改,都是
Button1Click
之类的。
这意味着,要找到相应的事件代码,必须先打开Form
,从
Form
上点击得到对应的事件,而不能直接在代码中找到要修改的代码。
2. 访问数据库的方法也不集中,比如有的代码用
ADO
,有的用
BDE
,还有什么直接开表的
(
后面的这个没有太听明白
)
。
3. 有很多控件,比如
ReportBuilder
,
Formula One
之类的。甚至同样功能的控件都有几个,用于不同的地方。
他们无一例外的没有做任何封装。这意味着,同样的功能,需要掌握不同的知识。
4. 还需要做
Office
,
OutLook
等外部软件的接口。
5. 很多代码都不太看得懂,很多文件都有
1
万多行。有些是数库访问代码依赖于逻辑代码和
UI
代码(不知道怎么依赖的)
。大量的代码,给理解软件模块带来了很多的麻烦。
反正,最后的效果就是80M
的
EXE
文件
。
这个公司也开始意识到这个问题,逐步的开始改进,还请了一个很牛的家伙,付了不少的咨询费用,经过改造,可以让项目每一个月发一次版本(我确认了下,就是Scrum
方法,我们曾经就这个方面,邀请讲师来公司交流过);而有些老的代码都不想看,就逐步的自己编写一次,换掉整个模块,容易把控
件
理解。可是这样做的风险也不小,还不知道如何处理。如果不能良好的组织模块,建立接口,没有利用抽象和分解这些老的技术,必然
存在
问题
”
。
对此,我建议他可以试试重构技术,并且推荐了Martin Folwer
的《重构:改善既有代码的设计》的书籍给他。我的
建议如下:
1. 老的代码修改起来确实很有难度,但是可以一点点的去用质量更高的代码去蚕食目前不良的代码,哪怕一次就做一个函数,慢慢的做,也许需要几年的时间
,但是收效也是很明显的。
2. 确立标准。先做简单的,比如化曲为直,分解函数可以先做
,
复杂的放到后面。
3. 先捡软柿子捏。从一次不超过一个小时的重构开始,逐步的熟练和更加清楚原来的业务模式后,
再
把大问题分解
为
小问题,把其中不超过一小时的重构做了;反正超过一小时的尽量不做,直到大家都觉得有信心后,再动大的。千万要注意,问题存在不一定要马上解决,问题唯有分解到一个个的可执行的步骤,才能真
正
的去解决它。比如架构问题,数据库结构的问题,就是很难分解下去的问题,这样的问题,就一定要先放下,等到重构做的比较多,代码良性程度高的时候,自然就是时机渐渐成熟的时候,就可以动了。
4. 做好保护措施。比如采用
TDD
开发(测试驱动开发)模式;如果觉得
TDD
不习惯或者不好着手,那么至少要利用好版本管理工具,让代码可逆,以便在重构看起来不太可能成功的情况下,回溯到前一个版本。我就遇到这样的情况
:
以为是一个很小的,有价值的重构,但是做的过程中发现关联很多,耗时很多,并且有改错功能的危险,必须重新评估,于是利用版本管理工具回溯
,
重头再来。还好这样的情况我只遇到了一次。估计一个重构的规模大部分情况比较容易,有少数情况比想象的要复杂的多,因此必须保证,我们能够
“
回得来
”
。
5. 在重构时,反正功能都是不去动的,因此不会担心功能上不够,可以利用零星的时间,或者专门的时间去做。
由于实际做的时候,有这么多的决策点,因此我建议他先找到合适的团队,这个团队必须有足够的意愿
去
尝试
,或者可以通过沟通和培训达到这样的意愿,在过程中积累方法。
这个技术不容易衡量,同样的重构,重构条目少的可能花费更多的时间,
条目
多的反而花费时间不多,很多效果也存在于人心之内,
单纯
从文档上看是看不出来的
,因此意愿是第一位的。
只要一个团队获得成功,取得了过程中的经验和感受,随后就要容易多了。
奖励是可以
配套
考虑的
。
重构本身的成果不易衡量,很多时候是感受和经验,并且存在于人心内,因此奖励本身不能仅仅用来奖励结果,而是重在奖励意愿;凡是主动的承担,积极的沟通,摸索更好的模式,尝试更好的技术,并且让这些能够共享,用于支持其他项目组的重构的,都可以考虑奖励。奖励本身无法分出等级,因此是表明管理者重视技术对产品的支撑能力,表明在这个方面的积极态度,对大家的稳重的尝试给予肯定。故此,凡是不愿意做的,一段时间内,都可不必勉强。我也给他介绍了我们的情况,我们有两个组开始利用重构来改善代码,有3
个人(仅仅限于我听说过的)以前独立的做过几次重构,目前看来效果都还不错。他决定回去马上就去试试,并和我
Email
交流。
尽管程度不同,这个公司和我们有某些类似的地方,
尤其是代码的历史久远,问题众多,
因此方法也值得我们借鉴。
分享到:
相关推荐
1swust学校的ACM平台的雷同率统计小软件 2读文件 HashMap 3 集合排序 4 Swing 5 内部类 线程
述职报告雷同如何整改.doc
【问题描述】 在评判开放性试题时,有一种情况会被视为作弊,即“雷同卷”。假设判定雷同卷的标准是:相同长度的两个句子中,同一位置、完全一致的单词占到75%以上,即为雷同卷。那么请你设计程序,来筛选输入的字符...
述职报告雷同如何整改..doc
录入学生的信息,并且保存到一个磁盘文件。可以录入学生的平时成绩和考试成绩,并统计学生的总成绩(计算方法:总成绩=考试成绩*70%+平时成绩30%)。按照总成绩对学生进行排序,查询某个学生的成绩(按照学号、姓名...
c#编写文本论文相似度雷同检查工具源码.
开题报告样例注意不得雷同.doc
小学奥数所有题型归类绝无雷同.doc
浅述中国城市广场设计的雷同化现象.docx
MBA英语考试必须掌握的雷同词汇辨析.doc
初中语文语文论文对学生雷同化作文的解读
短线交易提示 雷同交易决策通达信指标公式源码.doc
操作系统复习答案题(如有雷同纯属巧合)题docx.docx
RBF例子程序如有雷同请管理员删掉-RBF.rar RBF程序,包括拟合、建模、预测。如果论坛上已有该程序,请管理员删掉~~
个人通讯录管理系统c文件在最后 个人通讯录管理系统C语言编写 获得优秀 老师表扬的 绝不雷同
MyBatis的一个主要的特点就是需要程序员自己编写sql,那么如果表太多的话,难免会很麻烦,所以mybatis官方提供了一个逆向工程,可以针对单表自动生成mybatis执行所需要的代码(包括mapper.xml、mapper.java、po..)...
地方产业发展战略趋同问题的博弈分析,孙德斌 ,,所谓地方产业发展战略趋同,主要是指地区之间在主导产业的选择、产业组织规模和技术水平的确定以及产品结构安排等方面的雷同现象
Beginning iPhone Development with Swift 5 Exploring the iOS SDK, Fifth Edition PDF & EPUB