Bạn sẽ thiết kế lại hoàn toàn theo .Net?

Một ứng dụng rất rộng bắt đầu như một hệ thống dựa trên Access (để lưu trữ cơ sở dữ liệu). Các hình thức được viết bằng VB5 và / hoặc VB6. Khi .Net trở thành một vật cố định trong cộng đồng phát triển, một số mô-đun đã được viết lại. Điều này có vẻ rất khó xử và có khả năng tốn kém chỉ để duy trì vì các công nghệ chéo và công việc bổ sung để giữ cho hai công nghệ hài lòng với nhau. Tất nhiên, ứng dụng sử dụng kết hợp ODBC OleDb và MySql.

Bạn có nghĩ rằng dành thời gian và nguồn lực để phát triển lại hoàn toàn ứng dụng theo .Net sẽ hiệu quả hơn về chi phí không? Trong nỗ lực phát triển một ứng dụng ổn định hơn, liệu nó có hợp lý khi sử dụng .Net không? Hoặc tiếp tục theo đuổi các lỗi truy cập, thêm các tính năng mới trong .Net (có thể hoặc không thể tạo ra các lỗi mới giữa .Net và Access) và viết lại các mô-đun Access cũ vào các mô-đun .Net theo các ràng buộc về thời gian ngăn cản thiết kế và phát triển phù hợp?

Cập nhật Ứng dụng sử dụng OleDb và MySql - Tôi đã sửa câu lệnh trước đó của mình.

Ngoài ra, để hỗ trợ thêm cho việc viết lại: Tôi đã phát hiện ra rằng khi "chuyển" sang .Net bắt đầu, mã VBA / VB6 tồn tại về cơ bản được dịch sang tương đương .Net. Từ hiểu biết của tôi, không có gì được thực hiện để cải thiện hiệu suất, hoặc tận dụng các thư viện hoặc công nghệ mới.

Theo tôi, điều này tạo ra một ứng dụng rất mong manh và không ổn định. Với mỗi bản cập nhật mới, điều này ngày càng trở nên rõ ràng hơn. Là một kỹ thuật viên trợ giúp, tôi đã nhận thấy sự gia tăng các vấn đề được báo cáo. Các khách hàng sử dụng phần mềm đã nhận thấy sự gia tăng các vấn đề và đang bình luận về nó.

Rất nhiều người không khuyến khích viết lại một ứng dụng từ đầu và đôi khi tôi đồng ý với lý do này. Nhưng hầu hết các lần tôi thấy viết lại ứng dụng là giải pháp ít đau đớn nhất và mọi thứ được viết trong Access cần phải được chuyển sang .NET - PERIOD. Đừng hiểu sai ý tôi, Access có vị trí của nó và có thể cung cấp rất nhiều chức năng cho một tổ chức, nhưng nếu nó biến thành một ứng dụng chính thức mà mọi người dựa vào thì nó đã phát triển Access.

Có lẽ sẽ không mất nhiều thời gian để chuyển VBA hiện có sang .NET theo một chuyển đổi cho một lần chuyển đổi. Nhưng đó có thể không phải là một giải pháp tuyệt vời nếu VBA không tốt lắm để bắt đầu. Thiết kế lại / viết lại sẽ mất nhiều thời gian hơn để viết nhưng về lâu dài sẽ dễ bảo trì hơn nhiều.

Tôi hầu như luôn ở trong trại viết lại từ đầu, nơi Access có liên quan và đã không hối hận một lần.

Tôi đồng ý với phương pháp tái cấu trúc. Rất có khả năng đây sẽ là một quá trình chậm chạp có thể mất nhiều tháng để hoàn thành, nhưng bằng cách di chuyển một tính năng / phần tại một thời điểm có những lợi thế lớn bao gồm:

1. Tính năng sản phẩm được duy trì.
2. khả năng cung cấp một bản phát hành mới được duy trì.
3. Áp lực thời gian được loại bỏ.

Chúc may mắn

