Bersihkan dekomposisi

Pada artikel ini, saya ingin mempertimbangkan pendekatan untuk membagi tugas menjadi subtugas ketika menggunakan Arsitektur Bersih.

Masalah dekomposisi ditemukan oleh tim pengembangan seluler NullGravity dan di bawah ini cara kami menyelesaikannya dan apa yang terjadi pada akhirnya.

Latar belakang

Itu musim gugur 2018, kami sedang mengembangkan aplikasi berikutnya untuk operator telekomunikasi. Tapi kali ini berbeda. Persyaratannya cukup ketat dan terkait dengan kampanye pemasaran klien. Tim Android telah berkembang dari 3 menjadi 6-7 pengembang. Beberapa tugas diambil dalam sprint dan pertanyaannya adalah bagaimana cara menguraikannya secara efektif.

Apa yang kita maksudkan ketika kita berbicara secara efektif:

1. Jumlah maksimum tugas paralel.
   Ini memungkinkan untuk menempati semua sumber daya yang tersedia.
2. Mengurangi ukuran permintaan gabungan.
   Mereka tidak akan ditonton untuk pertunjukan, dan Anda masih dapat menangkap masalah potensial pada tahap tinjauan kode.
3. Mengurangi jumlah konflik gabungan.
   Tugas akan mengalir lebih cepat dan tidak perlu mengalihkan pengembang ke resolusi konflik.
4. Kesempatan untuk mengumpulkan statistik biaya waktu.
5. Otomatisasi pembuatan tugas di Jira.

Bagaimana kami memecahkan masalah?

Kami membagi semua subtugas ke dalam jenis berikut:

• Data
• Domain
• Kosong
• UI
• Barang
• Kebiasaan
• Integrasi

Data dan Domain terkait dengan lapisan dalam Arsitektur Bersih.
Kosong, UI, Item dan Kustom merujuk ke lapisan presentasi.
Integrasi berlaku untuk domain dan lapisan presentasi.


_{Gambar 1. Lokasi tugas relatif terhadap lapisan Arsitektur Bersih}

Mari kita lihat setiap jenis secara individual.

Data

Deskripsi DTO, API, bekerja dengan database, sumber data, dll.

Domain

Antarmuka repositori, deskripsi model bisnis, interaksi.

Antarmuka repositori di lapisan data juga diimplementasikan.
Sepintas tidak masuk akal, pada pandangan pertama, pemisahan memungkinkan untuk mengisolasi tugas-tugas tipe data dan domain sebanyak mungkin.

UI

Membuat tata letak layar dasar dan status tambahan, jika ada.

Barang

Jika layar adalah daftar elemen, maka untuk setiap jenis Anda perlu membuat model - Item. Untuk memetakan Item ke tata letak, Anda perlu AdapterDelegate. Kami menggunakan konsep adaptor delegasi , tetapi dengan beberapa modifikasi .
Selanjutnya, buat contoh bekerja dengan item daftar di PresentationModel.

Kosong

Kelas dasar diperlukan untuk tugas-tugas seperti ui atau item: PresentationModel, Framgent, tata letak, modul DI, pabrik AdapterDelagate. Mengikat antarmuka dan implementasi. Buat titik masuk di layar.

Hasil dari tugas adalah layar aplikasi. Ini mengandung Toolbar, RecyclerView, ProgressView, dll. yaitu, elemen antarmuka umum, penambahan yang dapat diduplikasi oleh pengembang yang berbeda dan akan menyebabkan konflik gabungan yang tak terhindarkan.

Kebiasaan

Implementasi komponen UI non-standar.

Tipe tambahan diperlukan untuk memisahkan pengembangan komponen baru dari tugas UI tipe.

Integrasi

Integrasi lapisan domain dan presentasi.

Sebagai aturan, ini adalah salah satu tugas yang paling memakan waktu. Hal ini diperlukan untuk mengurangi dua lapisan dan memperhalus poin yang bisa terlewatkan pada tahap sebelumnya.

Perintah Tugas

Tugas seperti data, kosong dan khusus dapat dimulai segera setelah sprint dimulai. Mereka independen dari tugas-tugas lain.

Tugas domain dijalankan setelah tugas data.

Tugas dan item ui setelah tugas kosong.

Tugas integrasi adalah yang terakhir harus diselesaikan karena membutuhkan penyelesaian semua tugas sebelumnya.


_{Gambar 2. Pelaksanaan tugas Timeline}

Terlepas dari kenyataan bahwa beberapa tugas diblokir oleh tugas-tugas lain, mereka dapat dimulai pada saat yang sama atau dengan sedikit penundaan. Tugas tersebut termasuk domain, ui, dan item. Dengan demikian, proses pengembangan dipercepat.


_{Gambar 3. Garis waktu pelaksanaan tugas dengan kunci}

Untuk setiap fungsi tertentu, serangkaian tugas dapat bervariasi.
Mungkin ada sejumlah tugas yang berbeda kosong, ui, item dan integrasi, dan beberapa jenis mungkin tidak ada.

Otomatisasi proses dan pengumpulan statistik

Untuk mengumpulkan statistik saat membuat tugas, label ditugaskan untuk itu. Mekanisme ini di masa depan akan memungkinkan Anda untuk menganalisis waktu yang dihabiskan untuk setiap jenis, dan untuk membentuk biaya rata-rata. Informasi yang dikumpulkan dapat diterapkan ketika mengevaluasi proyek baru.

Untuk otomatisasi, kami juga berhasil menemukan solusi. Karena tugasnya tipikal, mengapa deskripsi mereka di Jira harus berbeda. Kami mengembangkan templat untuk ringkasan dan deskripsi. Pada awalnya itu hanya file json, parser Python dari file ini, dan API Jira REST terhubung untuk menghasilkan tugas.

Dalam bentuk ini, skrip berlangsung hampir setahun. Hari ini telah berubah menjadi aplikasi desktop lengkap yang ditulis dalam Python menggunakan arsitektur PyQt dan MVP.

Mungkin MVP di atas kepala, tetapi ketika versi pertama pada Tkinter menabrak MacOS versi 10.14.6 dan tidak semua tim dapat menggunakan aplikasi, kami dengan mudah menulis ulang tampilan untuk PyQt dalam setengah hari dan itu berhasil. Sekali lagi, kami yakin bahwa penggunaan pendekatan arsitektur, bahkan untuk tugas-tugas sederhana seperti itu, memiliki kelebihan. Tangkapan layar JiraSubTaskCreator ditunjukkan pada Gambar 4.


_{Gambar 4. Layar JiraSubTaskCreator utama}

Kesimpulan

1. Kami telah mengembangkan pendekatan untuk dekomposisi tugas ke dalam subtugas minimal bergantung satu sama lain;
2. Templat yang dibuat untuk menggambarkan tugas;
3. Kami menerima permintaan penggabungan kecil, yang memungkinkan untuk meninjau dan mengubah kode secara hati-hati
4. Mengurangi jumlah konflik dengan permintaan penggabungan;
5. Kami mendapat kesempatan untuk lebih akurat menilai dan menganalisis waktu yang dihabiskan untuk setiap jenis tugas;
6. Bagian otomatis dari pekerjaan rutin.