中国软件业真的到了该反思的时候了
程序员文章站
2022-05-06 11:26:02
...
中国五千年文化造就了我们诸多的性格，其中之一就是好大喜功，这尤其反映在中国的软件产业。不错，我们确实拥有数量巨大的网民，拥有无与伦比的庞大市场与用户需求，但这并不足以让我们的步入世界领先行列。在巨大的市场优势面前常常让我们有些迷离，有些飘飘然，有些盲目地民族自豪感，喊出诸如“赶英超美”的口号。然而，客观地讲，我们现在却是差距巨大。
也许你觉得我这话有些崇洋媚外，但静下心来仔细分析我们自己设计的软件，我们注重了软件质量了吗？我们在如履薄冰地进行每一次设计了吗？我们的每一个系统都在编写高质量的代码了吗？也许每个项目的第一个版本我们做到了，但随着软件生命周期的延续，与软件需求的不断变更，我们真的越来越难以拍着胸口说，我做到了！这就是当今中国软件之殇：没有高质量的软件设计，哪来高质量的软件系统？
所以，作为中国软件业中的一员，你应该仔细反思了。下面这篇文章，一个真实的故事，也许可以给你许多的感悟：
2012年，我接到一个任务，对公司一个运行了十年之久的软件系统开展课题研究，使其能够由现有的省集中的运营模式，改为全国集中的运营模式。将原有的，每个省一台服务器的运营模式，改为将所有业务都集中于一台服务器进行运营，毫无疑问，这是一个性能问题，通过加入缓存、分布式处理、数据库分区、读写分离等技术，从而解决大并发访问与大数据量处理，问题就解决了。起初，我也是这样认为的，但我真正深入到这个软件系统的程序代码中时却发现，问题不是想象中那么简单。
虽然之前也有所耳闻，但我真正深入到代码中时，还是感到十分的震惊。整个项目中，一个类数百个方法，一个方法数千行代码的地方，比比皆是。当你游走于数百个方法，或者数千行代码中时，即使像我这样工作了十多年的老手，要读懂也是相当困难，更别说那些刚毕业的新同学。此时，我意识到，如果不改变现有的代码结构，这个系统真的无法承载任何的技术改造。
我造访了参与这个系统多年的老员工，那些“元老”们。他们告诉我，这个系统其实在最开初设计上还是很不错的。然而，经历是十年的维护，各种功能需求，加加减减，不断更新，版本升级上百次，问题就变得越来越大。随着人员的流动，一些代码变成了盲区，谁都不明白它的意思，同时谁都不敢去对它有任何修改，除非迫不得已。每个新员工加入，都不敢轻易修改原有任何代码，而是在原有代码的基础上不断添加代码。这样，随着功能的不断变更，新添的代码就想肿瘤一样不断膨胀，最后由数百行代码扩展成数千行代码，由数十个方法扩展成数百个方法，代码质量不断降低。
慢慢地，程序员越来越看不懂代码了，但他们又要完成自己手头的工作，因此开发工作变成了一种冒险。那么公司怎么能保证每次上线的新程序是正确的呢？那就是测试，投入巨大人力与时间的测试。由于程序越来越复杂，每次修改的测试成本都变得巨大。而这时，由于开发人员觉得，测试人员总数能测出问题来，所以自己只负责开发就可以了，所有的验证工作统统交给测试人员。毫无疑问，这个项目已经陷入了一阵难于自拔的恶性循环之中。维持现状已然疲于奔命，何谈任何技术改造？
然而，我认为这不是一个个案，而是一种普遍现象。大家想想，哪个软件公司没有运营数年的遗留系统？哪个系统不是遭遇频繁变更？在这些系统经历了数十次变更以后，谁还敢拍着胸脯说，我们的设计依然很清晰，我们的代码依然很优质，恐怕不能。
“就这样吧，好死不如赖活着！”也许大多数人都会这样想，然而却不包括我。我从业数十年就一直是一个救火队员，去拯救那些无法再运行下去的软件系统。我很少开发新的系统，总是在半途去接手一个老系统。这些系统起初代码都十分凌乱，维护十分困难。但是在我接手之日起，事情开始变得好转。我总是在不断改造它们，优化它们的代码，使它们慢慢变得易于阅读、容易维护、容易变更。慢慢地，我们的维护工作变得越来越轻松，我们开始喝着咖啡，听着音乐，享受编程生活。我采用的方法就叫“重构”。
重构不是高端大气上档次的华丽名词，也不是病入膏肓才拿出来唬人的终极杀招。它不是将原有系统改得面目全非，更不是拿着代码一阵瞎改的鲁莽之举。而是一种科学而稳健的持续改善。经过多年的工作实践，我深深的感到，这种方法是解决中国软件之殇的最有效方法，因为：
1.假如你在维护遗留系统，这个遗留系统本身的设计并不好，代码质量存在问题，那么你可以采用这种方法，持续而稳健地改造，最后将软件的维护纳入到一个良性的循环中来；
2.假如你是一个设计者，你在设计一个新系统，但你的设计能力不足够优秀，不知道怎样适应今后的变更，那么没有关系，思考今天的设计。因为有了重构，我们不用担心日后的变更。这样每个人都可以编写出高质量的程序代码；
3.假如你是一个遗留系统的维护者，你发现原有的程序不能适应新的需求，那么没有关系，通过重构先改造原有系统，以适应新的需求，再添加新的需求。这样做，你会发现你很容易设计出高质量的代码，使得新功能的加入不会降低原系统的质量。
当所有软件企业都做到了这些，那么中国软件的质量就开始提高，中国软件业才真正能够腾飞。为此，我将我多年的经验汇聚到《大话重构》这本书中，期望给大家更多的启迪！大家可以在当当、亚马逊、京东、china-pub等网上书店搜索，也可以在豆瓣、51CTO、IT168文库等网上试读。详见：http://product.dangdang.com/23449367.html
相关文档
遗留系统：IT攻城狮永远的痛
需求变更是罪恶之源吗？
系统重构是个什么玩意儿
我们应当改变我们的设计习惯
小步快跑是这样玩的（上）
小步快跑是这样玩的（下）
代码复用应该这样做（1）
代码复用应该这样做（2）
代码复用应该这样做（3）
做好代码复用不简单
软件可以这样功能扩展
过程扩展与放置钩子
特别说明：希望网友们在转载本文时，应当注明作者或出处，以示对作者的尊重，谢谢！
也许你觉得我这话有些崇洋媚外，但静下心来仔细分析我们自己设计的软件，我们注重了软件质量了吗？我们在如履薄冰地进行每一次设计了吗？我们的每一个系统都在编写高质量的代码了吗？也许每个项目的第一个版本我们做到了，但随着软件生命周期的延续，与软件需求的不断变更，我们真的越来越难以拍着胸口说，我做到了！这就是当今中国软件之殇：没有高质量的软件设计，哪来高质量的软件系统？
所以，作为中国软件业中的一员，你应该仔细反思了。下面这篇文章，一个真实的故事，也许可以给你许多的感悟：
2012年，我接到一个任务，对公司一个运行了十年之久的软件系统开展课题研究，使其能够由现有的省集中的运营模式，改为全国集中的运营模式。将原有的，每个省一台服务器的运营模式，改为将所有业务都集中于一台服务器进行运营，毫无疑问，这是一个性能问题，通过加入缓存、分布式处理、数据库分区、读写分离等技术，从而解决大并发访问与大数据量处理，问题就解决了。起初，我也是这样认为的，但我真正深入到这个软件系统的程序代码中时却发现，问题不是想象中那么简单。
虽然之前也有所耳闻，但我真正深入到代码中时，还是感到十分的震惊。整个项目中，一个类数百个方法，一个方法数千行代码的地方，比比皆是。当你游走于数百个方法，或者数千行代码中时，即使像我这样工作了十多年的老手，要读懂也是相当困难，更别说那些刚毕业的新同学。此时，我意识到，如果不改变现有的代码结构，这个系统真的无法承载任何的技术改造。
我造访了参与这个系统多年的老员工，那些“元老”们。他们告诉我，这个系统其实在最开初设计上还是很不错的。然而，经历是十年的维护，各种功能需求，加加减减，不断更新，版本升级上百次，问题就变得越来越大。随着人员的流动，一些代码变成了盲区，谁都不明白它的意思，同时谁都不敢去对它有任何修改，除非迫不得已。每个新员工加入，都不敢轻易修改原有任何代码，而是在原有代码的基础上不断添加代码。这样，随着功能的不断变更，新添的代码就想肿瘤一样不断膨胀，最后由数百行代码扩展成数千行代码，由数十个方法扩展成数百个方法，代码质量不断降低。
慢慢地，程序员越来越看不懂代码了，但他们又要完成自己手头的工作，因此开发工作变成了一种冒险。那么公司怎么能保证每次上线的新程序是正确的呢？那就是测试，投入巨大人力与时间的测试。由于程序越来越复杂，每次修改的测试成本都变得巨大。而这时，由于开发人员觉得，测试人员总数能测出问题来，所以自己只负责开发就可以了，所有的验证工作统统交给测试人员。毫无疑问，这个项目已经陷入了一阵难于自拔的恶性循环之中。维持现状已然疲于奔命，何谈任何技术改造？
然而，我认为这不是一个个案，而是一种普遍现象。大家想想，哪个软件公司没有运营数年的遗留系统？哪个系统不是遭遇频繁变更？在这些系统经历了数十次变更以后，谁还敢拍着胸脯说，我们的设计依然很清晰，我们的代码依然很优质，恐怕不能。
“就这样吧，好死不如赖活着！”也许大多数人都会这样想，然而却不包括我。我从业数十年就一直是一个救火队员，去拯救那些无法再运行下去的软件系统。我很少开发新的系统，总是在半途去接手一个老系统。这些系统起初代码都十分凌乱，维护十分困难。但是在我接手之日起，事情开始变得好转。我总是在不断改造它们，优化它们的代码，使它们慢慢变得易于阅读、容易维护、容易变更。慢慢地，我们的维护工作变得越来越轻松，我们开始喝着咖啡，听着音乐，享受编程生活。我采用的方法就叫“重构”。
重构不是高端大气上档次的华丽名词，也不是病入膏肓才拿出来唬人的终极杀招。它不是将原有系统改得面目全非，更不是拿着代码一阵瞎改的鲁莽之举。而是一种科学而稳健的持续改善。经过多年的工作实践，我深深的感到，这种方法是解决中国软件之殇的最有效方法，因为：
1.假如你在维护遗留系统，这个遗留系统本身的设计并不好，代码质量存在问题，那么你可以采用这种方法，持续而稳健地改造，最后将软件的维护纳入到一个良性的循环中来；
2.假如你是一个设计者，你在设计一个新系统，但你的设计能力不足够优秀，不知道怎样适应今后的变更，那么没有关系，思考今天的设计。因为有了重构，我们不用担心日后的变更。这样每个人都可以编写出高质量的程序代码；
3.假如你是一个遗留系统的维护者，你发现原有的程序不能适应新的需求，那么没有关系，通过重构先改造原有系统，以适应新的需求，再添加新的需求。这样做，你会发现你很容易设计出高质量的代码，使得新功能的加入不会降低原系统的质量。
当所有软件企业都做到了这些，那么中国软件的质量就开始提高，中国软件业才真正能够腾飞。为此，我将我多年的经验汇聚到《大话重构》这本书中，期望给大家更多的启迪！大家可以在当当、亚马逊、京东、china-pub等网上书店搜索，也可以在豆瓣、51CTO、IT168文库等网上试读。详见：http://product.dangdang.com/23449367.html
相关文档
遗留系统：IT攻城狮永远的痛
需求变更是罪恶之源吗？
系统重构是个什么玩意儿
我们应当改变我们的设计习惯
小步快跑是这样玩的（上）
小步快跑是这样玩的（下）
代码复用应该这样做（1）
代码复用应该这样做（2）
代码复用应该这样做（3）
做好代码复用不简单
软件可以这样功能扩展
过程扩展与放置钩子
特别说明：希望网友们在转载本文时，应当注明作者或出处，以示对作者的尊重，谢谢！