Dari proyek ke proyek, kami melihat bahwa kode kami melakukan fungsi yang sama dan terlihat hampir sama. Ini membuat kita bertanya-tanya - apakah kita tidak melakukan pekerjaan ekstra dengan menulis ulang hal yang sama? Kami mulai menyalin kelas dari proyek sebelumnya dan masih memahami bahwa kami melakukan sesuatu yang salah dan benar - hanya menyalin kelas dari suatu proyek ke proyek, kami dapat dengan mudah kehilangan / ganti / hapus sesuatu, dan jika tim kami memimpin beberapa lagi proyek secara bersamaan, maka deteksi kesalahan di kelas yang dipinjam akan membutuhkan perubahan manual di semua proyek. Bosan menginjak rake ini, kami memutuskan bahwa kami membutuhkan kode umum yang akan dibagikan pada semua proyek kami dan setiap perubahan di dalamnya akan mudah ditarik. Ya, kami sedang membuat perpustakaan kami dari komponen yang dapat digunakan kembali! Anda akan belajar tentang berbagai cara untuk mengatur perpustakaan Anda, tentang semua pro dan kontra dari pendekatan di bawah cat :)

Ada beberapa cara untuk mengatur basis kode umum kami:

1. Perpustakaan Android (aar / jar)
2. Git submodule
3. Git subtree

Perpustakaan Android (aar / jar)

Pustaka apa pun untuk aplikasi kita hanyalah banyak kelas yang diatur dengan cara tertentu. Setiap kali kami menghubungkan beberapa Retrofit atau Belati di build.gradle , kami memuat perpustakaan sebagai arsip aar / jar dari salah satu platform penerbitan perpustakaan. Platform penerbitan perpustakaan paling populer adalah JCenter dan MavenCentral. Para pengembang perpustakaan bekerja di repositori mereka di versi baru, dan ketika versi menjadi siap untuk keluar ke dunia, mereka menerbitkannya di salah satu platform dan berkata "Hei, kami merilis versi baru dari perpustakaan teratas kami!". Semua yang masih harus dilakukan untuk pengembang yang menggunakan lib ini dalam proyek mereka adalah mengubah versi di build.gradle dan menikmati fitur-fitur baru. Apakah itu nyaman? Kata yang salah!

Tetapi seberapa mudah pendekatan ini jika perpustakaan kami berkembang dan setiap hari diperbarui dengan fitur-fitur baru oleh pengembang yang berbeda dari berbagai proyek tim kami? Mari kita lihat tampilannya dalam praktik.

Kami membuat repositori perpustakaan kami, berkontribusi beberapa fitur di sana, men-debug-nya, dan siap untuk membaginya dengan tim kami. Kemudian kita akan belajar tentang kata-kata seperti JCenter, MavenCentral, Bintray, Jitpack.io ... semua ini adalah platform untuk penerbitan perpustakaan. Sekarang platform utama untuk proyek Android adalah JCenter. Jika Anda membuat proyek, Anda akan melihat bahwa di build.gradle (level proyek) di repositori, JCenter ditentukan

repositories { google() jcenter() } 

Artinya, jika pengembang ingin menghubungkan perpustakaan Anda, maka itu sudah cukup baginya untuk menghubungkannya ke tingkat modul build.gradle .

Cara termudah untuk menerbitkan perpustakaan bagi saya tampaknya adalah Jitpack.io, beberapa langkah dan perpustakaan Anda siap digunakan.

Bagaimana mengatur kerja tim di perpustakaan

Jika kami membuat perpustakaan dan mengunggahnya ke repositori, maka sisa tim kami hanya memiliki arsip jar / aar yang diterima. Agar seluruh tim dapat mengerjakan apa saja - setiap pengembang harus mengempiskan repositori perpustakaan dan membuat perubahan padanya.

Versi

Ketika mengembangkan dan menggunakan perpustakaan, kita harus berurusan dengan konsep seperti versi. Yaitu, set perubahan di perpustakaan yang ingin kami terbitkan harus diperbaiki oleh versi. Ini akan membantu ketika memperbarui perpustakaan ke versi baru untuk memahami seberapa serius / memecah perubahan telah dibuat, berkat skema versi yang diadopsi.

Memeriksa perpustakaan di proyek

Untuk memverifikasi bahwa perubahan yang dilakukan melakukan apa yang kita maksudkan - perlu untuk memeriksa perilaku kode tertulis dalam proyek. Kami meningkatkan versi perpustakaan dan ... di sini adalah salah satu hambatan dari pendekatan ini. Perpustakaan kami dan proyek berada dalam repositori yang berbeda, yang berarti bahwa kami tidak bisa hanya mendapatkan kelas perpustakaan di proyek. Kami memiliki 2 opsi untuk memeriksa kode perpustakaan baru:

