Làm cách nào để chuyển đổi đa quốc gia của tôi từ nền tảng phát triển này sang nền tảng khác?

Tôi đang làm việc trong bộ phận CNTT của một công ty lớn, quốc tế. Chúng tôi đang phát triển các ứng dụng Intranet khác nhau cho doanh nghiệp (Khiếu nại, Giảm giá, Bàn dịch vụ, v.v.). Bây giờ chúng tôi quyết định chuyển từ nền tảng PHP sang .NET (tích hợp với MS CRM Dynamics, Exchange và MS Office là một trong nhiều lý do). Vì có khoảng 20 ứng dụng khác nhau mà doanh nghiệp đang sử dụng trên nền tảng PHP hiện tại, chúng tôi sẽ phải đưa ra cách tốt nhất để chuyển tất cả chúng sang nền tảng mới. Tôi không muốn đi sâu vào chi tiết cách chuyển đổi mã, v.v., vì trong khi chúng tôi di chuyển, chúng tôi muốn cải thiện tất cả các ứng dụng này.

Vì vậy, chúng tôi đã đưa ra 2 cách chính để di chuyển các ứng dụng này:

1. Hỗ trợ chỉ một nền tảng. Nó có nghĩa là gì? Tạo trang chủ và di chuyển tất cả các ứng dụng theo nghĩa đen sang .NET (mà không cải thiện chúng trong khi chúng tôi làm điều đó). Sau khi mạng nội bộ mới hoạt động, chúng tôi sẽ bắt đầu xây dựng lại các ứng dụng đã di chuyển và cải thiện chúng. Điều đó sẽ giúp chúng tôi phát triển mạng nội bộ trong .NET trong khi phải hỗ trợ nền tảng PHP.

2. Hỗ trợ cả hai nền tảng một thời gian. Điều đó có nghĩa là chỉ xây dựng một trang chủ và 1 hoặc 2 ứng dụng mới (không tồn tại trên nền tảng PHP của chúng tôi). Cung cấp chúng cho người dùng nhưng không tắt nền tảng PHP (chúng tôi sẽ kết hợp các menu và liên kết để giúp người dùng dễ dàng di chuyển giữa các ứng dụng trên trang PHP và nền tảng mới). Sau đó, chúng tôi sẽ bắt đầu viết lại các ứng dụng PHP trong khi cải thiện chúng.

Bây giờ tôi không chắc điều gì sẽ tốt hơn, một mặt (tùy chọn 1) chúng tôi sẽ có khả năng giúp mọi người dùng dễ dàng hơn bằng cách không buộc họ sử dụng hai nền tảng khác nhau cùng một lúc. Mặc dù họ sẽ không thấy bất kỳ cải thiện nào về việc có nền tảng mới, ngoài mọi thứ trông đẹp hơn, chức năng của các ứng dụng trên nền tảng mới sẽ giống nhau trong một thời gian. Ngoài ra tôi nghĩ rằng chúng tôi sẽ thêm bản thân mình (IT dep) làm việc nhiều hơn vì thực tế chúng tôi sẽ viết mỗi ứng dụng hai lần.
Mặt khác, trong tùy chọn hai (2) người dùng sẽ có trải nghiệm tồi tệ hơn khi hai nền tảng trông khác nhau, nhưng họ sẽ nhận ra lợi ích của nền tảng mới khi các ứng dụng mới đang di chuyển.

Có ai trong số các bạn đã gặp một cái gì đó như thế? Bạn sẽ chọn những gì? Hoặc có thể có cách khác, thậm chí tốt hơn cho những người tôi đã trình bày? Tôi muốn biết bạn nghĩ gì và bạn sẽ tiếp cận điều đó như thế nào.

Hãy xem xét cả hai kịch bản:

Di chuyển mọi thứ cùng một lúc

Trong khi bạn đang di chuyển cơ sở mã của mình, khách hàng của bạn sẽ tiếp tục sử dụng các ứng dụng hiện có của bạn. Vì quá trình di chuyển sẽ mất một khoảng thời gian không hề nhỏ, điều này có nghĩa là bạn sẽ cần phải có một nhóm bảo trì trên cơ sở mã cũ, để sửa lỗi và phát triển tính năng. Mỗi thay đổi bạn thực hiện trong cơ sở mã cũ cần phải xảy ra trong cơ sở mã mới. Cuối cùng, bạn sẽ viết mỗi dòng mã gấp đôi khi quá trình di chuyển không được thực hiện, khiến cho việc di chuyển càng mất nhiều thời gian hơn. Vì vậy, tất cả sôi sục xuống: thời gian quay vòng cho việc di chuyển đầy đủ sẽ là gì? Chi phí phát triển của bạn sẽ tăng vọt trong thời gian quay vòng kéo dài.

Di chuyển từng mảnh

Trong kịch bản này, bạn sẽ kiểm soát tốt hơn nỗ lực gấp đôi, nhưng bạn vẫn sẽ có nhiều chi phí bổ sung. Việc triển khai của bạn sẽ liên quan đến hai nền tảng riêng biệt, với hai lần vấn đề triển khai và tài nguyên máy chủ bổ sung cần thiết. Trừ khi bạn có một ứng dụng được tổ chức rất mô-đun, bạn sẽ thấy rằng thường thì một đoạn mã có mặt trong nền tảng khác ngoài nền tảng bạn cần, gây ra thêm nỗ lực chuyển và bảo trì. Miễn là việc di chuyển không được thực hiện, chi phí phát triển của bạn sẽ cao hơn. Đồng thời, áp lực tính năng sẽ có nghĩa là bạn sẽ mất nhiều thời gian để hoàn thành việc di chuyển.

Phần kết luận

Từ kinh nghiệm cá nhân tôi có thể nói với bạn hai điều:

• Chuyển đổi ngôn ngữ lập trình hiếm khi trả hết. Từ một phân tích lợi ích chi phí, rất khó có khả năng chuyển sang .NET từ PHP. Vì vậy, lời khuyên chính của tôi là: không. Cố gắng giải quyết vấn đề của bạn với cơ sở mã hiện tại của bạn.
• Từng mảnh là cách tiếp cận tốt nhất, nhưng bạn sẽ gặp khó khăn khi thực hiện nó ở cấp độ của các mô-đun ứng dụng. Bạn sẽ thấy rằng bạn sẽ phải phát triển và duy trì các tính năng trên cả hai mặt của kiến ​​trúc miễn là việc di chuyển không được thực hiện đầy đủ. Có thể là một ý tưởng tốt để ưu tiên các tính năng không dựa trên những gì khách hàng cần nhất mà dựa trên những gì sẽ hạn chế số lượng nỗ lực gấp đôi (do đó giảm chi phí).

Vì lý do tài chính, hầu hết các công ty tôi đã làm việc đều đi theo cách tiếp cận thứ hai, đúng ra tôi có thể thêm vào. Phải mất rất nhiều tiền, thời gian và rủi ro để họ đạt được # 1. Người dùng hầu hết sẽ hiểu # 2 miễn là họ thấy tiến trình và sự tương tác của bạn với họ. Trong nền kinh tế nạc và trung bình này, tôi nghi ngờ bất kỳ ai cũng sẽ áp dụng phương pháp số 1.

Cách tiếp cận Big bang hiếm khi mang tính xây dựng khi có liên quan đến người dùng cuối. Tôi khuyên bạn nên chống lại điều đó và thành thật mà nói tôi không thể tin bất cứ ai nghiêm túc coi đó là một lựa chọn với số lượng ứng dụng liên quan.

Tôi có khuynh hướng đi với tùy chọn hai và xử lý các công việc lại theo từng trường hợp. Phải thừa nhận rằng việc này có thể mất nhiều thời gian hơn so với cách tiếp cận trên giấy nhưng thực tế, bạn đang mở ra một rủi ro kinh doanh đáng kể bằng cách tiếp cận một và tôi thực sự không muốn có mặt cho các cuộc gọi hỗ trợ vào ngày đầu tiên nếu có chỉ một vấn đề nhỏ ở cuối người dùng.

Ngoài ra, nếu phần lớn các ứng dụng dựa trên dịch vụ web của bạn đã được viết bằng php, thì chuyên môn .Net có sẵn như thế nào?

Tôi nghĩ dù bằng cách nào thì người dùng của bạn sẽ phải trải nghiệm sự thay đổi, hoặc là một vụ nổ lớn (đưa ra nhiều cuộc gọi hỗ trợ) hoặc từng phần (tăng sự quen thuộc). Tôi có xu hướng nghĩ rằng bạn chưa thực sự định cỡ chính xác bao nhiêu công việc sẽ phải hoàn thành để đi từ gần hoàn toàn tất cả php sang hoàn toàn .Net.

Đầu tiên, tôi đồng ý với tất cả những gì Joeri nói.

Lựa chọn một là thực sự khủng khiếp. Nếu bạn làm điều này và không tiếp tục hỗ trợ như Joeri mô tả, bạn sẽ tắt hỗ trợ trong một vài năm theo như khách hàng của bạn thấy. Sau hai năm, họ có được cùng một trang một cách hiệu quả với tất cả các vấn đề tương tự mà họ đã biết và ghét trong vài năm qua. Cộng với rủi ro thị trường đã thay đổi tạm thời và khiến ứng dụng trở nên lỗi thời & cần một cuộc cải tổ lớn. Ngoài ra, nếu bạn ngừng hỗ trợ trong hai năm, bạn nghĩ điều gì sẽ xảy ra với tất cả các yêu cầu dịch vụ? Họ sẽ không biến mất. Ít nhất một số người dùng của bạn sẽ "lừa đảo" và phát triển các hệ thống quan trọng trong nhiệm vụ (có thể) Truy cập để cắm các khoảng trống trong các hệ thống bạn đang viết lại - sau đó bạn vẫn kết thúc hỗ trợ hai nền tảng ...

Tùy chọn hai có nghĩa là bạn sẽ hỗ trợ cả hai công nghệ trong một khoảng thời gian dài. Khoảng thời gian này sẽ dài hơn bạn nghĩ và bạn có thể kết thúc với một hệ sinh thái bị phân mảnh vĩnh viễn - tức là một lượng đáng kể mã PHP không kinh tế để viết lại trộn lẫn với mã .NET mới hơn.

Đẩy lùi mạnh mẽ chống lại bất cứ ai đang đề nghị này. Viết mã để tích hợp các ứng dụng PHP với các sản phẩm bạn đề xuất sẽ rẻ hơn nhiều so với viết lại mọi thứ trong .NET, sau đó tích hợp mã viết lại với các sản phẩm, đừng quên, việc tích hợp sẽ không xảy ra một cách kỳ diệu nếu bạn sử dụng .NET .

Một điều nữa, hãy lấy số dòng mã PHP và đưa nó vào một công cụ COCOMO 2 để có ý tưởng về việc bạn sẽ cần bao nhiêu nhà phát triển để hoàn thành việc viết lại.

Bạn có một lựa chọn thứ ba: -

Di chuyển mã php sang máy chủ windows và ISS (giống như bạn dự định chạy .NET trên!)

Sau đó, bạn có thể thêm các ứng dụng mới trong .NET (và từ từ chuyển đổi một số ứng dụng cũ sang .NET) trong khi trình bày cho người dùng của bạn một giao diện giống như một hệ thống.