Làm thế nào một người nên quản lý các hằng số trên nhiều ngôn ngữ?

Tôi có một tình huống trong đó tôi hỗ trợ chức năng của cùng một thư viện trong nhiều ngôn ngữ. Thường có các hằng số cần được chia sẻ giữa chúng (ví dụ: khóa tên trường json hoặc mã lỗi).

Cách tôi hiện đang làm là bằng cách xác định các hằng số trong mỗi ngôn ngữ.

Vấn đề đến trong bảo trì. Nếu tôi thêm một mã lỗi mới, tôi cần cập nhật nó trong mọi thư viện theo cách thủ công. Trong khi điều này tốt cho một số người thì nó trở nên tẻ nhạt nếu tôi nói 5 sdks để cập nhật. Thật tuyệt khi có một nguồn sự thật cho những điều này.

Tôi đã nghĩ về một số loại tệp giống như cấu hình nhưng sau đó nó cần được bao gồm trong mọi gói được triển khai, điều này làm tăng thêm sự phức tạp cho quá trình xây dựng / phát hành của chúng tôi.

Có cách nào tốt hơn để xử lý việc bảo trì các hằng số được chia sẻ giữa nhiều ngôn ngữ không?

Mặc dù tôi nghĩ rằng cách tiếp cận hiện tại của bạn có lẽ là đơn giản và đơn giản nhất, đây là một vài ý tưởng thay thế:

• Trích xuất các hằng số của bạn (và có lẽ các mô hình) vào một gói khác được biên dịch chéo cho tất cả các ngôn ngữ của bạn. Bạn có thể biên dịch chéo toàn bộ thư viện, nhưng điều đó có thể đi kèm với một số vấn đề đáng kể. Chỉ cần các hằng số biên dịch chéo sẽ đủ đơn giản để không có nhiều vấn đề. Bạn có thể xuất bản gói hằng và phụ thuộc vào nó trong các thư viện dành riêng cho ngôn ngữ của bạn. Haxe có thể làm điều đó. Cách tiếp cận này tốt vì bạn vẫn sẽ kiểm tra thời gian biên dịch (đối với các ngôn ngữ được biên dịch)
• Lưu trữ cấu hình trong một dịch vụ trung tâm. Ví dụ: dịch vụ web xà phòng có Ngôn ngữ mô tả dịch vụ web (WSDL) và dịch vụ REST có Ngôn ngữ mô tả ứng dụng web (WADL) mô tả các hoạt động và thông báo của dịch vụ. Ngoài ra còn có các dịch vụ cấu hình tập trung chung chung như Spring Cloud Config
• Tập tin cấu hình. Tôi biết bạn đã đề xuất nó, nhưng tôi không nghĩ rằng nó cần làm phức tạp quá trình xây dựng / phát hành của bạn rất nhiều. Đặt tệp cấu hình của bạn trong một dự án xây dựng riêng (nơi bạn có thể phiên bản nó). Xuất bản dự án lên tất cả các kho lưu trữ gói ngôn ngữ cụ thể của bạn (Maven, Nuget, NPM, v.v.) sau đó trong các thư viện dành riêng cho ngôn ngữ của bạn, bạn có thể phụ thuộc vào gói. Điều này không nên phức tạp hơn việc có một dự án bổ sung trong đường ống xây dựng của bạn.
• Như RubberDuck đã đề xuất, việc tạo mã là một lựa chọn tốt để biên dịch chéo. Bạn có thể tạo các định nghĩa không đổi cho mỗi ngôn ngữ bằng cách sử dụng một cấu hình chung.

Câu hỏi tuyệt vời! Tôi có cùng một vấn đề chính xác; các hằng số của tôi về cơ bản là: những ngôn ngữ nào được hỗ trợ trong các ứng dụng của tôi và thông tin bổ sung về các ngôn ngữ đó khi chúng liên quan đến chức năng trong ứng dụng.

Thật không may, điều tốt nhất tôi tìm thấy (như bạn có) là chỉ cần xác định lại các hằng số cho mỗi ngôn ngữ, như bạn hiện đang làm (tôi biết, bạn chắc chắn muốn nghe điều đó ).

