.NET Framework - Khi nào cần nâng cấp?

Question

Tôi đang phải đối mặt với thách thức dẫn đầu hai nhóm phát triển .NET riêng biệt (hiện tại) với các chiến lược phát triển khác nhau. Một nhóm đang phát triển trên .NET Framework 2.0 (có thể một vài ứng dụng trên 3.5). Nhóm khác ngay lập tức áp dụng bất kỳ khung công tác mới nào xuất hiện và bắt đầu mã hóa bất kỳ ứng dụng mới nào với nó (chúng đang chạy các ứng dụng 2.0-4.0). Đối với nhóm cuối cùng này, các ứng dụng được viết trong phiên bản cũ hơn khung mới nhất không được nâng cấp.

Trường học hiện tại của tư tưởng khi nói đến một công ty phát triển các ứng dụng web khi nào áp dụng một khung công tác mới và liệu có nên di chuyển các ứng dụng được xây dựng trên các phiên bản trước sang khung mới nhất hay không? Nhiều năm trước, ý nghĩ là chờ đợi cho đến khi công nghệ trở thành dòng chính - nhưng điều đó dường như không áp dụng nhiều với .NET.

Answer 1

(Sau đây là ý kiến ​​cá nhân của tôi, dựa trên 1 1/2 aprox. Năm kinh nghiệm với .NET trong môi trường doanh nghiệp như vậy. Ý kiến ​​khác có thể chắc chắn khác với tôi.)

Có lẽ điều quan trọng nhất để xem xét các phiên bản .NET framework mà khách hàng của họ đã cài đặt trên máy của họ.

Ví dụ: ứng dụng khách chính của chúng tôi tại nơi làm việc đã cài đặt .NET 3.5 và Silverlight 3 trên tất cả (> 5.000) máy. Mặc dù chúng tôi rất muốn phát triển dựa trên khung công tác phiên bản 4, nhưng đó không thực sự là một lựa chọn cho đến khi nhân viên CNTT của khách hàng cuối cùng quyết định rằng nó sẽ triển khai các khung công tác này. (Chúng tôi hy vọng rằng cuối cùng sẽ xảy ra vào khoảng giữa năm 2011. Nhưng khách hàng có nhiều máy, vì vậy mọi thứ luôn mất nhiều thời gian hơn bạn muốn. Chúng cũng vẫn chạy Windows Vista trên tất cả các máy tính để bàn. Nói cách khác: các khách hàng lớn là có lẽ chậm hơn để áp dụng các phiên bản .NET framework mới hơn. Đó là một điều khác cần lưu ý.)

Tuy nhiên, tôi cho rằng khách hàng của bạn nên có .NET 3.5 được cài đặt ngay bây giờ. .NET 2 chậm là một điều của quá khứ, và thậm chí bạn có thể ngừng hỗ trợ .NET 1.1 trên các máy tính để bàn.

Answer 2

Cách tôi điều hành nhóm phát triển của mình là làm những gì tốt nhất cho dự án riêng lẻ trong khi vẫn ghi nhớ nhu cầu của nhóm VÀ khách hàng mà chúng tôi đang hỗ trợ.

Thông thường, nâng cấp cung cấp các tính năng mới và giúp viết mã dễ dàng hơn/nhanh hơn để đạt được những gì khách hàng có thể muốn. Tuy nhiên, có một chi phí rõ ràng với việc nâng cấp - đôi khi đào tạo mới là cần thiết và đôi khi có vấn đề với khả năng tương thích ngược (đặc biệt là đối với bất kỳ ứng dụng không tầm thường nào). Tất nhiên, tất cả điều này đều tốn tiền.

Phần lớn, tôi cố gắng giữ cho nhóm của mình luôn vượt trội vì chúng tôi đã học được (thông qua trải nghiệm) rằng việc duy trì các phiên bản khác nhau của khung công tác có thể tạo ra nhiều sự nhầm lẫn và cuối cùng chi phí như chỉ thực hiện nâng cấp một lần. Với điều này đã nói, có một vài khách hàng mà chúng tôi có mà cụ thể không muốn chúng tôi nâng cấp. Đó là những trường hợp đặc biệt, tất nhiên, nhưng chúng tôi quản lý những trường hợp cần thiết.

Về cơ bản, để tổng hợp câu trả lời - hãy quyết định điều gì là quan trọng nhất đối với bạn. Các tính năng mới? Tiết kiệm chi phí (mà bạn cần phải suy nghĩ về nhiều chi phí - phát triển và chi phí của khách hàng)? Duy trì? Ủng hộ? Một khi bạn đã quyết định những điều đó và bạn đã nhận được ý kiến ​​từ các nhóm phát triển của mình, câu trả lời sẽ khá rõ ràng.

Answer 3

Chúng tôi có cửa hàng hai người. Nếu nó tùy thuộc vào tôi, chúng tôi sẽ nâng cấp ngay khi có phiên bản .NET và Visual Studio mới. Đối tác của tôi thận trọng hơn và muốn chờ ít nhất 6 tháng để xem liệu có bất kỳ vấn đề nào đã biết xảy ra hay không.

Dù bằng cách nào, tôi nghĩ tốt nhất là nên cập nhật một cách hợp lý một cách nhanh chóng và cách tiếp cận của đối tác của tôi, trong khi bực bội với tôi, có ý nghĩa, vì vậy tôi theo dõi cô ấy. Mối quan tâm lớn nhất mà tôi có là số phiên bản của Visual Studio chúng ta cần phải giữ lại để hỗ trợ các ứng dụng cũ hơn. Chúng tôi vẫn có VB6 (và một FoxPro cho DOS) ứng dụng bởi vì người tiền nhiệm của chúng tôi không bao giờ muốn nâng cấp. Chúng tôi sống trong sợ rằng một sửa đổi sẽ cần phải được thực hiện cho một trong những ứng dụng đó. nó thường kết thúc bằng cách viết lại vì mã cũ chỉ là xấu (hoặc có thể chúng ta không đọc được mã cũ).

Tôi nghĩ rằng rất thông minh để nâng cấp các chương trình và codebase một cách hợp lý một cách nhanh chóng khi một bộ công cụ mới xuất hiện. Thông thường, các công cụ di chuyển hoạt động tốt hơn với các chuyển đổi mới tương đối mới, trái ngược với các chuyển đổi từ rất cũ đến mới. Nó chỉ làm cho cuộc sống dễ dàng hơn.