“Tolong tinggalkan aku sendiri, aku adalah pencipta! Biarkan saya membuat! ”- programmer Gennady untuk ketiga kalinya malam ini melafalkan mantra ini di kepalanya. Namun, dia belum menulis satu baris kode pun, karena permintaan pull lain telah tiba di perpustakaan yang coba dia kembangkan. Dan, menurut kebijakan perusahaan, peninjauan kode harus dilakukan dengan penundaan minimal. Sekarang Gennady sedang memikirkan apa yang harus dilakukan: tanpa melihat untuk menerima perubahan, tanpa menolaknya, atau masih menghabiskan waktu yang berharga untuk memahami esensi mereka. Lagipula, siapa selain dia? Dia menulis kode ini, dia akan mengikutinya. Dan semua perubahan hanya mungkin melalui persetujuan pribadinya, karena ini adalah Perpustakaan Kiamat.
Sementara itu, secara harfiah di balik tembok, tim yang disebut "Berang-berang Cedar" mendistribusikan ulang permintaan di antara mereka sendiri sehingga beban saat melihatnya turun lebih atau kurang merata. Ya, mereka tidak berurusan dengan Doomsday Library, tetapi mereka melakukan tugas-tugas lain yang memerlukan perubahan kode yang cepat dan proses yang lebih cepat.
Tidak ada solusi satu ukuran untuk semua untuk semua kasus: bagi seseorang, perampingan dan kecepatan proses itu penting, di suatu tempat mungkin perlu memiliki tangan yang kuat dan kendali total. Selain itu, pada tahapan yang berbeda dari pengembangan produk yang sama, pendekatan yang berbeda mungkin diperlukan, yang saling menggantikan. Masing-masing memiliki pro dan kontra sendiri, dan berdasarkan itu, kami sampai ke posisi kami sekarang.
Jadi kemana kita pergi di Wrike?
Opsi apa yang kita pilih dengan cara kita sendiri untuk memiliki kode?
Sangat pribadi. Kami bahkan belum mempertimbangkan ini. Sekarang, jika Gennady melarang pembuatan permintaan tarik ke perpustakaannya, dan dia melakukan semua perubahan secara pribadi, Anda mendapatkan pendekatan yang sangat pribadi. Tentunya Gennady memulai dengan cara ini.
Salah satu kelemahan yang jelas dari pendekatan ini adalah totaliterisme di dunia pembangunan. Gennady tanpa berlebihan adalah satu-satunya orang di Bumi yang benar-benar mengetahui kode tersebut, memiliki (atau tidak) rencana untuk pengembangannya dan dapat mengubahnya. Bus yang sama, yang merupakan "faktor bass", telah meninggalkan tikungan. Jika Gennady terkena flu, kemungkinan besar, proyek itu akan jatuh bersamanya. Pengembang lain harus bercabang, akan ada banyak, dan kekacauan total akan terjadi.
Pendekatan ini memiliki satu nilai tambah - pendekatan pembangunan yang terkonsolidasi sepenuhnya. Satu orang membuat semua keputusan tentang arsitektur, gaya kode, dan secara pribadi memecahkan masalah apa pun. Tidak ada overhead komunikasi.
Pribadi bersyarat. Inilah yang sebenarnya tidak ingin dilakukan Gennady: awasi semua MR, berikan kesempatan untuk mengubah kode perpustakaannya kepada orang lain, tetapi memiliki kendali penuh atas perubahan tersebut dan berhak memveto. Pro dan kontra sama seperti di paragraf sebelumnya, tetapi sekarang mereka sedikit diperhalus dengan kemampuan untuk mengirim permintaan tarik ke pengembang pihak ketiga langsung ke repositori, dan tidak membuat spesifikasi teknis untuk implementasi beberapa fitur.
Kolektifseperti Cedar Beavers. Dalam hal ini, seluruh tim bertanggung jawab atas kode tersebut, dan anggotanya sendiri yang memutuskan siapa yang akan mengawasi permintaan mana.
Di antara kelebihannya, seseorang dapat mencatat tingginya kecepatan meninjau ulasan, distribusi keahlian di antara anggota tim, dan penurunan faktor bus. Tentu saja, ada juga kekurangannya. Dalam perbincangan di internet, banyak yang menyebut kurangnya tanggung jawab jika “disebarkan” di antara beberapa orang. Tetapi itu tergantung pada struktur tim dan budaya pengembang: Pengembang Senior atau pemimpin tim dapat bertanggung jawab atas tim, kemudian dia akan menjadi titik masuk untuk pertanyaan. Dan MR dan menulis fitur baru dapat dibagi sesuai dengan tingkat pelatihan pengembang. Bagaimanapun, akan salah untuk memberikan pemula yang baru mulai memahami arsitektur aplikasi untuk memfaktor ulang kode.
Di Wrike, kami mengambil pendekatan kolaboratif untuk kepemilikan kode, dengan pemimpin tim sebagai tanggung jawab utama. Orang ini memiliki keahlian paling banyak dalam kode, tahu pengembang mana yang kompeten dalam meninjau kompleksitas tertentu, dan memikul tanggung jawab penuh atas kualitas kode tim.
Tetapi jalan menuju implementasi teknis dari solusi ini bukanlah yang termudah. Ya, dengan kata-kata semuanya terdengar cukup mudah: inilah fiturnya, ini perintahnya. Tim tahu apa yang menjadi tanggung jawabnya, artinya akan memantaunya.
Perjanjian semacam itu dapat berfungsi sebagai kontrak verbal jika jumlah perintah kurang dari jumlah jari di satu tangan. Dan dalam kasus kami, itu lebih dari tiga puluh perintah dan jutaan baris kode. Selain itu, sering kali batasan fitur tidak dapat ditentukan oleh repositori: ada integrasi yang cukup dekat dari beberapa fitur ke fitur lainnya.
Panel filter di sebelah kanan sama untuk semua tampilan. Ini adalah fitur dari tim "A". Selain itu, semua tampilan adalah fitur dari tiga tim lainnya.
Contoh paling jelas adalah filter. Tampilan dan perilakunya sama di semua kemungkinan tampilan, sementara tampilan itu sendiri mungkin berbeda dalam fungsi. Artinya, tampilan milik satu tim, dan satu panel filter milik tim lain. Dan lusinan repositori, ribuan file dengan kode berbeda. Siapa yang harus Anda tinjau jika Anda perlu membuat perubahan pada file tertentu?
Pada awalnya kami mencoba menyelesaikan masalah ini dengan file JSON sederhana yang ada di root repositori. Ada penjelasan tentang fungsionalitas dan nama orang yang bertanggung jawab. Mereka dapat dihubungi untuk mendapatkan tinjauan untuk permintaan penarikan mereka.
Ini seperti model kepemilikan kode pribadi bersyarat. Satu-satunya pengecualian adalah tidak ada satu orang yang terdaftar sebagai penanggung jawab, tetapi dua atau tiga orang. Tetapi pendekatan ini tidak pernah berhasil untuk kami: orang-orang beralih ke tim lain, jatuh sakit, pergi berlibur, berhenti, dan setiap kali kami harus terlebih dahulu mencari seseorang yang menggantikan pemilik yang ditentukan, lalu memberi tahu pemilik untuk mengubah nama secara manual dan mendorong perubahan.
Kemudian, mereka berpindah dari orang-orang tertentu ke menentukan perintah.Namun, semuanya ada di file JSON yang sama. Itu tidak jauh lebih baik, karena sekarang perlu untuk menemukan anggota tim yang kode dapat dikirimkan untuk ditinjau. Dan kami memiliki ratusan (sedikit licik, hampir 70) pengembang front-end, dan tidak mudah untuk menemukan semua peserta pada saat itu. Sistem kepemilikan telah menjadi kolektif, tetapi menemukan orang yang tepat terkadang tidak lebih mudah daripada mencari wakil pemilik dari versi sebelumnya. Ditambah masalah dengan kode, di mana beberapa fitur dapat berpotongan, masih tidak dapat diselesaikan.
Oleh karena itu, sangat penting untuk menyelesaikan dua pertanyaan: bagaimana menetapkan fitur individu ke tim tertentu dalam repositori tim lain dan bagaimana membuat informasi sederhana dan dapat diakses untuk semua tim yang mungkin memiliki kode.
Mengapa alat yang sudah jadi tidak cocok untuk kami. Ada alat di pasar untuk menugaskan orang untuk meninjau dan menghubungkan individu tertentu dengan kode. Saat menggunakannya, Anda tidak perlu membuat file dengan nama orang yang perlu Anda jalankan jika ada ulasan, bug, pemfaktoran ulang yang rumit.
Di Azure DevOps Services memiliki fungsionalitas - Secara otomatis menyertakan peninjau kode. Nama tersebut berbicara sendiri, dan salah satu mantan kolega saya mengatakan bahwa mereka menggunakan alat ini di perusahaan mereka dan sangat berhasil. Kami tidak bekerja dengan Azure, jadi akan sangat menyenangkan mendengar dari pembaca bagaimana kabarnya dengan autoreviewer.
Kami menggunakan GitLab, jadi akan logis untuk melihat ke Pemilik Kode GitLab. Tetapi prinsip pengoperasian alat ini tidak cocok untuk kami: fungsionalitas GitLab adalah sekumpulan jalur dalam repositori (file dan folder) dan orang-orang melalui akun mereka di GitLab. Bundel ini ditulis ke file khusus - codeowners.md. Kami membutuhkan banyak jalur dan fitur. Selain itu, fitur kami terdapat dalam kamus khusus, di mana fitur tersebut ditetapkan ke perintah. Ini memungkinkan Anda untuk menandai fitur kompleks yang mungkin ada di lebih dari satu repositori, dikembangkan oleh beberapa tim, dan, sekali lagi, tidak terikat pada nama tertentu. Selain itu, kami berencana untuk menggunakan informasi ini untuk membuat direktori tim yang nyaman, fitur terkait, dan semua anggota tim.
Hasilnya, kami memutuskan untuk membuat sistem kontrol kepemilikan kode kami sendiri. Penerapan versi pertama sistem kami didasarkan pada kemampuan Dart SDK , karena pada awalnya diluncurkan untuk repositori departemen front-end dan hanya untuk file Dart. Kami menggunakan tag meta kami sendiri (untungnya, ini didukung di tingkat bahasa), lalu kami menjalankan semua file sumber dengan penganalisis statis dan membuat sesuatu seperti tabel: File / Fitur - perintah Pemilik. Anda dapat menandai file individual dan seluruh jalur dengan beberapa folder.
Setelah beberapa waktu, markup dengan fitur menjadi tersedia untuk kode di Dart, JS, dan Java, dan ini adalah keseluruhan basis kode: frontend dan backend. Untuk mendapatkan informasi tentang pemilik, penganalisis statis digunakan. Tapi, tentu saja, ini tidak sama dengan versi pertama dan hanya berfungsi dengan kode Dart. Misalnya, untuk file Java, perpustakaan javaparser digunakan . Penganalisis ini berjalan sesuai jadwal dan mengumpulkan semua informasi yang relevan dalam satu registri.
Selain mengikat kode tertentu ke tim pemilik, kami membangun integrasi dengan layanan untuk mengumpulkan kesalahan dalam produksi dan memposting semua informasi berguna tentang tim dan fitur di sumber daya internal. Sekarang setiap karyawan dapat melihat kepada siapa harus lari jika mereka tiba-tiba memiliki pertanyaan dalam tampilan tertentu. Dan kami juga membuatnya otomatis untuk membuat tugas bagi mereka yang bertanggung jawab jika terjadi beberapa perubahan global, seperti berpindah ke versi baru Dart atau Angular.
Dengan mengklik perintah, Anda dapat melihat semua fitur, semua anggota tim, fitur mana yang murni teknis, dan yang merupakan produk
Hasilnya, kami tidak hanya mendapatkan sistem yang agak fleksibel untuk menghubungkan fitur dengan tim, tetapi juga infrastruktur lengkap yang membantu, mulai dari kode, untuk menemukan fitur terkait, tim dengan semua peserta, pemilik produk dari suatu fitur, dan laporan bug.
Di antara kelemahannya adalah kebutuhan untuk memantau markup fitur dengan cermat saat melakukan refactoring dan mentransfer kode dari satu tempat ke tempat lain, dan kebutuhan akan kekuatan tambahan untuk mengumpulkan semua informasi tentang markup.
Bagaimana Anda mengatasi masalah kepemilikan kode Anda? Dan apakah ada masalah terkait dan, yang terpenting, solusinya?