我的跨国公司如何从一个开发平台过渡到另一个平台?


10

我在一家大型国际公司的IT部门工作。我们正在为业务开发不同的Intranet应用程序(投诉,回扣,服务台等)。现在,我们决定从PHP平台迁移到.NET(与MS CRM Dynamics,Exchange和MS Office集成是许多原因之一)。由于企业在当前的PHP平台上使用大约20种不同的应用程序,因此我们将不得不提出最佳方法将它们全部迁移到新平台上。我不想详细介绍如何转换代码等,因为在进行迁移时,我们希望改进所有这些应用程序。

因此,我们提出了两种移动这些应用程序的主要方法:

  1. 仅支持一个平台。什么意思 创建主页,然后将所有应用原样迁移到.NET(在这样做的同时不会对其进行改进)。在新的Intranet运行之后,我们将开始重建迁移的应用程序并对其进行改进。这样可以节省我们在.NET中开发Intranet的时间,而不必支持PHP平台。

  2. 同时支持这两种平台。这意味着仅构建一个主页和1或2个新应用程序(在我们的PHP平台上不存在)。向用户提供这些功能,但不取消PHP平台(我们将合并菜单和链接,以使用户可以更轻松地在PHP页面上的应用程序和新页面之间切换)。然后,我们将在改进它们的同时开始重写PHP应用程序。

现在,我不确定会有什么更好的选择,一方面(选项1),我们可能会通过不强迫用户同时使用两个不同的平台来使用户更轻松。尽管他们认为新平台不会带来任何改善,但除了看起来更好之外,新平台上的应用程序功能在一段时间内将保持相同。另外,我认为我们会增加自己的工作量(IT部门),因为本质上我们会为每个应用程序编写两次。
另一方面,由于两个平台的外观不同,选项二(2)的用户体验较差,但是随着新应用程序的不断发展,他们将意识到新平台的优势。

你们有没有遇到过类似的事情?您会选择什么?或者,也许还有其他更好的方法可以代替我介绍的那些方法?我想知道您的想法以及如何处理。


1
#2不是迈向#1的一步吗?
泰成

不,这是两件事。在1中,我们将先迁移整个Intranet,然后再允许用户使用它,然后我们将着手改进应用程序。在2中,我们将迁移Intranet的重要部分,允许用户使用它,然后开始迁移其他应用程序,并在迁移过程中对其进行改进...

@greengit:阅读主题,与其他关键业务应用程序集成是原因之一。我的问题不是关于“为什么要迁移”,而是“如何迁移”。
2011年

我阅读了主题并有相同的问题。我非常怀疑该项目是否合理。您能告诉我们公司的名称,以便我们做空吗?;)
mcottle

哈哈,说实话,我并不在乎成本,因为我只是公司的IT实习生。我只是想问问我自己的知识...显然,我的经理说出这笔费用足以使CEO
批准

Answers:


5

让我们考虑两种情况:

一次迁移

在迁移代码库时,客户将继续使用现有的应用程序。由于迁移将花费很短的时间,这意味着您将需要在旧代码库上拥有维护团队,以进行错误修复和功能开发。您在旧代码库中所做的每个更改都需要在新代码库中进行。只要不完成迁移,您最终将每行代码编写两次,这使得迁移花费的时间越长,成本就越高。因此,归结为:完全迁移的周转时间是多少?只要周转时间持续,您的开发成本就会飞涨。

逐项迁移

在这种情况下,您将可以更好地控制双重努力,但仍然会有很多额外费用。您的部署将涉及两个单独的平台,两次部署问题和所需的其他服务器资源。除非您有一个非常模块化的组织应用程序,否则您会发现在另一个平台上通常会存在一段代码,而不是您需要的代码,这会导致额外的移植和维护工作。只要不完成迁移,您的开发成本就会更高。同时,功能压力意味着您将需要很长时间才能完成迁移。

结论

根据个人经验,我可以告诉您两件事:

  • 切换编程语言很少会得到回报。从成本效益分析来看,从PHP切换到.NET不太可能盈利。所以我的主要建议是:不要。尝试解决现有代码库的问题。
  • 逐个片段是最好的方法,但是在应用程序模块级别上很难做到。您会发现,只要迁移未完全完成,就必须在体系结构的两侧开发和维护功能。优先考虑功能的优先级不是一个好主意,它可以基于客户最需要的东西,而又可以基于哪些因素来限制双重工作量(从而降低成本)。

