Bagaimana seharusnya seseorang mengelola konstanta di berbagai bahasa?


13

Saya memiliki situasi di mana saya mendukung perpustakaan yang secara fungsional sama dalam berbagai bahasa. Sering ada konstanta yang perlu dibagi di antara ini (misalnya, kunci nama bidang json atau kode kesalahan).

Cara saya saat ini melakukan ini adalah dengan memiliki kode yang mendefinisikan konstanta dalam setiap bahasa.

Masalahnya muncul dalam pemeliharaan. Jika saya menambahkan kode kesalahan baru, saya perlu memperbaruinya di setiap perpustakaan secara manual. Meskipun ini baik untuk beberapa, itu menjadi membosankan jika saya katakan 5 sdks untuk memperbarui. Akan menyenangkan memiliki satu sumber kebenaran untuk ini juga.

Saya telah memikirkan beberapa jenis file seperti config tetapi kemudian harus dimasukkan dalam setiap paket yang dikerahkan yang menambah kompleksitas pada proses build / release kami.

Apakah ada cara yang lebih baik untuk menangani pemeliharaan konstanta yang dibagi antara beberapa bahasa?


Pendekatan Anda baik-baik saja, enderland. Saya mencoba mencari solusi yang lebih baik untuk pendefinisian ulang karena banyak kali beberapa klien mengkonsumsi program API saya dan sebenarnya tidak ada solusi yang elegan. Redefinisi konstanta masih yang paling mudah.
Andy

5
@ Davidvider tidak, tidak, tidak, Anda seharusnya memiliki solusi yang sangat elegan untuk saya. Jangan bilang ini yang terbaik! :-)
enderland

1
Saya mempertanyakan pilihan saya tetapi kemudian menyadari bahwa konstanta dimaksudkan untuk konstan. Mereka dapat diprediksi karena mereka konstan. Dengan menyimpannya dalam JSON atau format lain yang biasanya dapat diurai, mereka tidak benar-benar konstan lagi. Contoh khas dalam proses kerja saya adalah objek notifikasi yang berisi typeatribut untuk identifikasi struktur saat mentransfernya melalui kabel. Dengan ini, klien seluler hanya menentukan konstanta (jenis) yang mereka pahami pada saat itu dan mengabaikan jenis yang tidak dikenal. Definisi dinamis akan menyebabkan banyak masalah.
Andy

Anda memerlukan tabel tabel yang memetakan ke deretan konstanta dari tabel bahasa.
johnny

Jawaban:


10

Meskipun saya pikir pendekatan Anda saat ini mungkin yang paling sederhana dan paling mudah, berikut adalah beberapa ide alternatif:

  • Ekstrak konstanta Anda (dan mungkin model) ke paket lain yang dikompilasi silang ke semua bahasa Anda. Anda mungkin dapat mengkompilasi silang seluruh perpustakaan, tetapi itu mungkin memiliki sejumlah masalah. Konstanta kompilasi silang harus cukup sederhana sehingga tidak akan ada banyak masalah. Anda dapat menerbitkan paket konstanta Anda dan bergantung padanya di perpustakaan khusus bahasa Anda. Haxe mungkin bisa melakukannya. Pendekatan ini baik karena Anda masih akan memiliki waktu kompilasi (untuk bahasa yang dikompilasi)
  • Menyimpan konfigurasi di layanan pusat. Misalnya layanan web sabun memiliki Bahasa Deskripsi Layanan Web (WSDL) dan layanan REST memiliki Bahasa Deskripsi Aplikasi Web (WADL) yang menjelaskan operasi dan pesan layanan. Ada juga layanan konfigurasi terpusat umum seperti Spring Cloud Config
  • File konfigurasi. Saya tahu Anda sudah menyarankannya, tetapi saya pikir itu tidak perlu terlalu mempersulit proses pembuatan / rilis Anda. Letakkan file config Anda di proyek build yang terpisah (di mana Anda dapat membuat versinya). Publikasikan proyek ke semua repositori paket khusus bahasa Anda (Maven, Nuget, NPM, dll.) Lalu di perpustakaan khusus bahasa Anda, Anda dapat bergantung pada paket. Ini seharusnya tidak lebih rumit daripada memiliki proyek tambahan di pipeline build Anda.
  • Seperti yang disarankan RubberDuck, pembuatan kode adalah alternatif yang baik untuk melakukan kompilasi silang. Anda dapat menghasilkan definisi konstan untuk setiap bahasa menggunakan konfigurasi umum.

5
@RubberDuck pembuatan kode terdengar menarik (terutama untuk salah satu kasus penggunaan tangensial saya, yang sudah melibatkan pembuat kode).
enderland

3

Pertanyaan bagus! Saya memiliki masalah yang persis sama; konstanta saya pada dasarnya: bahasa apa yang didukung dalam aplikasi saya, dan informasi tambahan tentang bahasa-bahasa tersebut karena berkaitan dengan fungsionalitas dalam aplikasi.

Sayangnya, hal terbaik yang saya temukan (seperti yang Anda miliki) adalah cukup mendefinisikan ulang konstanta untuk setiap bahasa, seperti yang Anda lakukan saat ini (saya tahu, Anda pasti ingin mendengarnya ).

