Viết lại mã số di sản

Question

Bộ phận của tôi hiện đang phải đối mặt với trách nhiệm về nhiệm vụ duy trì một cơ sở mã COBOL khá lớn. Chúng tôi đang tự hỏi làm thế nào để thêm các tính năng mới để theo kịp với nhu cầu kinh doanh. Các lập trình viên COBOL khó có thể đến được vào những ngày này, và chúng tôi cũng nghĩ rằng chúng tôi sẽ có được năng suất cao hơn từ việc sử dụng một ngôn ngữ hiện đại hơn như Java hoặc C#.

Chúng tôi cảm thấy rằng chúng tôi có bốn lựa chọn:

1. Rewrite tất cả mọi thứ từ đầu, rời khỏi ứng dụng cũ để bản thân cho đến khi nó đã sẵn sàng để được thay thế
2. mọi thứ Rewrite từ đầu, nhận được một số người để duy trì ứng dụng cũ để đối phó với nhu cầu kinh doanh mới vì nhu cầu kinh doanh mới đang được xây dựng
3. Viết tất cả chức năng mới bằng ngôn ngữ hiện đại và tìm cách tích hợp mã mới với chức năng cũ.
4. Tiếp tục duy trì ứng dụng cũ.

Bạn nghĩ lựa chọn nào tốt nhất cho chúng tôi và tại sao?

Answer 1

Thành thật mà nói, đã giúp "cổng" một ứng dụng từ ColdFusion 5 sang PHP sang ColdFusion 8 Tôi muốn nói với # 1. Để lại ứng dụng cũ tại chỗ và đóng băng phát triển. Gặp gỡ khách hàng và tìm hiểu xem các tính năng mới là gì, ngoài việc hệ thống cũ hoạt động như thế nào/được cho là hoạt động và tạo ra một tài liệu yêu cầu tốt. Điều đó chỉ để lại các chi tiết về thiết kế và xây dựng, sau đó bạn có thể chọn ngôn ngữ và nền tảng tốt nhất cho ứng dụng của mình.

Hiện tại tôi đang làm việc, chúng tôi đang thực sự duy trì một ứng dụng CF cũ trong khi xây dựng ứng dụng .NET thay thế. Bạn có thể tưởng tượng mã .NET guys sẽ phải viết sau khi họ hoàn thành các ứng dụng cơ sở? Đó là lý do tại sao tôi khuyên bạn nên đóng băng sự phát triển.

Answer 2

Hãy cẩn thận khi viết lại toàn bộ. Có rất nhiều ví dụ về điều này sẽ gây khó chịu cho nhiều công ti phần mềm. Netscape là prime example

Answer 3

Tùy chọn # 2 và # 3 là lựa chọn tốt nhất của bạn. Nếu ứng dụng COBOL của bạn lưu trữ dữ liệu của nó trong một DB SQL hoặc một số định dạng sane khác mà bạn có thể dễ dàng truy cập từ một ngôn ngữ hiện đại là giải pháp rẻ nhất/dễ nhất.

Nếu không, sau đó yêu cầu một người nào đó trên nhân viên triển khai các tính năng mới quan trọng trong khi bạn xây dựng lại sẽ là cần thiết. Nhưng tôi vẫn đề xuất yêu cầu mọi người giới hạn các tính năng mới trong cơ sở mã cũ chỉ với những tính năng thực sự quan trọng.

Duy trì COBOL, về lâu dài, sẽ khó hơn. Bạn càng đợi lâu, nó sẽ càng khó khăn hơn.

Answer 4

Tôi là người tin tưởng mạnh mẽ vào việc cập nhật các ứng dụng cũ cho công nghệ tiên tiến (nhiều đến sự mất tinh thần của người quản lý của tôi). Điều này luôn luôn là một cách tiếp cận từng giai đoạn và chỉ được thực hiện nếu cần thiết. Cố gắng giữ cho ứng dụng cũ chạy và phục vụ mục đích của nó, nhưng tạo ra các phần nhỏ của nó trong một công nghệ mới hơn, và theo thời gian ngắt đoạn mã cũ và thay thế nó bằng mã mới hơn. Tôi luôn đảm bảo rằng tôi ưu tiên những lợi ích/chi phí này cho doanh nghiệp trước tiên.

Nếu ứng dụng được dệt quá chặt thì có vẻ như bạn cần thuê một số trình soạn thảo COBOL để giúp rút các dịch vụ riêng biệt, để bạn có thể giải quyết chúng khi bạn sẵn sàng.

