ACM通信
快速系统转换的艺术
从头构建一个软件系统是教授和理解软件工程的基本方法。确定用例，设计体系结构和模式，然后实现和部署软件。用户上。这种绿地开发可以是令人振奋的创造机会。升级现有系统是第二种更常见的开发类型，因为对于任何给定的系统，只有一个初始版本，但有许多后续版本。虽然升级主要关注增量改进，但这是一个更复杂的情况，因为升级是中断和功能倒退的主要风险，而基线情况在初始发布时没有其他任何东西。
但如果有一个预先的操作系统呢?确切地说，是一个被取代的人。
系统转换代表了第三种截然不同的开发类型。项目范围现在包括了初始软件发布的所有工作，以及一组全新的复杂性。先前的系统经常陷入一个向下的螺旋——可能存在技术限制，使升级变得困难，这反过来会削弱组织改进系统的意愿，进而降低系统性能和可行性。但是，先前的系统必须保持足够长的时间，以便将功能转换并支持数据转换到新平台。这可能会成为引发焦虑的软件“与时间赛跑”。作为生活模仿艺术的一个例子，1994年的动作片速度与基努·里维斯的合作提供了一些令人惊讶的深刻教训，以及如何应对这种情况。
第一课:公交车不能减速
在电影中，一辆公共汽车被安装了炸弹，速度不能低于每小时50英里，否则会有可怕的后果。从软件的角度来看，如果一个现有的系统被高度利用，仍然运行关键功能，但没有得到很好的维护，它可能会有这样的感觉。可能有多个因素都在拖现有系统的后腿:过时的、不可伸缩的体系结构、过时的代码库，甚至可能缺乏支持上述项目的开发人员。忽略当前的系统只会让问题变得更糟。
第二课:需要第二辆巴士
为了保存初始总线，必须获得第二个总线。在软件世界中，“第二总线”代表新系统和创建该系统的开发团队。这既可以作为一个具有两项主要职责的团队来管理(支持旧系统，构建新系统)，也可以作为两个团队来管理，但有一点是明确的:实际上工作量是原来的两倍。系统转换开发的一个主要错误是只为“新”开发编制预算。
第三课:第二辆公共汽车加速赶上第一辆公共汽车
实现功能对等是系统转换中最困难的方面之一，特别是当第一辆公共汽车有100英里的领先时。“追赶系统”在时间和预算上都需要足够长的跑道，而之前的系统可能仍在同时继续进化，而不是一个静态目标，这一事实使其变得复杂。即使是最善意的项目也会在这一点上出错。这种类型的开发可能需要多个财政季度或数年，最大的问题之一是执行期望管理。
第四课:乘客得救了
在电影中，乘客们以戏剧性的方式获救，任何经历过大型系统转换的人都会认识到这几乎就是它的感觉。为了营救乘客，两辆巴士不仅要高速行驶，而且要近距离行驶，这再次强调了功能对等的重要性。让第二辆车以每小时50英里的速度行驶，但距离5英里，并在后退，这并没有帮助。
此外，还需要软件来协助转换——特别是大规模数据迁移——这是一门特殊的艺术。这样的软件仍然需要遵循软件工程的最佳实践，但是还需要快速(因为转换窗口总是处于时间紧张的状态)、可解释(因为转换总是被要求准确地解释发生了什么)和可自动化(因为最好的转换总是经过大量实践)。
转换的管理是软件工程的一个重要方面，不适合胆小的人。这个过程代表了从旧到新的桥梁。
第5课:第一辆公共汽车退役了
在电影中，第一辆公共汽车在乘客获救后发生了壮观的爆炸。在现实生活中，这种动态结果通常是不可取的。根据合同或法规规定通知的关闭过程是重要的考虑因素，例如在必要的一段时间内保存现有系统状态，并可能使系统以只读状态在线。如果将系统状态保存为备份，建议确认备份实际上可以恢复。
结论
系统转换是一个困难的问题，并且将永远存在于软件世界中，因为今天的蓝天开发工作将成为明天的遗留代码。导致系统腐烂的原因有很多:框架或语言的技术过时是原因之一，但由于系统在最初发布时被积极部署，然后被闲置，许多具有合理当前架构的系统已经被繁荣和萧条的预算行为削弱。技术领导者必须积极地管理投资组合中的每个系统。这样做需要大量的工作，但另一种选择更糟糕。
Doug Meil是一名软件架构师Ontada．他还创立了克利夫兰大数据聚会在2010年。
没有发现记录