Chiến lược di chuyển để phản đối ngôn ngữ kịch bản nội bộ


8

Chúng tôi có một ngôn ngữ kịch bản mà chúng tôi sử dụng nội bộ cho nhiều thứ. Nó bắt đầu như một tuyên bố đánh giá đơn giản cho các nhãn động để trở thành một ngôn ngữ hoàn chỉnh Turing được sử dụng phổ biến trong toàn hệ thống của chúng tôi.

Vấn đề là nó không bao giờ được thiết kế cho điều này và nó cho thấy. Môi trường phát triển thiếu máu, các tập lệnh được tạo ra không thể kiểm tra được và cho đến ngày nay vẫn chưa có định nghĩa chính thức về ngôn ngữ.

Tình cảm ngày càng tăng giữa những người dùng ngôn ngữ cảm thấy rằng nó đã hoàn thành công việc và đã đến lúc phải buông tay nhưng chúng tôi phải đối mặt với một thách thức khó khăn để di chuyển cơ sở mã hiện tại sang bất kỳ giải pháp mới nào sẽ được đưa ra. Chính lập luận này được sử dụng chống lại ý tưởng di chuyển.

Bạn đã bao giờ phải đối mặt với một tình huống tương tự? và nếu vậy những chiến lược nào bạn đã sử dụng để ngừng sử dụng cái cũ và thúc đẩy cái mới?

Một điều cuối cùng (cảm ơn Morons ) là nhiều kịch bản này không được ghi lại và mục đích ban đầu của chúng bị mất mặc dù chúng vẫn đang được sử dụng. Các tập lệnh cũng được sử dụng tại các trang web của khách hàng để tùy chỉnh hệ thống, vì vậy chúng tôi có hàng ngàn tập lệnh này, một phần lớn không thuộc quyền kiểm soát nguồn hoặc bất kỳ cơ chế tạo phiên bản nào cho vấn đề đó.


Chấp nhận câu trả lời.

Khó lựa chọn này là. Tất cả các câu trả lời đều là lời khuyên tốt và hợp lý mặc dù tôi nghĩ rằng những lời nói dối tốt nhất có phần giống với sự kết hợp của Moron và Oliver.

Cuối cùng tôi đã chấp nhận Oliver vì đó là câu trả lời có cơ hội tốt nhất để được chấp nhận cao hơn (ha! Chính trị!). Đóng gói môi trường kịch bản cũ trong một tuyên bố có thể gọi được có thể được tích hợp trong môi trường mới sẽ cung cấp một lộ trình nâng cấp nhanh chóng và dễ dàng.

Sau khi hoàn thành, chúng ta có thể kiểm soát việc tạo ra các tập lệnh mới tốt hơn bằng cách hiển thị các cảnh báo hoặc không cho phép các tập lệnh cũ hoàn toàn không bị chỉnh sửa hoặc tạo ra buộc phải đi với ngôn ngữ mới.

Cảm ơn tất cả cho đầu vào của bạn!


4
Khi tôi đọc "một điều cuối cùng (cảm ơn Morons)", tôi nghĩ rằng bạn đang bình luận về trí thông minh của nhà thiết kế ban đầu.
Kyle Hodgson

2
:-D không, mặc dù tôi đã cảm thấy kinna viết nó kỳ lạ và do dự một lúc. Sau đó, một lần nữa anh ấy chọn tên để tôi đoán nó ổn!
Newtopian

1
Ổn mà!! ......
Morons

Câu trả lời:


5

Một cách tiếp cận khác là chuyển thời gian chạy tập lệnh của bạn sang ngôn ngữ kịch bản mới mà bạn chọn và cung cấp các cách để thực thi các tập lệnh cũ trong ngôn ngữ mới.

LegacyR.78.execute (Tập lệnh chuỗi);

Có thể trộn mã cũ và mã mới sẽ dễ dàng chuyển đổi.


11

Việc bạn đang xử lý một ngôn ngữ kịch bản tùy chỉnh là không liên quan. Bạn đang di chuyển một tập các tập lệnh từ ngôn ngữ này sang ngôn ngữ khác.

Có 2 chiến lược cơ bản:

1) Nỗ lực rất lớn để chuyển đổi tất cả các tập lệnh trả trước (như một dự án)

2) Khi bạn cần thay đổi các tập lệnh cụ thể, hãy viết lại chúng bằng ngôn ngữ mới. Sau một thời gian, khi chỉ còn một vài đoạn script trong ngôn ngữ gốc, hãy tiếp tục thực hiện một dự án để hoàn thành chúng. *

Dù bằng cách nào bạn cũng cần đặt quy tắc cứng và nhanh: Không có mã mới nào được viết bằng ngôn ngữ cũ.

* Bạn cũng có thể đặt quy tắc về số tiền bạn được phép chỉnh sửa trước khi phải viết lại toàn bộ nội dung, nhưng điều này có thể bị lạm dụng như một lỗ hổng.


Tôi đoán tôi đã quên đề cập rằng rất nhiều kịch bản trong đó có mục đích nhưng kiến ​​thức đó đã biến mất với người tạo ra nó khi họ rời công ty.
Newtopian

1
Điều này không thay đổi bất cứ điều gì ... Bạn sẽ cần phải hiểu mã tại một số điểm. Và bạn cũng sẽ cần Thay đổi mã tại một số điểm. (Tất nhiên trừ khi, không ai trong nhóm dự định có mặt ở đó :-)
Morons

1
Với một chiến lược rất đơn giản, sẽ ít có khả năng sẽ có những sơ hở để bị lạm dụng. Ngoài chiến lược Morons, tôi sẽ cố gắng kiểm soát phiên bản trước khi làm bất cứ điều gì.
thiệu

@refro Tôi đồng ý với bạn nhưng tiếc là nó gần như không thể. Có lẽ có hàng tá định dạng lưu trữ khác nhau cho các tập lệnh này và không có định dạng nào rất thân thiện với SCM. Kịch bản thường được trình bày dưới dạng một blob cơ sở 64 phải được tải trong trình chỉnh sửa tương thích. Nhưng chủ yếu là vì các tập lệnh có thể được chỉnh sửa trực tiếp bởi khách hàng và được lưu trữ cục bộ trong cơ sở dữ liệu của họ. Có một tập hợp lớn (bị nghi ngờ) mà chúng ta thậm chí không biết tồn tại. Điều đó nói rằng ngôn ngữ rất khó để làm việc với tôi, tôi nghi ngờ nhiều khách hàng đã đầu tư nhiều vào nó.
Newtopian

5

Tôi đã có một kinh nghiệm như vậy.

Cách tiếp cận của tôi là thiết kế ngược lại việc thực hiện ngôn ngữ, lấy ra một đặc tả chính thức hơn hoặc ít hơn cho cú pháp và ngữ nghĩa của nó (hãy tưởng tượng giải mã một BNF ra khỏi trình phân tích cú pháp viết tay trong Fortran77, với hàng ngàn từ khóa). Sau đó, tôi đã triển khai một trình biên dịch cho ngôn ngữ này, dịch nó thành một mã Lua thành ngữ (thậm chí lưu giữ hầu hết các ý kiến).

Bạn có thể chọn bất kỳ ngôn ngữ kịch bản phổ biến phù hợp hoặc triển khai DSL được thiết kế tốt hơn của riêng bạn. Trình biên dịch có thể được sử dụng như một lớp dịch trong suốt (giữ nguyên các tập lệnh cũ) hoặc để viết lại các tập lệnh để bảo trì tốt hơn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.