Lưu ý điều này: đôi khi lỗi và quirks trong mã cũ ban đầu phục vụ mục đích mà doanh nghiệp dựa vào, vì vậy hãy cảnh giác với việc sửa lỗi mà mã khác sau này dựa vào.

Answer 5

admiteddly, vấn đề liên quan đến cobol mà làm cho bất kỳ câu trả lời cụ thể cho nhu cầu của bạn, nếu bạn nói "chúng tôi có một ứng dụng VB cũ" hoặc ứng dụng C cũ, sau đó tùy chọn # 3 luôn luôn là đúng cách để đi.

Tôi đã làm việc tại 3 công ty đã quyết định chọn tùy chọn # 2. 2 đã phá sản cố gắng để trả tiền cho hệ thống mới trong khi chỉ đạt được doanh thu từ cũ, thứ 3 đến rất gần thực sự.

Yếu tố khác để sử dụng # 3 là bạn có thể giữ tất cả các sửa lỗi cũ mà bạn đã làm trong những năm qua. Mọi viết lại luôn giới thiệu ngày càng nhiều lỗi, một phần vì bạn sẽ muốn viết lại được nhanh chóng, một phần vì bạn sẽ viết nó bằng một ngôn ngữ mới lạ và một phần vì tất cả mã mới đều có lỗi.

Tái cấu trúc và thay thế các khối lôgic của ứng dụng cũ, cuối cùng bạn sẽ có một khối mới sáng bóng. Bắt đầu với GUI để có cách tiếp cận an toàn nhất với giao diện mới. Bên cạnh đó, vào thời điểm bạn đã viết xong ứng dụng trong một cái gì đó mới, một cái gì đó thậm chí mới hơn sẽ là tuyệt vời nhất và ứng dụng mới của bạn sẽ lỗi thời và bạn sẽ đăng cùng một câu hỏi một lần nữa!

Answer 6

Tuân thủ quy tắc 80/20. Ngồi xuống với khách hàng và viết thông số kỹ thuật cho 20% ứng dụng nhận 80% mức sử dụng. Viết rằng trong một hệ thống hiện đại. Sau đó, hoặc giữ cho hệ thống cũ cho một số lượng co lại các trường hợp đặc biệt hoặc giai đoạn nó ra khi bạn xác thịt ra một hệ thống mới.

Đừng cố viết lại mã cũ 100%. Điều đó thật ngớ ngẩn. Kịch bản trường hợp tốt nhất là bạn có một cổng hoàn chỉnh của một hệ thống lỗi thời. Trường hợp xấu nhất là bạn đốt cháy rất nhiều thời gian và tiền bạc để có một hệ thống mới không thành công và bạn vẫn bị mắc kẹt với hệ thống cũ.

Sử dụng thời gian và công sức để cải thiện hệ thống, không chỉ là cổng. Sau khi chuyển các phần quan trọng nhất, hãy sử dụng thời gian để xem xét lại các trường hợp đặc biệt.

Answer 7

Một giải pháp khác có thể là:

Dịch mã sang ngôn ngữ hiện đại của sự lựa chọn của bạn.

Thông thường, điều đó sẽ liên quan đến nhiều khối lớn:

• phần Rewrite của ứng dụng di sản mà không thể được dịch. Ít nhất, sử dụng cấu trúc lập trình có cấu trúc ở mọi nơi.
• Triển khai internal DSL giúp dễ dàng ánh xạ các cấu trúc từ ngôn ngữ cũ bằng ngôn ngữ mới.
• Thực hiện trình dịch mã nguồn mã lệnh ném đi cho 90% mã.
• Dịch 10% còn lại của mã khéo léo bằng tay.
• Dành rất nhiều thời gian để nhận được những điều darn để biên dịch.
• Nhận toàn bộ thông qua một số thử nghiệm và sửa chữa nghiêm trọng.
• Dần dần làm sạch động vật kết quả để làm cho nó thành ngữ.

Ưu điểm chính của phương pháp này là nó sẽ bảo toàn tất cả các trường hợp góc kinh doanh khó chịu đã được mã hóa qua nhiều năm trong cơ sở mã. Vấn đề lớn với việc viết lại từ đầu là họ loại bỏ tất cả kiến ​​thức tích lũy này.

Một ưu điểm khác là nó biến một vấn đề khó chịu (duy trì ứng dụng cobol) thành một vấn đề thú vị (dịch ngôn ngữ tự động), vì vậy bạn có cơ hội để có được một lập trình viên tốt tham gia dự án.