Nói chung, việc "viết lại" một ứng dụng từ đầu (đây là một thôi thúc bình thường mà hầu hết các lập trình viên cảm thấy ít nhất một vài lần trong đời) vì bạn sẽ đi từ một ứng dụng có bộ tính năng đã biết (và cả các lỗi đã biết!) đến một ứng dụng có nhiều tính năng ít được thiết lập hơn và quan trọng hơn - các lỗi chưa biết. Người dùng có thể bị thất vọng, vv

Bạn có thể sẽ tốt hơn nếu bạn từ từ tái cấu trúc ứng dụng của mình trong một khoảng thời gian, từ đó phát triển kiến ​​trúc của nó trong một khoảng thời gian dài hơn.

Một thách thức lớn mà tôi đã trải qua khi viết lại thang đo đó là phải duy trì hai cơ sở mã hóa cùng một lúc. Nếu bạn sửa một lỗi trong hệ thống cũ, bạn phải đảm bảo chức năng hoạt động chính xác trong hệ thống mới và ngược lại. Nâng cấp một mô-đun tại một thời điểm giảm thiểu sự đau đầu bảo trì.

Một bộ kiểm tra hồi quy đầy đủ chạy trên cả hệ thống kế thừa và thay thế cũng sẽ hữu ích.

Tôi đồng ý với Jas, đừng viết lại ứng dụng chỉ vì viết lại. Chúng có thể không bao giờ cần được gỡ lỗi hoặc cải thiện, vậy tại sao lại lãng phí thời gian? Tuy nhiên, nếu bạn cảm thấy có sự thay đổi trong chuyên môn của nhà phát triển mới của bạn thuê từ Access to .NET, bạn có thể phải di chuyển trước khi quá muộn. Điều đó dường như không thể, nhưng một sự cân nhắc có thể.

Mặc dù nó có thể không mang lại lợi nhuận từ quan điểm phát triển, làm thế nào để các ứng dụng khác nhau lan rộng ảnh hưởng đến người dùng? Nó có yêu cầu đào tạo người dùng nhiều hơn? Có phải họ đang phạm nhiều sai lầm hơn. Nó có làm tăng số lượng cuộc gọi hỗ trợ vì họ không thể tìm thấy thứ gì không?

"Bạn có nghĩ rằng dành thời gian và nguồn lực để phát triển lại hoàn toàn ứng dụng theo .Net sẽ hiệu quả hơn về chi phí không?"

Đây không phải là một câu hỏi có thể được trả lời ở đây.

Từ đỉnh của kim tự tháp yêu cầu: ai đó đã đưa ra quyết định mà anh ta hy vọng có thể biện minh với một kế hoạch kinh doanh. Trong kế hoạch kinh doanh đó, cần nêu rõ bao nhiêu giờ + chi phí thêm để chuyển đổi ứng dụng và trong cùng một kế hoạch kinh doanh, các lợi ích cũng được nêu trong điều khoản về tiền.

Đó là cách để làm điều đó. Nếu không có kế hoạch kinh doanh cho nó. sau đó, câu trả lời là trước tiên hãy làm việc trên một kế hoạch kinh doanh có thể truy nguyên theo một số trường hợp sử dụng cấp cao để thực hiện phân tích tác động để xác minh sự khởi đầu của dự án.

Nếu người điều khiển ban đầu của mục tiêu kinh doanh dẫn đến thay đổi thậm chí không dựa trên tiền thì người này có lẽ là người trả tiền cho tất cả vì vậy nó phải được thực hiện.

Nếu không có kế hoạch kinh doanh nhưng "nó chỉ được thực hiện" thì hãy cố gắng thực hiện một kế hoạch và trình bày cho quản lý cấp trên. Bao gồm các trường hợp sử dụng cấp cao, chi phí, giờ để thiết kế lại, xây dựng, thêm chi phí cho hoạt động, đào tạo mới cho quản trị viên và người tiêu dùng, quản lý dự án và các rủi ro tiềm ẩn.

IMHO đây không phải là câu hỏi kỹ thuật.