Hutang teknis: setiap orang memilikinya, dan setiap pengembang yang layak atas hak milik mereka ingin melunasinya, tetapi bagaimana Anda mengatur proses ini?

Kami menerapkan rotasi tanaman

Dalam artikel saya sebelumnya, saya membandingkan pembayaran hutang teknis dengan pentingnya rotasi tanaman di pertanian. Jika Anda terus memproses bidang (basis kode) musim demi musim untuk mendapatkan panen besar (menyelesaikan proyek, menambah fitur, dll.), Dan tidak memberi bidang ini musim untuk pulih (pembayaran hutang teknis), maka itu secara bertahap mulai kehilangan kualitas dan produktivitasnya.



Metafora ini tetap sesuai untuk pengembangan perangkat lunak; Selain itu, dokumen ini berisi petunjuk tentang kemungkinan strategi yang dapat digunakan untuk melunasi utang teknis.



Ada banyak sekali cara untuk melunasi hutang. Dan ini sangat berguna karena memberi kita banyak pilihan perencanaan.



Untuk keperluan artikel ini, kami akan berasumsi bahwa Anda bekerja dalam metodologi pengembangan yang gesit, tetapi banyak prinsip, jika disempurnakan secara kreatif, berlaku untuk metodologi lain.

Sprint khusus untuk melunasi hutang teknis

Dalam analogi penuh dengan rotasi tanaman, kita dapat berhenti mengerjakan fitur setiap sprint keempat atau lebih, mengalokasikannya hanya untuk melunasi hutang teknis.



Kelebihan:

• Pengembang memiliki dorongan yang sama untuk fokus hanya pada melunasi utang teknis
• Pengembang dapat berkoordinasi untuk melunasi sebagian besar utang teknis dengan bekerja bersama-sama
• Bisnis termotivasi untuk mempelajari hasil hutang teknis yang menunjukkan pentingnya pekerjaan dan volume yang tersisa.

Minus:

• Konflik penggabungan mulai muncul saat karyawan membuat volume perubahan arsitektur yang lebih besar.
• Dengan kekacauan dan ketidakstabilan ini, sulit untuk mengetahui apakah ada yang rusak jika tidak ada cakupan tes yang baik.
• Hanya karena Anda mengerjakan hutang teknis, insiden dukungan tidak pernah hilang. Tanpa staf untuk membantu eskalasi permintaan dukungan, utang teknis dijamin akan terhambat oleh dukungan.

Kapasitas Khusus untuk pembayaran hutang teknis

Dalam model ini, tim agile menyimpan sejumlah poin atau persentase tertentu dari total kapasitas sprint untuk membayar hutang teknis secara berkelanjutan. Misalnya, dalam setiap sprint, sebuah tim dapat mengambil 5 storypoins dari berbagai pekerjaan pembayaran hutang.



Kelebihan:

• Ini memastikan bahwa pelunasan hutang teknis adalah bagian dari budaya organisasi yang sedang berjalan.
• Pekerjaan hutang teknis yang sedang berlangsung dapat menghalangi kebutuhan untuk lebih banyak pekerjaan di masa depan.

Minus:

• Jika perubahan perlu dilakukan pada sprint, mengerjakan hutang teknis akan menjadi kandidat yang paling mungkin untuk dikeluarkan dari sprint.
• Dengan membatasi pekerjaan Anda pada hutang teknis menjadi jumlah kecil, Anda mempersulit penghapusan potongan hutang teknis yang terkadang besar.

Mendedikasikan karyawan untuk melunasi hutang teknis

Ini adalah gabungan dari dua opsi terakhir. Setiap sprint memilih satu pengembang untuk mengerjakan hutang teknis sementara yang lainnya melanjutkan pekerjaan normal mereka.



Kelebihan:

• , , .
• , ,

:

• ,
• , , capacity

Dalam model ini, ketika pengembang merencanakan pekerjaan mereka, mereka menambahkan rencana pembersihan kode tetangga dan pembayaran hutang teknis yang terdeteksi yang sudah ada di area kerja. Hal ini sejalan dengan prinsip Pramuka : selalu tinggalkan tempat parkir (basis kode) lebih bersih dari sebelumnya.



Dengan kata lain, ini menyiratkan bahwa ketika Anda menyentuh kode, itu akan menjadi lebih baik. Pada kode yang paling sering disentuh, Anda perlu membayar persentase tertinggi dari hutang teknis, jadi masuk akal untuk melunasi hutang di area kode yang sedang Anda kerjakan.



Konsep serupa ditemukan dalam buku Malcolm Gladwell The Tipping Point.misalnya dari kereta bawah tanah New York. Otoritas Transportasi Kota telah menemukan bahwa dengan melepaskan gerbong kereta bawah tanah, membersihkan coretan-coretannya dan memastikan bahwa tidak ada coretan sepanjang waktu, Anda dapat menghemat efek jendela yang pecah , di mana orang percaya bahwa kondisi gerbong tidak mengganggu. siapa saja dan tingkat kejahatan bisa meningkat. Dengan mengurangi jumlah kelinci dan grafiti, badan tersebut juga dapat mengurangi jumlah kejahatan kekerasan di kereta bawah tanah.



