软件之路

中国五千年文化造就了我们诸多的性格，其中之一就是好大喜功，这尤其反映在中国的软件产业。不错，我们确实拥有数量巨大的网民，拥有无与伦比的庞大市场与用户需求，但这并不足以让我们的步入世界领先行列。在巨大的市场优势面前常常让我们有些迷离，有些飘飘然，有些盲目地民族自豪感，喊出诸如“赶英超美”的口号。然而，客观地讲，我们现在却是差距巨大。

也许你觉得我这话有些崇洋媚外，但静下心来仔细分析我们自己设计的软件，我们注重了软件质量了吗？我们在如履薄冰地进行每一次设计了吗？我们的每一个系统都在编写高质量的代码了吗？也许每个项目的第一个版本我们做到了，但随着软件生命周期的延续，与软件需求的不断变更，我们真的越来越难以拍着胸口说，我做到了！这就是当今中国软件之殇：没有高质量的软件设计，哪来高质量的软件系统？

所以，作为中国软件业中的一员，你应该仔细反思了。下面这篇文章，一个真实的故事，也许可以给你许多的感悟：

2012年，我接到一个任务，对公司一个运行了十年之久的软件系统开展课题研究，使其能够由现有的省集中的运营模式，改为全国集中的运营模式。将原有的，每个省一台服务器的运营模式，改为将所有业务都集中于一台服务器进行运营，毫无疑问，这是一个性能问题，通过加入缓存、分布式处理、数据库分区、读写分离等技术，从而解决大并发访问与大数据量处理，问题就解决了。起初，我也是这样认为的，但我真正深入到这个软件系统的程序代码中时却发现，问题不是想象中那么简单。

虽然之前也有所耳闻，但我真正深入到代码中时，还是感到十分的震惊。整个项目中，一个类数百个方法，一个方法数千行代码的地方，比比皆是。当你游走于数百个方法，或者数千行代码中时，即使像我这样工作了十多年的老手，要读懂也是相当困难，更别说那些刚毕业的新同学。此时，我意识到，如果不改变现有的代码结构，这个系统真的无法承载任何的技术改造。

我造访了参与这个系统多年的老员工，那些“元老”们。他们告诉我，这个系统其实在最开初设计上还是很不错的。然而，经历是十年的维护，各种功能需求，加加减减，不断更新，版本升级上百次，问题就变得越来越大。随着人员的流动，一些代码变成了盲区，谁都不明白它的意思，同时谁都不敢去对它有任何修改，除非迫不得已。每个新员工加入，都不敢轻易修改原有任何代码，而是在原有代码的基础上不断添加代码。这样，随着功能的不断变更，新添的代码就想肿瘤一样不断膨胀，最后由数百行代码扩展成数千行代码，由数十个方法扩展成数百个方法，代码质量不断降低。

慢慢地，程序员越来越看不懂代码了，但他们又要完成自己手头的工作，因此开发工作变成了一种冒险。那么公司怎么能保证每次上线的新程序是正确的呢？那就是测试，投入巨大人力与时间的测试。由于程序越来越复杂，每次修改的测试成本都变得巨大。而这时，由于开发人员觉得，测试人员总数能测出问题来，所以自己只负责开发就可以了，所有的验证工作统统交给测试人员。毫无疑问，这个项目已经陷入了一阵难于自拔的恶性循环之中。维持现状已然疲于奔命，何谈任何技术改造？

然而，我认为这不是一个个案，而是一种普遍现象。大家想想，哪个软件公司没有运营数年的遗留系统？哪个系统不是遭遇频繁变更？在这些系统经历了数十次变更以后，谁还敢拍着胸脯说，我们的设计依然很清晰，我们的代码依然很优质，恐怕不能。

“就这样吧，好死不如赖活着！”也许大多数人都会这样想，然而却不包括我。我从业数十年就一直是一个救火队员，去拯救那些无法再运行下去的软件系统。我很少开发新的系统，总是在半途去接手一个老系统。这些系统起初代码都十分凌乱，维护十分困难。但是在我接手之日起，事情开始变得好转。我总是在不断改造它们，优化它们的代码，使它们慢慢变得易于阅读、容易维护、容易变更。慢慢地，我们的维护工作变得越来越轻松，我们开始喝着咖啡，听着音乐，享受编程生活。我采用的方法就叫“重构”。

重构不是高端大气上档次的华丽名词，也不是病入膏肓才拿出来唬人的终极杀招。它不是将原有系统改得面目全非，更不是拿着代码一阵瞎改的鲁莽之举。而是一种科学而稳健的持续改善。经过多年的工作实践，我深深的感到，这种方法是解决中国软件之殇的最有效方法，因为：

1.假如你在维护遗留系统，这个遗留系统本身的设计并不好，代码质量存在问题，那么你可以采用这种方法，持续而稳健地改造，最后将软件的维护纳入到一个良性的循环中来；

2.假如你是一个设计者，你在设计一个新系统，但你的设计能力不足够优秀，不知道怎样适应今后的变更，那么没有关系，思考今天的设计。因为有了重构，我们不用担心日后的变更。这样每个人都可以编写出高质量的程序代码；

3.假如你是一个遗留系统的维护者，你发现原有的程序不能适应新的需求，那么没有关系，通过重构先改造原有系统，以适应新的需求，再添加新的需求。这样做，你会发现你很容易设计出高质量的代码，使得新功能的加入不会降低原系统的质量。

当所有软件企业都做到了这些，那么中国软件的质量就开始提高，中国软件业才真正能够腾飞。为此，我将我多年的经验汇聚到《大话重构》这本书中，期望给大家更多的启迪！大家可以在当当、亚马逊、京东、china-pub等网上书店搜索，也可以在豆瓣、51CTO、IT168文库等网上试读。
当当：http://product.dangdang.com/23449367.html
试读：http://wenku.it168.com/d_001416667.shtml