Rõ ràng là nó cảm thấy sai bởi vì nó trái ngược với DRY ( WET ?? ). Tuy nhiên, các hằng số nên thay đổi không thường xuyên đến mức 5-10 phút xác định lại chúng cho từng ngôn ngữ không thực sự làm phiền tôi. Vào cuối ngày, các vấn đề nhỏ với một số giải pháp 'thanh lịch' như chia sẻ cấu hình hoặc tạo mã có thể mất hàng giờ hoặc nhiều ngày để giải quyết, vậy điều gì thực sự đạt được? Sự phức tạp gia tăng với nguy cơ xảy ra sự cố có thể mất thêm nỗ lực để khắc phục không phải là điều mà tôi muốn giải quyết.

Hơn nữa, nếu ứng dụng của bạn có quá nhiều hằng số xác định lại chúng theo ngôn ngữ khi bạn thêm hoặc thay đổi chúng mất một khoảng thời gian đáng kể, bạn có thể có mùi mã quan trọng hơn để xử lý và tại thời điểm đó, bạn có thể muốn bật đến một cái gì đó phức tạp hơn.

Vì vậy, trong ngắn hạn, xác định lại chúng cho từng ngôn ngữ là giải pháp tốt nhất của tôi và tôi vẫn chưa nghĩ ra bất cứ điều gì DRY sẽ không có nhiều yếu tố rủi ro hơn tôi muốn giải quyết.

Mặc dù vậy, một điều chắc chắn phải làm là đảm bảo rằng các hằng số của bạn được ghi chép tốt theo cách tổng quát (và bất khả tri ngôn ngữ) (chúng tôi có tài liệu repo tài liệu của công ty với thông số kỹ thuật, tài liệu linh tinh, tài liệu 'bảng vẽ', v.v. tài liệu này). Đồng thời đảm bảo rằng bạn có (các) cơ chế để giữ các định nghĩa của chúng đồng bộ. Đó là một vấn đề lớn với cách tiếp cận sao chép như bạn sẽ gặp phải, ngoại trừ một chút đau khổ tâm lý từ việc sao chép mã có chủ ý. Nhưng cuối cùng, những thay đổi liên tục của bạn nên rất có chủ ý và không thường xuyên , vì vậy vấn đề đồng bộ nên về cơ bản là không.

Tôi cũng nên đề cập rằng trong nhiều năm qua, tôi đã thấy các cổng đa ngôn ngữ của các thư viện khác nhau (quá mệt mỏi để nhớ chúng là gì vào lúc này) được viết bởi cùng một nhóm luôn có các hằng số được định nghĩa bằng các ngôn ngữ. Không có cấu hình được chia sẻ, không tạo mã (ngoại trừ các thư viện máy khách API của Google ... nhưng thôi, Google có các tài nguyên để chi trả cho sự phức tạp như vậy). Vì vậy, tôi nghĩ rằng chúng ta đã va phải một bức tường gạch trên cái này. Có lẽ cuối cùng ai đó sẽ đến với một thư viện để giải quyết vấn đề này;)

Hy vọng, lõi của thư viện của bạn được viết bằng một ngôn ngữ và các thư viện khác sử dụng FFI ( https://en.wikipedia.org/wiki/Foreign_feft_interface ) để gọi đến thư viện lõi. Điều này sẽ cung cấp cho bạn vị trí trung tâm để cung cấp một api để xuất bản các hằng số và định nghĩa từ đó. Bằng cách này, mọi thứ đều khép kín trong thư viện. Tôi chỉ đề cập đến điều này vì nó dường như không được đưa vào phản hồi của Samuel.

Tôi nghĩ rằng nó thực sự phụ thuộc vào khả năng cơ sở người dùng của bạn. Là đủ khả năng để có thể xử lý chuyển qua một tập tin cấu hình khác? Họ có khả năng thiết lập một dịch vụ mới không? Đối với đại đa số người dùng mà tôi đã hỗ trợ, tôi muốn mọi thứ được khép kín - theo cách này, người dùng sẽ không phải suy nghĩ về điều đó.