您提出了非常有趣的观点。尽管是否切换平台不由我自己决定,我只会在9月底之前为公司工作(我和他们一起在一个单位工作)。从PHP切换到.NET可能是一个好主意,因为我们拥有的旧PHP框架将需要一些主要的工作,数据库,因此该公司目前使用的系统是OLD,并且是由不具备出色开发技能的人员创建的。 ..
Daniel Gruszczyk 2011年

我的问题也是:在旧平台上进行“更改冻结”是个好主意吗?我的意思是,冻结PHP平台上对现有系统的任何更改(错误修复除外),直到我们开始将给定的应用程序移至.NET为止。那是我经理的迁移计划的一部分……
Daniel Gruszczyk

如果这是一个不平凡的系统,那么更改冻结在实践中极不可能发生。如果某人确实需要一项功能,他们会将其升级到比您的经理更高的级别,并且您将不得不进行更改。此外,错误修正本身会占用大量团队资源。并始终牢记,旧系统已经进行了大量调整,而新设计可能会忘记所有这些小的单行修复程序,而这将需要重新发生,以便用户接受重新设计的产品。
Joeri Sebrechts

还有一点:如果要重建系统,那么现在有哪些安全措施可以确保更好的代码质量?由于平台和代码质量问题,我已经看到一个应用程序被重写了4次。
Joeri Sebrechts

2

出于财务原因,我工作过的大多数公司都采用了第二种方法,我可能会补充说。他们要获得第一名需要花费大量金钱,时间和风险。只要用户看到您的进度以及与他们的互动,他们通常就会理解#2。在这种贫乏而卑鄙的经济中,我怀疑有人会采用#1方法。


那正是我的想法。我的经理想继续执行#1,我觉得很难理解。

2

就最终用户而言,大爆炸方法很少具有建设性。我建议您不要这样做,老实说,考虑到相关应用程序的数量,我不敢相信任何人会认真考虑将其作为一种选择。

我倾向于选择第二种方法,并视情况进行返工。诚然,这可能比纸上方法要花更长的时间,但实际上,您采用方法一会给您带来巨大的业务风险,而且我真的不希望在第一天就接到支持电话在用户端只有一个小问题。

另外,如果绝大多数基于Web服务的应用程序已经用php编写,那么.Net专业知识又如何呢?

我认为,无论哪种方式,您的用户都将不得不经历变化,无论是大爆炸(提示大量支持电话)还是零零碎碎(增加熟悉度)。我倾向于认为您并没有真正确定从完全接近所有php到完全.net都需要做多少工作。


我想这比不支持两个独立的平台要复杂得多。两种方法都不是很好的方法...感谢您的宝贵时间!
2011年

1

首先,我同意Joeri所说的一切。

选项一确实是可怕的。如果您这样做并且不按照Joeri的描述继续提供支持,则可能会在客户看到的情况下将支持关闭几年。两年后,他们实际上进入了同一个站点,而在过去的几年中,他们逐渐认识并讨厌所有相同的问题。加上市场在此期间发生变化,使该应用程序过时且需要进行重大修改的风险。另外,如果您确实关闭了两年的支持,您认为所有服务请求将会如何?他们不会消失。至少您的一些用户会“无赖”并在(可能的)Access中开发关键任务系统,以填补正在重写的系统中的空白-然后您仍然最终支持两个平台...

选项2意味着您将长期支持这两种技术。该时间段将比您想象的要长,并且您最终可能会遇到一个永久性的零散的生态系统-即大量的PHP代码,与新的.NET代码混合重写是不经济的。

强烈反对提出建议的人。编写代码以将PHP应用程序与您建议的产品集成起来要比在.NET中重写所有内容然后将重写的代码与产品集成起来要便宜得多,请记住,如果您使用.NET,集成将不会神奇地发生。

还有一件事,将几行PHP代码放入COCOMO 2工具中,以了解完成重写需要多长时间和多少开发人员。


好点子。如果迁移与否取决于您,该怎么办。您会选择哪种方法?还是mybe我列出了另一种方法吗?如果您的经理不同意您的看法,您会尝试证明您的方法更好吗?
Daniel Gruszczyk 2011年

以更加分层的“面向服务”方式编写PHP应用程序。使用企业服务总线来缓冲PHP和Microsoft land之间的接口。关键是进行COCOMO估算,这应该吓到您的经理改写生活。
mcottle

1

您还有第三种选择:

将php代码迁移到Windows服务器和ISS(与计划在.NET上运行的同一代码)!

然后,您可以在.NET中添加新的应用程序(然后将一些较旧的应用程序缓慢地转换为.NET),同时为用户提供看起来像单个系统的外观。


PHP确实在IIS下运行
Bart
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.