锁定老帖子 主题:中国软件业真的到了该反思的时候了
精华帖 (0) :: 良好帖 (0) :: 新手帖 (1) :: 隐藏帖 (13)
|
|
---|---|
作者 | 正文 |
发表时间:2014-04-07
最后修改:2014-04-09
也许你觉得我这话有些崇洋媚外,但静下心来仔细分析我们自己设计的软件,我们注重了软件质量了吗?我们在如履薄冰地进行每一次设计了吗?我们的每一个系统都在编写高质量的代码了吗?也许每个项目的第一个版本我们做到了,但随着软件生命周期的延续,与软件需求的不断变更,我们真的越来越难以拍着胸口说,我做到了!这就是当今中国软件之殇:没有高质量的软件设计,哪来高质量的软件系统? 所以,作为中国软件业中的一员,你应该仔细反思了。下面这篇文章,一个真实的故事,也许可以给你许多的感悟: 2012年,我接到一个任务,对公司一个运行了十年之久的软件系统开展课题研究,使其能够由现有的省集中的运营模式,改为全国集中的运营模式。将原有的,每个省一台服务器的运营模式,改为将所有业务都集中于一台服务器进行运营,毫无疑问,这是一个性能问题,通过加入缓存、分布式处理、数据库分区、读写分离等技术,从而解决大并发访问与大数据量处理,问题就解决了。起初,我也是这样认为的,但我真正深入到这个软件系统的程序代码中时却发现,问题不是想象中那么简单。 虽然之前也有所耳闻,但我真正深入到代码中时,还是感到十分的震惊。整个项目中,一个类数百个方法,一个方法数千行代码的地方,比比皆是。当你游走于数百个方法,或者数千行代码中时,即使像我这样工作了十多年的老手,要读懂也是相当困难,更别说那些刚毕业的新同学。此时,我意识到,如果不改变现有的代码结构,这个系统真的无法承载任何的技术改造。 我造访了参与这个系统多年的老员工,那些“元老”们。他们告诉我,这个系统其实在最开初设计上还是很不错的。然而,经历是十年的维护,各种功能需求,加加减减,不断更新,版本升级上百次,问题就变得越来越大。随着人员的流动,一些代码变成了盲区,谁都不明白它的意思,同时谁都不敢去对它有任何修改,除非迫不得已。每个新员工加入,都不敢轻易修改原有任何代码,而是在原有代码的基础上不断添加代码。这样,随着功能的不断变更,新添的代码就想肿瘤一样不断膨胀,最后由数百行代码扩展成数千行代码,由数十个方法扩展成数百个方法,代码质量不断降低。 慢慢地,程序员越来越看不懂代码了,但他们又要完成自己手头的工作,因此开发工作变成了一种冒险。那么公司怎么能保证每次上线的新程序是正确的呢?那就是测试,投入巨大人力与时间的测试。由于程序越来越复杂,每次修改的测试成本都变得巨大。而这时,由于开发人员觉得,测试人员总数能测出问题来,所以自己只负责开发就可以了,所有的验证工作统统交给测试人员。毫无疑问,这个项目已经陷入了一阵难于自拔的恶性循环之中。维持现状已然疲于奔命,何谈任何技术改造? 然而,我认为这不是一个个案,而是一种普遍现象。大家想想,哪个软件公司没有运营数年的遗留系统?哪个系统不是遭遇频繁变更?在这些系统经历了数十次变更以后,谁还敢拍着胸脯说,我们的设计依然很清晰,我们的代码依然很优质,恐怕不能。 “就这样吧,好死不如赖活着!”也许大多数人都会这样想,然而却不包括我。我从业数十年就一直是一个救火队员,去拯救那些无法再运行下去的软件系统。我很少开发新的系统,总是在半途去接手一个老系统。这些系统起初代码都十分凌乱,维护十分困难。但是在我接手之日起,事情开始变得好转。我总是在不断改造它们,优化它们的代码,使它们慢慢变得易于阅读、容易维护、容易变更。慢慢地,我们的维护工作变得越来越轻松,我们开始喝着咖啡,听着音乐,享受编程生活。我采用的方法就叫“重构”。 重构不是高端大气上档次的华丽名词,也不是病入膏肓才拿出来唬人的终极杀招。它不是将原有系统改得面目全非,更不是拿着代码一阵瞎改的鲁莽之举。而是一种科学而稳健的持续改善。经过多年的工作实践,我深深的感到,这种方法是解决中国软件之殇的最有效方法,因为: 1.假如你在维护遗留系统,这个遗留系统本身的设计并不好,代码质量存在问题,那么你可以采用这种方法,持续而稳健地改造,最后将软件的维护纳入到一个良性的循环中来; 2.假如你是一个设计者,你在设计一个新系统,但你的设计能力不足够优秀,不知道怎样适应今后的变更,那么没有关系,思考今天的设计。因为有了重构,我们不用担心日后的变更。这样每个人都可以编写出高质量的程序代码; 3.假如你是一个遗留系统的维护者,你发现原有的程序不能适应新的需求,那么没有关系,通过重构先改造原有系统,以适应新的需求,再添加新的需求。这样做,你会发现你很容易设计出高质量的代码,使得新功能的加入不会降低原系统的质量。 当所有软件企业都做到了这些,那么中国软件的质量就开始提高,中国软件业才真正能够腾飞。为此,我将我多年的经验汇聚到《大话重构》这本书中,期望给大家更多的启迪!大家可以在当当、亚马逊、京东、china-pub等网上书店搜索,也可以在豆瓣、51CTO、IT168文库等网上试读。 当当:http://product.dangdang.com/23449367.html 试读:http://wenku.it168.com/d_001416667.shtml 相关文档 遗留系统:IT攻城狮永远的痛 需求变更是罪恶之源吗? 系统重构是个什么玩意儿 我们应当改变我们的设计习惯 小步快跑是这样玩的(上) 小步快跑是这样玩的(下) 代码复用应该这样做(1) 代码复用应该这样做(2) 代码复用应该这样做(3) 做好代码复用不简单 软件可以这样功能扩展 过程扩展与放置钩子 特别说明:希望网友们在转载本文时,应当注明作者或出处,以示对作者的尊重,谢谢! 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2014-04-07
作者范钢。 4月17日发售,现在预售。。。
读到最后忽然明白了。。。 最则是打了广告,但是说的确实在理。 |
|
返回顶楼 | |
发表时间:2014-04-07
虽然有打广告的成分,但真的是我十分用心总结出来的东西,相信会给你带来帮助
|
|
返回顶楼 | |
发表时间:2014-04-07
每一个系统的初期都是为了满足初期的需求和场景,从开发设计的原则来看,如果过多的为未来不确定的因素做太多的接口扩展或者是功能方面的预留,又会进入过度设计的迷坑。只能说,系统在不断更新的过程中,接手的系统的人,就没有一开始把系统弄懂,而是机械的堆叠。
|
|
返回顶楼 | |
发表时间:2014-04-08
很早很多大师说过,做开发就是一个反复重构迭代的过程,谁也不敢说一次就设计的很优秀,所以大量的重构很有必要的
|
|
返回顶楼 | |
发表时间:2014-04-08
这广告做的
|
|
返回顶楼 | |
发表时间:2014-04-08
看过楼主之前的文章,应该都是楼主的经验所谈
|
|
返回顶楼 | |
发表时间:2014-04-08
可以换个说法推广.摘取一些书中的经典案例增加大家的购买兴趣啊.如果是好书我也会买的
|
|
返回顶楼 | |
发表时间:2014-04-08
最后修改:2014-04-08
Yaphis 写道 可以换个说法推广.摘取一些书中的经典案例增加大家的购买兴趣啊.如果是好书我也会买的
前面有将近2个月的博客都在谈重构,都是书中部分内容的摘录,可以查看这个专栏: http://www.iteye.com/blogs/subjects/howDoesRefactoringDo 后面还会发布一些 |
|
返回顶楼 | |
发表时间:2014-04-08
看起来是不错的总结
|
|
返回顶楼 | |