Jika kami mentransfer prinsip yang sama ke basis kode kami, maka kami perlu membuatnya sehingga ketika Anda menyentuh area kode, area tersebut dibersihkan dan hutang teknis terbayar.



Anda mungkin menebak dari apa yang Anda baca di atas bahwa saya adalah penggemar pendekatan ini, tetapi mari kita tetap pertimbangkan pro dan kontranya.



Kelebihan:

• Hutang teknologi terbayar di area yang secara alami lebih sering disentuh oleh pengembang
• Anda tidak perlu lagi "mengalokasikan ruang" untuk membayar hutang teknis, itu hanya bagian dari alur kerja
• Konflik penggabungan diminimalkan karena perubahan hanya dilakukan di daerah terpencil.

Minus:

• Tidak ada kesempatan khusus untuk melakukan perubahan besar yang mempengaruhi keseluruhan sistem
• Ini menyebabkan "penggelembungan" storypoint karena fakta bahwa pekerjaan tambahan perlu dilakukan dengan setiap tiket. Ini mengurangi jumlah pekerjaan yang bisa dilakukan di setiap sprint.

Revisi kode utama

Di atas, saya berbicara tentang strategi melunasi hutang teknis dengan mengganti bagian-bagian sistem secara bertahap, seperti dalam eksperimen pemikiran dengan kapal Theseus , tetapi bagaimana jika itu tidak cukup? Bagaimana jika Anda tidak punya waktu untuk mengganti semua perangkat lunak sepotong demi sepotong dan perlu melakukan perubahan yang lebih radikal?



Berikut beberapa ide untuk membantu Anda:

Memecah aplikasi menjadi aplikasi yang lebih kecil

Dengan metodologi ini, kami membagi aplikasi monolitik menjadi aplikasi yang lebih kecil. Seringkali pendekatan ini dilengkapi dengan Domain Driven Design dan / atau layanan mikro, tetapi poin utamanya adalah jika aplikasi terlalu besar untuk diganti, itu dapat dibagi menjadi beberapa bagian yang lebih kecil, penggantinya realistis, setelah itu Anda dapat mengganti masing-masing bagian satu demi satu.



Anda juga dapat mengimplementasikan skema ini menggunakan pola Aplikasi Pencekik Martin Fowler, yang membuat aplikasi baru yang menerima permintaan yang sama seperti yang lama dan membuat panggilan ke sistem lama hingga pengganti modern siap untuk masing-masingnya.



Kelebihan:

:

• ,

capacity

Dalam model ini, pengembang dapat menggunakan waktu luang atau waktu yang dialokasikan untuk hutang teknis untuk mengerjakan proyek jangka panjang, seperti mengganti sebagian atau seluruh aplikasi. Setelah kemajuan yang cukup telah dibuat dan pekerjaan dapat dimulai dengan sungguh-sungguh, tugas-tugas ini mulai diimplementasikan ke dalam seri sprint atau sprint untuk implementasi dan penyampaian formal.



Mengikuti pola ini, saya sangat berhasil dalam mem-porting aplikasi JavaScript ke TypeScript , termasuk menghabiskan waktu di luar pekerjaan (belum tentu, tetapi saya memutuskan untuk melakukannya) dan menunggu lingkungan pengujian regresi untuk online.



Kelebihan:

• Prototipe yang berpotensi rusak yang tidak terikat dengan siklus QA / pasokan formal dapat diidentifikasi dan ditangani
• Ketika pekerjaan siap untuk dimasukkan ke dalam sprint, itu biasanya merupakan pekerjaan yang sangat terkonsentrasi di mana sebagian besar variabel yang tidak diketahui diselesaikan.

Minus:

• Mungkin sulit untuk menemukan banyak waktu pembuatan prototipe di luar jadwal kecuali organisasi Anda ingin mengurangi alokasi sumber daya untuk proyek lain.

Transisi penuh ke aplikasi baru

Dalam model ini, semua pekerjaan pada aplikasi lama berhenti, kecuali untuk memperbaiki bug kritis, dan pekerjaan dimulai pada aplikasi, yang akan menjadi penggantinya yang lengkap. Inilah yang biasanya orang maksud ketika mereka berbicara tentang menulis ulang aplikasi.



Kelebihan:

• Karyawan dapat fokus pada sistem baru tanpa benar-benar mempertimbangkan sistem yang sudah ada.
• Total waktu eksekusi mungkin lebih sedikit

Minus:

• Dengan waktu pengiriman yang sangat singkat, bisnis mungkin merasa membuang-buang uang untuk proyek tersebut.
• Keterlambatan tenggat waktu dapat mengganggu pengiriman pekerjaan yang dibutuhkan
• Faktanya, pendekatan ini berubah menjadi prinsip semua atau tidak sama sekali.
• Mungkin tidak sepenuhnya mempertimbangkan semua risiko sebelum berinvestasi dalam proyek platform baru

temuan

Pertimbangkan opsi ini untuk terus memperbarui aplikasi, serta opsi yang lebih radikal. Menurut pendapat saya, tidak ada satu pun pilihan terbaik , Anda perlu mencari yang paling optimal untuk tim, produk, dan organisasi Anda. Evaluasi pendekatan ini dan tentukan opsi mana yang paling cocok untuk Anda saat menyiapkan "rotasi tanaman" untuk menjaga basis kode Anda tetap sehat dalam jangka panjang.