Comment by Jim Denver

Nó sẽ không thể rất khó để viết một thông dịch viên mà chuyển thành mã mà là hơi có thể đọc được và duy trì? Vấn đề của chúng tôi là ứng dụng COBOL là một cơn ác mộng duy trì. Chúng tôi không muốn điều này trở thành cơn ác mộng tương tự ở một ngôn ngữ khác.

Tôi không thể biết nó sẽ khó như thế nào. Nó dễ dàng hơn nếu mã bạn đang bắt đầu là thường xuyên. Nhưng trong mọi trường hợp, bạn sẽ kết thúc bằng "COBOL được viết bằng $ LANG". Đây chỉ là điểm khởi đầu để viết lại gia tăng cho đến khi cơn ác mộng duy trì được khắc phục.

Đây chỉ là một cách thay thế để "viết lại từ đầu" và "duy trì trong COBOL". Nó có thể chỉ là giá trị của các kiến ​​thức tích lũy trong cơ sở mã là ít hơn chi phí dự kiến ​​của một dọn dẹp gia tăng.

Answer 8

Di chuyển ứng dụng dần dần?

Có cách nào bạn có thể giao diện mã khác với COBOL và dần dần viết lại thành phần thay đổi bong bóng qua không? Bạn có thể không bao giờ loại bỏ tất cả, nhưng nó thực sự quan trọng?

Viết lại mã hiện có thường là một ý tưởng tồi. Nó sẽ rất nguy hiểm (ví dụ như rủi ro phá vỡ một số chức năng được hiểu ít ai đó đang dựa vào) và sử dụng rất nhiều thời gian mà không đạt được bất kỳ điều gì hữu ích mà hầu hết các bên liên quan đều có thể nhìn thấy.

Đừng cho rằng một lập trình viên có thẩm quyền sẽ không thể học COBOL nếu nhu cầu phát sinh- một ngôn ngữ lập trình giống như ngôn ngữ khác. Nếu bạn thuê một người có thẩm quyền tại (nói) C++ hoặc Java, họ sẽ có thể tìm hiểu COBOL.

Answer 9

tôi muốn duy trì ứng dụng cũ, nhưng sau đó, tôi là một lập trình viên COBOL ....

Answer 10

tôi sẽ duy trì các mã cũ và thêm chức năng mới cho nó sử dụng một số công cụ tuyệt vời từ Microfocus/AcuCOBOL. Bạn có thể thực hiện các ứng dụng GUI và gọi các công cụ .NET và Java ngay từ mã "cũ" của mình.

Tại sao phải ngắt back-end nếu nó hoạt động cho bạn? Giữ cho back-end làm việc và thay thế front-end mệt mỏi là giải pháp mà công ty tôi làm việc đang bắt đầu sử dụng.

Vì vậy, tôi đoán lựa chọn của tôi sẽ là tùy chọn # 3, bởi vì có giải pháp ngoài đó như thế.

Answer 11

Đây là một biến thể của Lựa chọn 3:

Microfocus cung cấp một công cụ gọi là Enterprise Server cho phép COBOL để tương tác với các dịch vụ web.

Nếu bạn có chương trình COBOL A và một chương trình COBOL B và A khác gọi B qua phần giao diện, công cụ này cho phép bạn hiển thị phần giao diện của B làm dịch vụ web.

Đối với chương trình A, sau đó bạn tạo proxy máy khách và A bây giờ có thể gọi B qua dịch vụ web.

Tất nhiên, vì giờ đây B có dịch vụ web bất kỳ loại chương trình nào khác (dòng lệnh, ứng dụng Windows, Java, ASP, v.v.) hiện có thể gọi nó.

Sử dụng phương pháp này, bạn có thể "nibble đi ở các cạnh" để di chuyển GUI đến một phương pháp tiếp cận dựa trên trình duyệt hiện đại bằng cách sử dụng một cái gì đó như ASP trong khi vẫn sử dụng động cơ kinh doanh COBOL.

Và một khi bạn có một bộ dịch vụ web phong nha, chúng có thể được sử dụng cho bất kỳ phát triển mới nào cung cấp cách di chuyển khỏi COBOL trong thời gian dài hơn.

Answer 12

gì về việc sử dụng một trong những ứng dụng của bên thứ ba mà lấy COBOL và chuyển nó sang C# như:

http://www.softwaremining.com/index.jsp

Hoặc porting nó để COBOL.net, mà nên được dễ dàng hơn, sau đó tất cả mọi thứ bạn thêm có thể ở một trong các ngôn ngữ khác .net.

