Utang teknis seperti tetris

Menang tidak mungkin. Anda hanya memutuskan seberapa cepat kalah


Apa langkah selanjutnya?

Banyak orang menyukai tetris, saya juga. Saya ingat bermain teman saya untuk pertama kalinya di Nintendo Game Boy. Mungkin lagu itu juga terjebak di kepala Anda. Tetris tidak hanya salah satu game terbaik sepanjang masa, tetapi juga analogi yang bagus untuk hutang teknis. Ini memberikan pemahaman umum tentang utang teknis dan dampaknya.

Saya akan menceritakan kepada Anda sebuah kisah dari pengalaman pribadi bagaimana tim saya mengurangi hutang teknis dalam beberapa jenis kode tagihan dan pada saat yang sama memperbaiki kesalahan tersebut dengan satu juta dolar setahun .


Pada awalnya, tugas lebih sederhana, pada tingkat kesulitan yang rendah

Di perusahaan perangkat lunak, manajer produk / proyek, bersama dengan pengembang, menentukan kode mana yang akan ditulis dan dikirim ke pelanggan pada rilis berikutnya. Menyelesaikan garis dalam tetris seperti melepaskan fungsi.


Fungsi kompleks sepenuhnya layak dengan hampir tidak ada peningkatan utang teknis

Mengeluarkan fungsi yang kompleks membutuhkan penyelesaian beberapa baris .

Seringkali, kebutuhan bisnis (fitur baru, produk baru) mengarah pada kompromi dalam kode (peretasan, penyelesaian masalah) agar tidak melewati batas waktu. Atau perubahan dalam strategi produk tidak sesuai dengan desain sebelumnya, membutuhkan upaya tambahan untuk memigrasikan pelanggan atau mendukung logika "baru" dan "lama".


Utang teknis kecil adalah normal dan dapat dikelola.

Skenario semacam itu menciptakan utang teknis dalam kode. Lulus tersembunyi di Tetris adalah tugas teknis.

Kode apa pun memiliki tugas teknis. Ini normal. Anda dapat terus bermain dengan beberapa operan.


Terkubur dalam hutang teknis

Terlalu banyak hutang teknis tidak memungkinkan waktu yang wajar untuk merilis fungsi baru atau memperbaiki bug.

Masalah ini tidak dapat diselesaikan dengan menambahkan pengembang baru atau, lebih dramatis, mengganti yang sudah ada. Ini disebut utang teknis: pada titik tertentu harus dibayar.

Melunasi hutang teknis Anda membuat Anda kompetitif. Itu membuat Anda tetap dalam permainan.


Game usai

Seperti manajemen bisnis, di Tetris, kompleksitas meningkat seiring waktu. Bentuk bergerak lebih cepat dan lebih sulit untuk mengikuti.

Seperti dalam bisnis, tidak mungkin menang di sini. Tidak ada garis akhir yang nyata. Satu-satunya pertanyaan adalah seberapa cepat Anda akan kalah.

Seperti halnya bisnis, terlalu banyak celah dalam tetris menyebabkan kerugian.

Bug jutaan dolar


Belum lama ini, tim saya diperintahkan untuk memperbarui logika penagihan / faktur dalam kode produk kami untuk mendukung rencana penetapan harga baru, prosesor pembayaran baru, dan untuk meningkatkan keseluruhan proses penagihan secara keseluruhan. Beberapa detail masih diklarifikasi, jadi kami menggunakan waktu ini untuk menggali lebih dalam ke kode yang ada untuk memberikan perkiraan yang lebih akurat dari perubahan yang akan datang.

Tugas utama kode ini adalah menelusuri akun semua pelanggan, menghitung masing-masing, dan mengirim informasi ke API untuk faktur. Sistem ini ditulis dengan sangat hati-hati dan niat baik - tidak seburuk yang tidak fleksibel. Fungsi monolitik . Tidak ada tes. Sangat sedikit log. Praktis tidak ada dokumentasi. Ada beberapa pengacakan yang tidak bisa dijelaskan. Salah satu pendiri menulis sistem lebih dari lima tahun yang lalu. Satu-satunya perubahan sejak itu dilakukan oleh salah satu karyawan pertama yang sudah absen dari perusahaan.

Apakah ada masalah? Faktur ditagih. Perusahaan menghasilkan uang. Tidak ada tanda-tanda masalah. Semua ini berbicara menentang refactoring, tetapi kami tahu bahwa perubahan besar akan datang: fungsi ini tidak dapat ditingkatkan untuk kebutuhan kami, dan akan lebih mudah untuk melanjutkan jika kami menyederhanakan bagian ini.

Dalam satu sprint, kami mendesain ulang fungsi dan menambahkan beberapa log yang sangat dibutuhkan. Saat itulah kami menemukan bahwa kami telah benar-benar memperbaikinya. Salah satu akuntan berhenti di meja kami dan bertanya mengapa jumlah faktur keluar tiba-tiba meningkat. Kode lama diam-diam jatuh pada timer - dan beberapa klien tidak diproses. Pengacakan yang aneh? Dia menyembunyikan model apa pun yang bisa menjelaskan bahwa beberapa klien tidak mengeluarkan faktur. Ketika kami melakukan penilaian, kami menghitung faktur yang hilang lebih dari $ 1 juta per tahun.

Pembayaran tidak selalu menghasilkan


Meskipun ceritanya sepenuhnya benar, melunasi hutang teknis tidak selalu memiliki efek dramatis. Kita beruntung.


Temukan keseimbangan utang teknis yang tepat

Saya ingin memberikan nasihat bijak ketika Anda harus melunasi hutang teknis. Sayangnya, jawabannya adalah sulit - dan selalu turun ke keseimbangan . Anda mungkin memiliki kode terbersih dan teruji di dunia, tetapi tidak memiliki klien. Dan sebaliknya, perusahaan Anda dapat bekerja dalam kode yang benar-benar kotor, tetapi yang menyenangkan pelanggan, dan uang mengalir seperti sungai.

Saya hanya dapat mengatakan bahwa baik pemilik produk dan pengembang harus memahami esensi hutang teknis dan bahwa itu tidak dapat dihindari selamanya. Pada akhirnya, seperti dalam Tetris, di sini Anda tidak akan pernah bisa menang.

Source: https://habr.com/ru/post/id443896/


All Articles