1. Buat modul dalam proyek perpustakaan sampel di mana kode akan ditulis yang memeriksa fungsionalitas perpustakaan. Opsi ini sederhana, tetapi ada 2 minus: 1. Kami menulis kode tambahan; 2. Lingkungan modul tes berbeda dari proyek nyata di mana kita akan menggunakan perpustakaan, dan jika kita membuat kesalahan, itu akan muncul ketika kita mendapatkan versi baru dari proyek.
2. Posting perubahan ke repositori mavenLocal lokal. Berkat pendekatan ini, Anda bisa mendapatkan kode baru di proyek, tetapi tidak akan dipublikasikan untuk seluruh tim (tetapi Anda perlu sedikit mengotak-atik pengaturannya).

Git submodule

Dalam pendekatan sebelumnya, kami menghadapi kesulitan mendapatkan kode baru pada tahap pengembangan / debugging dalam proyek, karena perpustakaan dan kode proyek berada di berbagai repositori dan proyek studio. Pendekatan Submodule Git juga melibatkan penggunaan repositori yang terpisah, tetapi memungkinkan proyek utama untuk mendapatkan perpustakaan sebagai modul menggunakan Git. Ini berarti bahwa kode perpustakaan akan tersedia di proyek dan semua perubahan segera tersedia di proyek!

Bagaimana cara kerjanya

Submodules memungkinkan Anda mengandung satu repositori Git sebagai subdirektori dari repositori Git lainnya. Ini memungkinkan untuk mengkloning repositori lain di dalam proyek, menyimpan komit untuk repositori ini secara terpisah.

Sederhananya, kami memiliki 2 repositori: proyek dan perpustakaan. Repositori proyek menyimpan kode perpustakaan dan tautan ke status repositori perpustakaan. Jadi Git mengerti kondisi apa (versi) dari perpustakaan yang dibutuhkan proyek.

Baca lebih lanjut tentang cara kerja Submodule Git di sini.

Bagaimana mengatur kerja tim

Dalam pendekatan Submodule Git, kerja tim di perpustakaan diatur sebagai berikut:

1. Saat membuat proyek baru atau menghubungkan perpustakaan ke proyek yang ada, cabang Git baru dari master dibuat dengan nama proyek.
2. Ketika tiba saatnya untuk mengisi kembali perpustakaan dengan beberapa fungsi, cabang untuk tugas (dari cabang proyek) dibuat dan perubahan dibuat di sana.
3. Sebuah tinjauan sedang dilakukan, kolam sedang dituangkan ke cabang proyek. Ketika perubahan yang cukup diketik untuk merilis versi, kumpulan dibuat pada gabungan cabang proyek di cabang utama perpustakaan.
4. Setelah kumpulan melewati ulasan oleh tim yang bertanggung jawab untuk perpustakaan dan dituangkan ke dalam cabang utama, tim proyek yang tersisa akan diberitahu tentang pembaruan perpustakaan yang telah muncul dan akan memutuskan pembaruan.

Versi

Ketika kumpulan dicurahkan ke master , dan tim diberitahu tentang pembaruan perpustakaan, mereka tidak menyadari seberapa global perubahan dalam versi baru. Bagaimanapun, pendekatan dengan Git Submodule tidak memerlukan skema versi apa pun. Tetapi masalah ini mudah diselesaikan dengan memperkenalkan skema versi. Yang diperlukan hanyalah menulis versi dan deskripsi tentang apa yang telah diubah dan ditambahkan ke deskripsi permintaan kumpulan di cabang master . Kemudian para pengembang akan mengerti berapa banyak mereka sekarang benar-benar dapat memutakhirkan ke versi baru perpustakaan. Kedengarannya hebat, tetapi pertanyaannya adalah:

Ya, studio tidak tahu bagaimana melakukan secara terpisah ke lib yang terhubung oleh submodule. Saya menggunakan SourceTree untuk menyelesaikan masalah ini. Aplikasi ini untuk Windows dan Mac, dan untuk Linux ada GitKraken.

Git subtree

Git Subtree adalah versi yang disempurnakan dari Git Submodule. Di Git Subtree mereka mencoba untuk memecahkan masalah yang dihadapi pengembang saat bekerja dengan Git Submodule, ada artikel bagus tentang hub yang menjelaskan perbedaan antara alat. Meskipun mereka bekerja secara berbeda, mereka memecahkan satu masalah.

Kesimpulan

Alat Git Submodule / Subtree sangat bagus untuk memecahkan masalah menciptakan basis kode umum untuk tim yang terlibat dalam beberapa proyek. Salah satu keuntungan penting adalah verifikasi instan kode baru pada proyek setelah melakukan perubahan pada perpustakaan. Dalam hal ini, pendekatan standar penerbitan perpustakaan ke JCenter atau MavenCentral lebih rendah. Jika Anda memutuskan untuk membawa Submodule / Subtree Git ke tim Anda, pikirkan terlebih dahulu tentang skema versi, dan buat aturan / plugin untuk mengontrol versi.

Penggunaan kembali yang bagus untuk semua orang!