Answer 13

Điều tuyệt vời về COBOL là yêu cầu dữ liệu được viết ngay tại đầu mã. Nó cũng giúp COBOL được thiết kế để được viết bằng cách sử dụng (tương đối) đồng bằng tiếng Anh thương mại (TXTSPKers không cần phải áp dụng).

Tất nhiên, nếu máy cắt cỏ của bạn cũ hơn một số lập trình viên của bạn, hãy quên chúng để đọc nguồn. Họ sẽ rên rỉ quá nhiều.

Answer 14

Không đủ dữ liệu để xác định khóa học phù hợp.

Mặc dù nhiều folks đã bẽn với câu trả lời thích hợp cho hoàn cảnh cụ thể, câu trả lời đúng thực sự phụ thuộc vào tình hình kinh doanh của công ty bạn đang ở trong.

Những điều như lộ trình hiện có, cam kết giao hàng, hợp đồng dịch vụ, thời gian-to- các tính năng được yêu cầu khởi chạy và các tính năng tương tự sẽ xác định điều gì là tốt nhất trong trường hợp của bạn.

Điều đó nói rằng, nhiều câu trả lời của nhà kỹ thuật sẽ là # 1, trong khi nhiều câu trả lời của người kinh doanh sẽ là # 4. Không biết gì hơn những gì đã được trình bày, tôi sẽ thúc đẩy đội nghiên cứu điều tra sâu số 3 vì nó có thể là rủi ro thấp nhất. # 1 có một hồ sơ theo dõi đã được chứng minh là thất bại, và # 2 chỉ là # 1 với ít tài nguyên hơn. # 4 có lẽ không phải là giải pháp lâu dài, KHÔNG BAO GIỜ bạn đang EOL'ing dòng sản phẩm này trong thời gian gần/trung hạn.

Answer 15

Một công ty mà tôi biết phải vật lộn với chính xác cùng một câu hỏi trong nhiều năm; cuối cùng, họ đã bỏ ứng dụng COBOL và chuyển sang SAP. Làm điều đó là một dự án lớn mất vài năm để hoàn thành, nhưng nó đã hoạt động tốt.

Answer 16

Nếu bạn sử dụng OpenVMS, BridgeWorks có thể giúp bạn xây dựng một ứng dụng web bằng cách sử dụng mã cũ của bạn với các sửa đổi nhỏ.

Answer 17

Tôi đã tự di chuyển một hệ thống cũ sang một hệ thống cũ (mặc dù nó ở quy mô thấp hơn nhiều).

Chúng tôi đã sử dụng thành công phương pháp tiếp cận "thay thế dần dần" (# 2), cho hệ thống máy khách/máy chủ (hệ thống báo cáo trong nhà nhỏ).Chúng tôi thực sự đã làm nó với một twist, bằng cách sử dụng một "proxy" cách tiếp cận:

• Đầu tiên chúng tôi thực hiện một máy chủ mới mà cung cấp tất cả các giao diện chức năng/cuộc gọi của máy chủ cũ, nhưng trong nội bộ chỉ giao tất cả mọi thứ đến máy chủ cũ , được tiếp tục chạy.
• Sau đó, tất cả khách hàng đã được chuyển sang hệ thống mới; điều này tương đối không đau vì hệ thống mới về cơ bản chỉ là một trình bao bọc.
• Cuối cùng, chúng tôi dần dần viết lại máy chủ mới để triển khai chức năng mà không cần gọi lại hệ thống cũ.

Cách tiếp cận này mang lại nhiều sự linh hoạt và cho phép triển khai nội dung mới mà không cần chạm vào mã cũ. Việc chuyển đổi kéo dài hơn một năm và các phần cuối cùng của ứng dụng chỉ được di chuyển sang hệ thống mới vì máy chủ cũ đang chạy trên phần cứng cũ, chuyên dụng đã được giải mã.

Tôi thực sự đã đi xuống phòng máy chủ để tắt máy chủ cũ khi mọi thứ đã được di chuyển. Đó là niềm vui :-).

Ngẫu nhiên, cách tiếp cận "chuyển đổi dần dần" này cũng cho phép chúng tôi triển khai một số đăng nhập vào hệ thống mới, để quyết định chức năng nào được sử dụng thường xuyên. Bằng cách đó, một số chức năng máy chủ cũ có thể bị loại bỏ, bởi vì nó bật ra khách hàng không còn sử dụng nó nữa. Đó là một lợi thế đáng kể của phương pháp "ủy quyền".