作者范钢。  4月17日发售，现在预售。。。
读到最后忽然明白了。。。
最则是打了广告，但是说的确实在理。    

《大话重构》这本书的最大特点就是，虽然重构这个话题有一些大师级的经典著作，但大师们都生活在太空里的，我们追随大师感觉都是飘在半空中落不到实地，也就是无法落实到工作中。这本书恰恰相反，它没有提出任何新的概念，全都是你耳熟能详的知识，却将他们铆合成了一个整体，将它们落地，形成切实可行的方法与方案，让大家真正在工作中用起来，写出高质量的代码，逐步改善遗留系统。尽管如此，依然需要大家重新审视自己的编程习惯，做出改变。这起初确实会有些痛苦，但最终会受益良多。    

可惜的是即使好书常有，也是知音难觅啊。以我的经验来估计，80%的开发人员没有看过那本经典版的《重构》，这也造成了双方在观念上不可逾越的鸿沟，如果想强推则只能落得孤芳自赏，重构这种东西普通程序员自己学学也就行了；真要大家一起来，只能让领导来推。    

fangang 写道

虽然有打广告的成分，但真的是我十分用心总结出来的东西，相信会给你带来帮助

感同身受啊，我现所在的项目也是经历了8年，这个系统前前后后最少上百个人参与过，每个人的编码风格、水平都参差不齐，时间长了，代码就成一坨坨了，修改一个小问题都要担心掉胆。曾看到一个类里面有5个方法，这5个方法名只有一字之差就是方法名字后面有数字1、2、3、4、5，而参数也一个比一个多，看到这样的代码真是蛋疼。

 中国的软件质量是有很大问题，一个是教育跟不上，大部分人在学校学习的都是基础，很少有学校讲软件质量，管理方面的，另一个中国这环境太浮躁太唯利是图，无论是否广告贴还是支持lz一下，写的很真实。

不知道在说什么．重构，就能解决所有的问题吗？一个架构的好坏，首先是全局的架构．    

个人认为，lz说的十年系统貌似臃肿难维护，但从时间和使用程度上看是成功的系统，能够支撑十年业务得省多少成本啊，如果我是管理着，我认为lz的评价是不客观公正的。再者，十年的系统我想需要的不是重构那么简单了，如果十年前的业务和现在的业务基本重合，重构是可以的，但是大多数情况基本发生了质的飞越，也许重做或者部分替换代价更小。

后半段说的对，不过重做和部分替换不也是重构的一部分吗，哈哈

前半段就略微想当然了，一个十年的系统，不代表成功，而是代表了没人敢去动它。在国内，电信、移动、各种银行的对外、对内系统，充斥着大量的bug，天天有人投诉，开发人员天天忙于救火。之前不是一个新闻说美国一个好像是医疗相关的系统，上亿行代码，几乎到了濒临奔溃的地步。。。。

截至到发帖时。。。旁边的一位兄弟，已经研究了一整天，一个好几年的系统，有一个多线程并发的bug。。。线程跑着跑着就消失了呀。。。。log也没有。。。    

软件的复杂度，是与软件需求的复杂度有密切关系的。起初的需求简单，我们不需要有十分复杂的架构。但随着软件的不断发展与扩充，需求变得越来越复杂，这时候我们就需要调整架构了。道理十分清楚，但做起来却不是那么简单，你是怎么做的呢？通过重构，逐步改善系统结构、解耦、调整、添加新技术，才能使系统重新获得新的架构，以适应新的需求，对不？

还有，评判一个架构好坏的标准是是否可以快速适应业务需求的变化。但你不是先知，你怎么知道日后需求会怎么变呢？这就意味着你的架构不可能总是适应需求的变化，不可能总是一成不变，你在日后总要调整。怎么调整？你需要重构！

随着软件越来越向着工业化发展，慢慢地变得越来越复杂，对一个机构甚至整个社会的作用也越来越巨大。这时候，要推倒重做一个系统将变得越来越困难。推倒重来行不通，但随着时间的流逝，越维护，问题也越多。推倒不行，保持现状也不行，软件企业陷入了进退两难的维谷境地。怎么办呢？很多事情不是非此即彼的两项选择，选择中间路线往往更加可行。

选择重构，不是去推倒一个系统，而是采用更加稳妥的方式逐步改进，从而解决问题，是系统从一种恶性循环中走出来，走向良性循环。重构是一种对系统的内部调整，部分替换是它的一个方式，但绝对不是重做。本书试读版中《大布局你伤不起》大家可以读一读。    

我大天朝软件行业差的根源在于政体，与你反思没有一分钱关系。有了程序公平的竞争，任何行业都会牛逼起来。用我大天朝的方式去管理美帝，不出10年，必定衰落。
至于高大上的重构方法，计算机教学时就应该掌握，而最系统快捷的方式就是搞明白计算机语言为什么这么进化。哪里需要这种给出零零碎碎的“方法”的高大上的重构书。就像MF的那本《重构》，比起BS的《演化》来那是远远不如了。    

重构的本身并不仅仅是重构，还包含着大量其他因素，特别是政治因素。
企业软件系统为什么这么复杂，因为每次调整都会带来权利重新分配。重构、技术债务、技术选择等等同样带来大量纯技术之外的东西。
我觉得一个企业系统要重构，最麻烦的不是技术，而是政治圈的变化。一旦涉及到这个，屁股决定脑袋，捍卫既得利益是第一想法。
如何能够平衡处理这些方方面面，才是最麻烦的。    

总觉得 重构 这个翻译不好 总是被人误解为重新设计。
但其实意思是 在自动测试的基础上，代码的逐步修剪。