Mudah mempertahankan budaya perusahaan dengan kata-kata. Namun, hanya beberapa perusahaan yang secara aktif mengeksplorasi beberapa fitur budaya perusahaan yang memiliki dampak signifikan terhadap produktivitas - karena ini adalah yang paling sulit.
Untuk tim perangkat lunak, kepemilikan kode adalah prediktor kunci dari kesejahteraan teknik. Dalam panduan praktis ini, kami akan menganalisis bagaimana Anda mengintegrasikan prinsip ini ke dalam pekerjaan sehari-hari tim pengembangan Anda, sehingga kesejahteraan basis kode Anda dipertahankan dengan sendirinya.
Saya cukup beruntung bisa bertemu dengan beberapa pengembang terbaik di dunia - di Stepsize saya bekerja dengan mereka setiap hari. Dan selama diskusi tentang bagaimana utang teknis dibuat, dengan pengembang perusahaan terkemuka seperti Skyscanner, Spotify, Palantir, dan lainnya, satu pertanyaan selalu muncul: kepemilikan.
Dalam tim yang berinteraksi erat dan berkembang dengan cepat (yah, yaitu dalam tim modern), di mana pengembang dapat berkomitmen pada bagian basis kode mana pun, kode tersebut mudah berantakan dan menjadi monster yang mirip dengan Frankenstein. Dan ketika segalanya menjadi cukup buruk, seseorang harus turun tangan, seperti Kapten Marvel, dan memperbaikinya dengan satu refactoring besar.
Untuk menghindari situasi ini, tim pengembangan mencoba mematuhi salah satu dari banyak tips hebat Robert S. Martin ("Paman Bob"), yaitu " Aturan Pramuka ": menjaga kode dalam kondisi yang lebih baik daripada sebelum Anda . Berikut ini adalah ekstensi gratis untuk VSCode untuk membantu Anda menjadikan ini jauh lebih mudah .
Namun demikian, terlepas dari tingkat keterampilan dan insentif terbaik dari para pengembang, tampaknya hukum pengembangan perangkat lunak yang tidak dapat diubah adalah bahwa utang teknis menumpuk - sampai menjadi terlalu banyak, dan kemudian kita harus meluangkan waktu untuk banyak refactoring . Kami enggan menerima ini sebagai bagian dari siklus hidup pengembangan perangkat lunak.
Mungkin itu semua terjadi karena kurangnya disiplin?
Jadi saya pikir sebelumnya. Dan kemudian saya bertemu Gareth Vizaji , kepala arsitek di Snyk.io , dan dia memukul saya dengan frasa berikut:
Kepemilikan adalah indikator utama dari kesejahteraan teknik.
Apa yang dia maksud? Dan bagaimana dia bisa membuat pernyataan seperti itu?
Ada sejumlah besar penelitian yang menunjukkan bahwa ketika anggota tim memiliki hasil kerja mereka, bertanggung jawab kepada manajer dan bertanggung jawab atas keberhasilan dan kegagalan, segala macam hal baik mulai terjadi.
Sayangnya, mencapai ini dalam praktik tidaklah mudah. Sebagian karena, tampaknya, produktivitas rekayasa tidak dapat diukur , dan praktik pembangunan modern dapat dilihat sebagai mendorong kepemilikan kode yang buruk dalam keadaan apa pun. Yang benar adalah bahwa sampai sekarang sangat sulit untuk mengukur kepemilikan dalam tim pengembangan dengan benar ... jadi kami bahkan tidak tahu seberapa "baik" kelihatannya untuk indikator ini.
Untungnya, penelitian ilmiah baru-baru ini menunjukkan bahwa kepemilikan kode - ukuran tidak langsung terbaik dari gagasan "kepemilikan" yang tidak jelas dalam tim pengembangan - dapat diukur dengan aktivitas Git commit. Dan ini adalah indikator utama yang luar biasa dari kesejahteraan basis kode Anda.
Bagian-bagian dari basis kode yang membuat banyak pengembang melakukan perubahan menjadi berantakan seiring waktu, dan mereka yang bekerja dengan lebih sedikit orang biasanya dalam kondisi yang lebih baik. Jangan mengambil kata saya untuk itu - orang baik dari Microsoft telah mempelajari ini dengan contoh mereka sendiri.
Sumber: studi Microsoft
Saya hampir dapat mendengar beberapa dari Anda berteriak bahwa Anda tidak menginginkan situasi di mana hanya satu pengembang adalah satu-satunya orang yang diizinkan menyentuh sepotong kode - pendekatan ini memiliki efek samping yang mengerikan. Saya mengerti Anda, dan ini bukan yang kami tawarkan.
Dengarkan aku sampai akhir.
Ada berbagai bentuk kepemilikan kode yang cocok untuk keadaan yang berbeda.
Kepemilikan bersama dan kurangnya kepemilikan
Kepemilikan bersama adalah [...] kepemilikan di mana kode dimiliki bersama, tetapi tanggung jawab dan jadwal didefinisikan dengan jelas. Setiap anggota tim dapat bekerja pada subsistem atau layanan apa pun, jika perlu.
Non-kepemilikan - [...] situasi di mana beberapa pengembang membuat perubahan pada subsistem yang sama, tetapi koordinasi tindakan, tanggung jawab untuk kualitas atau komunikasi dalam tim sangat minim. Dalam sistem seperti itu, seseorang seharusnya tidak mengharapkan pekerjaan yang berkualitas tinggi.
Sumber: studi Microsoft
Anda dapat melanjutkan partisi ini lebih lanjut dengan menambahkan ke heap juga kode tanpa pemilik dan kepemilikan tunggal, tetapi saya tidak ingin ketinggalan hal utama, jadi di sini adalah grafik yang menunjukkan spektrum bentuk kepemilikan kode:
Kepemilikan bersama harus menjadi pilihan default Anda dan bentuk kepemilikan yang harus Anda perjuangkan. Perhatikan bahwa ini tidak berarti bahwa hanya satu pengembang di tim Anda yang memiliki izin untuk mengubah kode, atau bahwa modifikasi kode apa pun memerlukan persetujuannya. Ini hanya berarti bahwa sangat jelas bagi semua orang di tim dengan siapa dia harus mendiskusikan pertanyaan yang dia miliki, dan bahwa pemilik kode kemungkinan besar akan menghadapi peninjauan kode (review kode). Ini akan memungkinkan semua orang di tim untuk meningkatkan standar penulisan kode dan menyadari bagaimana kode mereka sendiri telah dimodifikasi.
Pemilik bertanggung jawab atas status kode-nya, dan manajer harus meminta ini darinya. Ini tidak berarti bahwa ia harus dikalahkan di kepala untuk setiap bug yang bocor ke kode-nya; ini berarti bahwa pemilik berwenang untuk membuat keputusan mengenai kualitas kode dan hutang teknis; mereka akan dimintai pertanggungjawaban atas keputusan ini dengan metrik pendukung tambahan, seperti kohesi dan aktivitas berulang (churn) (untuk detail lebih lanjut, lihat artikel kami tentang metrik hutang teknis ).
Kurangnya kepemilikan, atau kepemilikan yang lemah, adalah kebalikan dari kepemilikan kolektif, dan dalam kebanyakan kasus bentuk kepemilikan ini harus dihindari. Seperti yang telah disebutkan (dan ini mungkin terdengar jelas) untuk file seperti package.json tidak memiliki pemilik yang jelas adalah situasi normal. Pergi ke ekstrem tidak perlu.
Kode yatim
Jenis paling tidak menyenangkan dari kurangnya kepemilikan, salah satu ujung spektrum bentuk kepemilikan kode. Anda pasti tidak membutuhkan bentuk kepemilikan ini. Menghindarinya dengan cara apa pun ... kecuali itu, tentu saja, kode yang tidak akan pernah Anda sentuh lagi. Tetapi kode seperti itu sangat jarang.
Kode dianggap tidak memiliki pemilik jika pengembang utamanya berhenti membuat perubahan apa pun pada basis kode. Mungkin dia meninggalkan organisasi, atau mungkin pindah dari pengembang ke manajer. Bagaimanapun, Anda memiliki masalah serius - dan basis kode Anda juga.
Namun, ada solusinya. Anda perlu menerjemahkan kode sumber ke bentuk kepemilikan apa pun lainnya yang paling sesuai untuk itu. Untuk menghindari kemunculan kode tanpa pemilik dalam basis kode Anda, pastikan bahwa rencana Anda untuk kasus pemberhentian atau rujukan kasus mencakup memasukkan pemilik baru kode tersebut ke dalam perjalanan urusan pemilik lama. Anda dapat membuatnya lebih mudah dengan menetapkannya secara otomatis untuk melihat permintaan tarik untuk perubahan kode. Jika tidak ada, Anda dapat dengan mudah menunjuk pemilik kode sesuai keinginan Anda.
Apa pun metode yang Anda pilih, jangan biarkan kode tanpa pemilik tergantung di basis kode Anda. Anda tidak pernah tahu apa yang akan terjadi padanya jika Anda menyerahkannya pada takdir nasib.
Kepemilikan tunggal (kepemilikan absolut)
Ini adalah ujung lain dari spektrum kepemilikan kode. Dengan dia, semuanya bisa menjadi indah dan sangat sulit.
Kode dianggap sebagai kepemilikan tunggal ketika pemilik adalah satu-satunya pengembang yang dapat membuat atau menyetujui perubahan pada kode, atau ketika pemilik, pada dasarnya, satu-satunya orang yang pernah membuat perubahan pada kode di masa lalu.
Startup kecil sering menemukan praktik serupa dalam pekerjaan mereka. Setiap pengembang, sebagai suatu peraturan, bertanggung jawab atas seluruh riwayat satu file, dan diharapkan kepemilikan file ini tetap dipertahankan. Ini bukan akhir dunia; startup, bagaimanapun, memiliki sumber daya yang terbatas, dan Anda perlu membuat pengorbanan tertentu. Tetapi jika suatu hari pengembang memindahkan bus, bagian dari kode ini akan menjadi tanpa pemilik. Untuk situasi seperti itu, Anda harus memiliki rencana cadangan.
Dalam organisasi rekayasa yang lebih besar, “ faktor bus ” yang rendah dapat menjadi masalah nyata, terutama ketika menyangkut bagian-bagian penting dari basis kode, pergantian staf tinggi, dan utang teknis yang direkrut oleh perusahaan terlalu besar. Misalnya, jika pengembang yang membuat seluruh sistem pembayaran yang dikonfigurasikan secara manual berhenti, Anda akan mengalami sakit kepala hebat - jika Anda ingin mengubah model penetapan harga Anda, atau jika Anda menemukan bug dalam basis kodenya yang menyebabkan Anda selama berbulan-bulan mereka menerima lebih sedikit uang dari pelanggan terbesar mereka. Maka seseorang harus berkumpul dan mencoba memahami kode untuk mengubahnya, atau Anda harus menyatakan kebangkrutan teknis pada sistem pembayaran Anda dan menulis ulang dari awal (tetapi sebelum melakukan ini, baca ini ).
Jangan biarkan ini terjadi pada Anda.
Namun, ada kalanya kepemilikan satu-satunya terhadap kode dapat diterima atau bahkan direkomendasikan. Anda mungkin ingin membuat bentuk kepemilikan ini untuk bagian-bagian dari basis kode di mana pernyataan “jika bagian ini rusak, kami dapat melipat, karena dengan demikian bisnis tidak akan dapat membayar kami gaji atau kami akan masuk penjara”.
Dalam kasus seperti itu, bahkan jika Anda ingin menyebarkan pengetahuan tentang bagian penting dari kode di antara beberapa pengembang untuk mempertahankan faktor bus yang cukup tinggi, Anda mungkin juga ingin menetapkan aturan yang melarang injeksi permintaan tarik tanpa persetujuan dari pemilik tunggal kode yang sesuai.
Ringkasan
Berjuang untuk kepemilikan kolektif sebagian besar file dalam basis kode Anda (50% -90% dari kepemilikan kode untuk file apa pun yang diberikan), dan lebih disiplin untuk meningkatkan kepemilikan kode dan mengurangi hutang teknis bila diperlukan.
Manfaatnya adalah sebagai berikut:
- Standar penulisan kode yang lebih tinggi dan dirawat dengan baik. Dalam kelompok kecil, berpengetahuan luas, mematuhi standar tinggi lebih mudah. Ini berlaku tidak hanya untuk pengembang memodifikasi kode mereka sendiri, tetapi juga untuk ulasan kode yang ditulis oleh rekan-rekan mereka dan mempengaruhi bagian yang mereka miliki.
- Memfasilitasi komunikasi. Kepemilikan yang jelas dan jelas berarti bahwa setiap pengembang dalam tim tahu siapa yang akan menjawab pertanyaannya.
- Refactoring yang lebih fokus dan efektif. Jika Anda memutuskan untuk melunasi sebagian hutang teknis, pengembang kuat yang memiliki kode yang sesuai paling cocok untuk pekerjaan ini. Gunakan kepemilikan, konektivitas, dan metrik aktivitas berulang untuk menguraikan bidang yang menjadi perhatian dalam basis kode Anda. Pengembang Anda akan menggunakan anggaran mereka untuk utang teknis dengan bijak dan tidak pernah lagi menghabiskan waktu untuk membayar utang teknis yang tidak sepadan.
- Faktor bus tidak akan pernah lepas kendali. Anda dapat menggunakan kepemilikan kode untuk mengatur berbagi pengetahuan di organisasi Anda. Jika tingkat kepemilikan terlalu tinggi, tetapkan pengembang lain untuk meninjau kode dan tugas yang terkait dengan mengubahnya. Anda secara bertahap akan meningkatkan indikator kepemilikan Anda, yang akan mengarah pada peningkatan kualitas kode dan penurunan utang teknis.
Seperti segala sesuatu yang benar-benar berharga, menciptakan budaya rekayasa kepemilikan kode (dan mengikutinya!) Membutuhkan waktu dan upaya, tetapi akan terbayar dengan bunga. Faktor ini secara langsung mempengaruhi hampir semua kesejahteraan teknik KPI yang dapat Anda bayangkan. Tanamkan dalam budaya perusahaan Anda, dan dalam jangka panjang itu akan menjadi keunggulan kompetitif besar Anda.