大连自动泊车软件开发维护人员的工作就是为了解决问题，其中也包括了“历史遗留问题”。是否要展开重构，取决于是否有好的解决方案。什么是好的解决方案，以及谁可以带来好的解决方案，我们在前面的章节中已经多次谈到。

      我们说，要解决问题，就必须寻找一个有着成功记录的主刀医生，要允许这个主刀医生听取团队意见并独立地制定方案。如果有好的解决方案，还有什么理由不尽快实现它呢？

      我希望承担着经营风险的人去聆听一些正确的声音。实际上，大多数工作在一线的大连自动泊车软件开发维护人员都会感觉到“历史遗留问题”所带来的高昂成本！他们在糟糕的程序结构下工作，重复实现着各种妥协的方案，不断添加更多的“历史遗留问题”。简单的问题被无限地复杂化，各种错误层出不穷。

      如果真的决定重构，那么应该在故事讲清楚后再开始重构。

      这是我对于大连保险公司早会管理软件最根本的思路。这个思路非常有效，胜过一切工具、会议以及投入的资源。

      有人也许会说，现实没有这么理想。你看，没有代码注释，没有详细设计文档，没有当初的作者，怎么来阅读并理解现有的软件系统？说得没错，理解这样的软件系统是困难的。但是，不尝试去理解是彻头彻尾的错误。

      有一个办法（准确地说，有一种工作的方式），可以帮助你加快对现有软件系统的理解速度，那就是讲故事。

      致远服软认为：http://www.soft8.com.cn/从现有软件系统中提炼故事是一个反向工程。我感到奇怪的是，很少见到有系统地论述这类反向工程的论著。很多软件维护人员都在本能地做着这件事情，即便这件事情每天都在发生。

      经验告诉我，看似复杂的代码（几百行甚至上千行）讲述的故事情节其实都很简单。复杂的故事不是这么讲述的。

      复杂的故事往往由大量短小精炼的类以一种复杂的关系组合而成。这些类和关系来自联想丰富的隐喻。大多数臃肿的代码块在挤去水分后，往往只剩下干瘪的一小坨。

      要对现有的大连自动泊车软件开发维护系统进行重构，你需要一些业务分析人员的帮助，另外，把故事记录下来，整理清楚——仅此而已。

      场景故事点评：

      在本章的场景故事中，基本上没有碰到非技术性妥协带来的问题。这归功于孔如之的简单化思想。孔如之曾经有过动摇，例如，让于伦负责TFC项目的架构设计；如果是这样，结果将完全不同。