Jelas itu terasa salah karena itu kebalikan dari KERING ( WET ?? ). Namun, konstanta harus berubah sangat jarang sehingga 5-10 menit mendefinisikannya kembali untuk setiap bahasa tidak terlalu mengganggu saya. Pada akhirnya, masalah kecil dengan beberapa solusi 'elegan' seperti konfigurasi bersama atau pembuatan kode dapat membutuhkan waktu berjam-jam atau beberapa hari untuk diselesaikan, jadi apa yang benar-benar didapat? Menambah kerumitan dengan risiko terjadi kesalahan yang perlu upaya tambahan untuk memperbaikinya bukanlah sesuatu yang ingin saya tangani.

Selain itu, jika aplikasi Anda memiliki begitu banyak konstanta yang mendefinisikan ulang mereka per bahasa ketika Anda menambah atau mengubahnya membutuhkan banyak waktu, Anda mungkin hanya memiliki bau kode yang lebih signifikan untuk ditangani dan, pada titik itu, Anda mungkin ingin mengubah untuk sesuatu yang lebih kompleks.

Jadi singkatnya, mendefinisikan kembali mereka untuk setiap bahasa adalah solusi terbaik saya, dan saya belum memikirkan sesuatu yang lebih KERING yang tidak memiliki faktor risiko lebih daripada yang ingin saya tangani.

Namun, satu hal yang pasti harus dilakukan adalah memastikan bahwa konstanta Anda didokumentasikan dengan baik dengan cara umum (dan bahasa agnostik) (kami memiliki repo dokumentasi perusahaan dengan spesifikasi, dokumen lain-lain, dokumen 'papan gambar', dll. Tempat kami menyimpannya dokumen ini). Pastikan juga Anda memiliki mekanisme untuk menjaga definisi mereka tetap sinkron. Itu tentang masalah besar dengan pendekatan duplikasi seperti yang Anda miliki, kecuali untuk sejumlah kecil tekanan psikologis dari duplikasi kode yang disengaja. Tetapi pada akhirnya, perubahan konstan Anda harus sangat disengaja dan jarang , sehingga masalah sinkronisitas pada dasarnya tidak ada.


Saya juga harus menyebutkan bahwa selama bertahun-tahun, saya telah melihat port multi-bahasa dari berbagai perpustakaan (terlalu lelah untuk mengingat apa itu saat ini) ditulis oleh kelompok yang sama yang selalu memiliki konstanta yang didefinisikan dalam bahasa itu sendiri. Tidak ada konfigurasi bersama, tidak ada pembuatan kode (kecuali untuk perpustakaan klien Google API ... tapi ayolah, Google memiliki sumber daya untuk membayar kompleksitas seperti itu). Jadi saya pikir kita telah menabrak dinding bata yang satu ini. Mungkin seseorang pada akhirnya akan datang dengan perpustakaan untuk mengatasi masalah ini;)


0

Mudah-mudahan, inti perpustakaan Anda ditulis dalam satu bahasa, dan perpustakaan lain menggunakan FFI ( https://en.wikipedia.org/wiki/Foreign_function_interface ) untuk menelepon ke perpustakaan inti. Ini akan memberi Anda lokasi pusat untuk menyediakan api untuk menerbitkan konstanta dan definisi dari. Dengan cara ini semuanya ada di dalam perpustakaan. Saya hanya menyebutkan ini karena sepertinya tidak dimasukkan dalam tanggapan Samuel.

Saya pikir itu benar-benar tergantung pada kemampuan basis pengguna Anda. Apakah cukup mampu untuk menangani melewati file konfigurasi lainnya? Apakah mereka dapat mengatur layanan baru? Untuk sebagian besar pengguna yang telah saya dukung, saya ingin semuanya serba lengkap - dengan cara ini para pengguna tidak perlu memikirkannya.


1
Hopefully, the core of you library is written in one language, and the other libraries use FFI Sayangnya kami memiliki pustaka untuk klien web dan kode server (dalam berbagai bahasa) jadi ... itu tidak mudah untuk dilakukan (dan mungkin kerentanan keamanan jika kami dapat memulai di aplikasi web).
enderland

Saya menyarankan agar Anda meningkatkan keamanan Anda, karena saya tidak akan pernah cukup mempercayai pengguna saya untuk merahasiakan file konfigurasi.
Robert Baron

Bagaimana Anda menggunakan aplikasi web yang menangani kode kesalahan? Atau nama bidang json? Saya bingung dengan apa yang Anda pikir saya lakukan itu adalah masalah keamanan. Menjalankan kode arbitrer pada mesin klien saya benar-benar merupakan masalah keamanan, yang memungkinkan mereka untuk mengurai json dari server sepertinya tidak akan terjadi kecuali saya kehilangan sesuatu.
enderland

Saya telah bekerja di perusahaan, yang menjadi dasar keamanan adalah generator nomor acak gaya DOS dan nilai seed yang disimpan sebagai konstanta. Ini cenderung diperbaiki dengan sangat cepat setelah ditunjukkan. Namun, jika Anda meletakkan nilai unggulan ke dunia, Anda akan memberikan kunci kerajaan. Karena perangkat lunak Anda tampaknya terutama berbasis web, simpan konfigurasi dalam objek JSON dan biarkan masing-masing bahasa mengurai yang sama file bersama.
Robert Baron

Nama bidang JSON mungkin tidak dan tidak harus konstan. Berapa kemungkinan bahwa nama bidang ini perlu diubah, tetapi Anda tidak mengubah nama konstanta itu sendiri? Anda mungkin lebih diuntungkan dari menghasilkan kode untuk mengakses entri, atau menggunakan bahasa ekspresi seperti ObjectPath.
Lie Ryan
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.