Banyak pemrogram telah mendengar bahwa kadang-kadang kode harus dialokasikan ke perpustakaan yang terpisah untuk digunakan kembali lebih lanjut. Namun, pertanyaan tentang kode seperti apa yang harus dipilih sebagai entitas terpisah membingungkan banyak pengembang. Saat membaca artikel / percakapan tentang topik ini, masalah generalisasi prematur biasanya teringat kembali.
Pemrogram berpengalaman biasanya memiliki aturan sendiri, yang mengikuti mereka memahami apakah kode harus dibedakan sebagai dapat digunakan kembali. Misalnya, jika kode seperti itu (atau sangat mirip) digunakan di tiga tempat atau lebih. Meskipun demikian, setiap orang yang pernah saya ajak bicara tentang hal ini setuju bahwa kode yang dapat digunakan kembali harus ada, penciptaannya adalah berkah, dan layak untuk menghabiskan waktu Anda.
Saya ingin mengangkat topik penggunaan kembali kode dalam konteks menciptakan arsitektur berorientasi layanan dan layanan mikro.
Apa kode yang dapat digunakan kembali?
Kode yang dapat digunakan kembali adalah kode yang diisolasi dalam entitas terpisah, yang disebut berbeda dalam bahasa yang berbeda - perpustakaan, paket, ketergantungan, dll. Biasanya, kode tersebut disimpan dalam repositori terpisah, dan ada dokumentasi untuk menghubungkan dan menggunakan kode ini (README.md). Selain itu, kode dapat dicakup oleh tes, mungkin ada instruksi untuk melakukan perubahan (CONTRIBUTING.md), dan CI dapat dikonfigurasi. Berbagai lencana yang dilampirkan pada deskripsi hanya meningkatkan representasi visual dari kematangan entitas yang diberikan, dan jumlah bintang yang diberikan akan menunjukkan popularitas solusi ini. Anda tidak perlu pergi jauh untuk contoh - cukup buka halaman github dari salah satu kerangka kerja populer dalam bahasa favorit Anda, misalnya
vue.js. Secara umum, metode desain perpustakaan berkualitas tinggi adalah gerobak dan troli kecil.
Layanan dan layanan microser
Dalam artikel ini, layanan adalah entitas lengkap yang melakukan serangkaian tugas khusus dalam domain tanggung jawabnya dan menyediakan antarmuka untuk interaksi. Layanan atau layanan mikro dalam artikel ini dari sudut pandang arsitektur dapat berupa konsep yang identik, pertanyaannya hanya dalam skala. Suatu layanan dapat terdiri dari serangkaian layanan microser yang mengimplementasikan sektor logika bisnis mereka, atau menjadi layanan microser yang membanggakan.
Arsitektur berorientasi layanan mengasumsikan bahwa setiap layanan minimal terhubung dengan yang lain. Namun demikian, interaksi antar-layanan tidak dikecualikan, tetapi hanya diasumsikan bahwa itu harus diminimalkan. Untuk menerima permintaan, suatu layanan biasanya mengimplementasikan beberapa API standar. Itu bisa apa saja - SISA, SABUN, JSONRPC atau GraphQL bermodel baru.
Secara konvensional, layanan dapat dibagi menjadi infrastruktur dan bahan makanan. Layanan produk adalah mereka yang menerapkan logika produk klien. Misalnya, mereka bekerja dengan aplikasi untuk koneksinya, atau mengatur dukungan untuk produk ini sepanjang seluruh siklus hidup klien. Layanan infrastruktur lebih banyak tentang fungsi dasar suatu perusahaan (atau proyek), misalnya, layanan yang berisi informasi pelanggan, atau layanan yang menyimpan informasi tentang pesanan tertentu. Selain itu, layanan infrastruktur mencakup layanan yang mengimplementasikan fungsi bantu, misalnya, layanan informasi pelanggan (mengirim pesan push atau SMS) atau layanan untuk berinteraksi dengan dadata.
Sedikit fantasi
Misalkan ada toko online hipotetis yang dibangun di atas arsitektur berorientasi layanan. Para pengembang keajaiban teknik ini dapat menyetujui di antara mereka sendiri dan sampai pada kesimpulan bahwa semua layanan mereka akan berfungsi sebagai API, misalnya, menggunakan protokol jsonrpc. Namun, karena toko online itu besar, tidak berdiri diam dan aktif berkembang, ada beberapa kelompok pengembangan di sana, biarlah lebih dari dua - dua yang desain, satu disertai dengan apa yang sudah ditulis. Juga, untuk meningkatkan efek, semua tim menulis di tumpukan yang sama.
Arsitektur toko online hipotetis:
Hanya layanan API yang menonjol di Internet yang menyediakan akses ke semua sistem front-end - antarmuka web toko online, serta aplikasi seluler.
Layanan informasi pelanggan menyimpan informasi tentang pelanggan, tahu bagaimana memulainya, memberikan otorisasi, mengeluarkan informasi yang diperlukan tentang mereka.
Layanan informasi produk menyimpan informasi tentang produk, saldo dan ketersediaannya untuk pemesanan, juga menyediakan metode untuk memperoleh informasi yang diperlukan dengan mudah.
Layanan pesanan beroperasi dengan pesanan. Berikut adalah logika pembentukan pesanan, konfirmasinya, pilihan jenis pembayaran dan alamat pengiriman, dll.
Layanan informasi pelanggan dapat mengirim PUSH / SMS / pesan email. Jenis komunikasi, misalnya, tergantung pada pengaturan klien tertentu, dan klien juga dapat mengatur waktu yang diinginkan untuk menerima pemberitahuan.
Layanan ini bersifat prasarana kondisional, karena tanpa mereka toko online tidak dapat berfungsi seperti itu.
Layanan promosi dan penawaran serta distribusi intisari seharusnya dikembangkan dalam waktu dekat oleh tim proyek. Layanan ini adalah kelontong bersyarat.
Jelas, dalam hal apa pun, layanan produk baru apa pun tidak akan dapat eksis tanpa interaksi dengan layanan infrastruktur - kemungkinan besar harus menerima informasi tentang pelanggan atau perlu mengirim pemberitahuan.
Dalam contoh yang dijelaskan di atas, detail implementasi setiap layanan sengaja disembunyikan. Jadi, misalnya, layanan informasi pelanggan mungkin memiliki mekanisme eksekusi kode tertunda, seperti antrian eksekusi, dan layanan informasi produk dapat memiliki panel admin sendiri untuk manajemen barang yang nyaman, dan api untuk sistem front-end mungkin memiliki beberapa replika. Selain itu, arsitektur yang digambarkan mungkin tidak optimal, hanya diambil dari kepala.
Dalam konteks arsitektur yang diusulkan, segera menjadi jelas bahwa perpustakaan siap pakai sangat penting untuk pengembangan produk yang cepat. Jadi, penting untuk memiliki implementasi yang siap pakai dari server jsonrpc, serta klien untuk itu, karena ini adalah protokol utama untuk mengatur interaksi antar layanan. Juga dalam contoh ini, masalah mendokumentasikan API meningkat sepenuhnya. Jelas, untuk pembentukan dokumentasi, tim juga harus memiliki alat yang sudah jadi. Jika kita berasumsi bahwa masih ada alat yang siap pakai untuk menghasilkan skema smd untuk server jsonrpc, maka kecepatan pengembangan layanan baru dapat meningkat lebih jauh. Akibatnya, di dalam perusahaan, idealnya, harus ada satu set perpustakaan siap pakai yang digunakan semua tim untuk melakukan tugas-tugas khas. Pustaka-pustaka ini dapat berupa milik atau open-source, yang utama adalah mereka melakukan tugasnya dengan baik. Jelas, tim yang ada di tumpukan umum dan menulis layanan menggunakan perpustakaan siap pakai akan lebih efektif daripada tim yang terus-menerus siklus. Kehadiran satu kerangka kerja dan satu database perpustakaan yang digunakan di semua tim proyek, saya sebut ekosistem tunggal.
Dan bagaimana dengan perusahaan besar?
Di perusahaan besar, ada jauh lebih banyak layanan infrastruktur, serta protokol interaksi yang digunakan. Jumlah perpustakaan yang sudah jadi bisa mencapai puluhan atau bahkan ratusan. Menyoroti dalam kode yang dapat digunakan kembali di sini bahkan lebih relevan.
Kebetulan saya memiliki pengalaman di sebuah perusahaan yang mempekerjakan sekitar 200 pengembang yang menulis dalam berbagai bahasa - java, c #, php, python, go, js, dll. Anehnya, ekosistem umum, dalam konteks tumpukan tunggal, jauh dari semua tim pengembangan miliki dan gunakan. Tampaknya hal yang jelas - untuk mempersiapkan kode yang dapat digunakan kembali, memformatnya dengan benar dan menggunakannya - masih jauh dari jelas. Tentu saja, tim pengembangan menyelesaikan masalah mereka. Seseorang menggunakan templat layanan - satu set kode yang membentuk inti dari setiap layanan baru, dari mana segala sesuatu yang tidak perlu dibuang dan yang diperlukan ditambahkan.
Tim pengembang lain menggunakan sepeda motor mereka sendiri, menyalin dan menempelkannya dari proyek ke proyek, dan tidak peduli mendokumentasikan dan mengujinya. Secara umum, ada banyak perpecahan dalam alat dan pendekatan yang digunakan dalam tumpukan yang sama di satu perusahaan. Apalagi secara geografis terletak di satu kota.
Manfaat ekosistem tunggal
Membentuk ekosistem tunggal dapat mengatasi banyak kesulitan, dan memiliki potensi besar untuk meningkatkan produktivitas bagi perusahaan besar. Faktanya, praktik ini diambil dari komunitas Open Source - solusi terbaik di bidangnya bertahan dan paling populer. Sekarang cukup untuk membuka manajer dependensi dan hanya akan terkejut dengan banyaknya solusi yang diusulkan. Tetapi pendekatan semacam itu dapat diterapkan di dalam perusahaan. Keuntungan dari pendekatan ini ketika menerapkan layanan baru adalah sebagai berikut:
- Stabilitas tinggi - penggunaan perpustakaan yang dicoba dan didokumentasikan dengan baik meningkatkan stabilitas layanan secara keseluruhan;
- Rotasi kolega yang mudah antar tim - jika semua tim berada di dalam ekosistem tunggal, maka ketika berpindah dari satu tim ke tim lainnya, pengembang tidak perlu menghabiskan banyak waktu untuk mengetahui alat yang digunakan, karena ia sudah mengenal mereka;
- Konsentrasi pada logika bisnis - memang, pengembangan layanan baru bermuara pada kebutuhan untuk memperketat ketergantungan yang diperlukan yang menyelesaikan semua tugas infrastruktur dan hanya menulis logika bisnis;
- Akselerasi pengembangan - tidak perlu berputar, semuanya sudah siap, kecuali untuk logika bisnis;
- Penyederhanaan pengujian - hanya logika bisnis yang perlu diuji, karena perpustakaan telah diuji;
Terbang di salep
Jelas bahwa untuk mencapai pendekatan ini, beberapa praktik harus diikuti, yaitu, mengembangkan perpustakaan menggunakan versi semantik, mengurus dokumentasi dan tes, dan telah dikonfigurasi. Ini adalah semacam indikator kedewasaan tidak hanya dari tim pengembangan, tetapi juga pengembang di perusahaan secara keseluruhan.
PS
Dan pendekatan berorientasi paket hanya karena kode yang dapat digunakan kembali pada stack saya disebut paket. Ya, itu terdengar lucu. Baru-baru ini, saya berdialog dengan salah satu kolega saya yang mendorong saya untuk menulis artikel ini:
- Rekan: Anda berubah menjadi kasir dalam lima
- saya: artinya?)
- Rekan: segera Anda akan bertanya "apakah Anda memerlukan paket?"
- I: tolong buka pikiran. saya tidak mengerti
- Rekan kerja: yah, untuk kesekian kalinya Anda memiliki paket yang sudah jadi untuk menyelesaikan masalah saya
Masalahnya adalah bahwa di komunitas pengembang kami di dalam perusahaan ada sekitar 20 buah paket siap pakai, dan penciptaan layanan baru diterjemahkan menjadi menarik ketergantungan yang diperlukan, serta menulis logika bisnis. Biaya mengikat dalam hal penulisan kode hampir dibatalkan.