Apa itu Utang Teknis dan Bisakah Anda Menghindarinya?

Jika Anda berada dalam pengembangan perangkat lunak, Anda akan harus berurusan dengan utang teknis di beberapa titik. Jadi untuk menjawab pertanyaan di judul…tidak, Anda tidak bisa menghindarinya. Namun, ada beberapa langkah yang dapat Anda ambil untuk meminimalkan efeknya dan memastikannya tidak lepas kendali. Setidaknya terlalu buruk.

Apa itu Utang Teknis?

Hutang teknologi, seperti yang kadang-kadang disebut, pada dasarnya adalah biaya yang Anda keluarkan dari waktu ke waktu karena memiliki kode yang tidak sempurna. Perubahan dan pembaruan pada kode sumber memiliki biaya, seperti halnya menambahkan anggota baru ke tim pengembang, menambahkan fitur baru, atau memperbaiki bug dan menambal eksploit.

Saat proyek Anda semakin besar, basis kode berkembang, dan lebih banyak orang mengerjakan kode itu, suara dan gaya mereka akan berbenturan di sana-sini. Mungkin Anda memiliki tenggat waktu dan solusi yang kurang ideal ditambal ke dalam kode sumber untuk diselesaikan tepat waktu. Mungkin Anda menambahkan komponen sumber terbuka yang tidak sepenuhnya Anda pahami untuk menangani fitur alih-alih mengkodekannya sendiri. Atau Anda dapat mengganti pustaka antar versi (dari Backbone ke React, misalnya), tetapi masih perlu mendukung orang-orang yang menggunakan basis kode lama untuk proyek mereka.

Sama sekali tidak ada dari hal-hal ini yang buruk . Tidak sendiri. Mungkin tidak sama sekali. Tetapi ketika ditambahkan bersama-sama, hutang teknis yang mereka timbulkan harus dibayar kembali di beberapa titik di masa depan.

Pada titik tertentu, komponen sumber terbuka itu mungkin perlu diganti (atau bercabang). Itu akan menghabiskan waktu dan uang. Di masa mendatang, Anda harus menghapus semua kode Backbone dari proyek Anda dan berhenti mendukung pengguna lama. Sekali lagi, waktu dan uang. Patch yang Anda lakukan untuk memenuhi tenggat waktu? Yah, itu pada akhirnya akan dibatalkan dan membutuhkan perbaikan yang lebih permanen. Waktu dan uang. Dan Anda akan memiliki anggota baru dari tim Anda yang kembali melalui kode lama untuk melakukan semua ini, perlu memahami kode dan logika pengembang sebelumnya. Waktu. Uang.

Kau mengerti.

Sementara utang teknis adalah istilah abstrak, seringkali metaforis, biaya utang teknologi sangat nyata. Membayarnya kembali memiliki nilai moneter, dan Anda dapat melacak bunga yang Anda bayarkan dalam jam kerja dan slip gaji. Anda dapat melihatnya di garis bawah dari semua pengembangan perangkat lunak.

Bisakah Anda Menghindari Hutang Teknologi?

Seperti yang saya katakan sebelumnya… tidak juga, tidak. Anda akan memperoleh hutang teknis di setiap proyek yang Anda tulis jika Anda kembali ke kode setelah dirilis. Namun, jika Anda merinci jenis utang teknis, Anda dapat meminimalkan dan bahkan memperhitungkannya dalam proyek Anda. Jika Anda mempertimbangkan hutang terlebih dahulu, tidak ada bedanya dengan mengambil pinjaman mobil atau hipotek. Anda melihat biaya, bunga, dan manfaatnya, dan kemudian Anda memutuskan apakah Anda bisa/ingin membayarnya.

Mari kita lihat beberapa contoh yang telah kita bahas di atas dan lihat apakah ada cara untuk menghindari, meminimalkan, atau menyerap biaya.

Mempertimbangkan Utang Teknis yang Bertujuan

Ketika kami mengatakan utang teknis yang disengaja, yang kami maksudkan adalah bahwa tim Anda telah membuat keputusan yang Anda tahu tidak sesuai dengan apa yang disebut praktik terbaik baik untuk bahasa atau jenis proyek yang Anda kerjakan. Kami sebutkan sebelumnya bahwa Anda mungkin memiliki tenggat waktu untuk dipenuhi. Dan mungkin tenggat waktu itu keras dan cepat. Mungkin ada 0% kemungkinan itu diubah atau digeser.

Inilah saatnya Anda perlu mempertimbangkan untuk mengambil pinjaman dan masuk ke utang teknis.

Anda benar-benar memiliki tiga opsi di sini:

• Keluarkan perangkat lunak yang belum selesai dan bermasalah, tetapi Anda tidak membuat konsesi untuk kejelasan dan logika kode
• Tarik fitur yang tidak dapat Anda kelola dengan sempurna, tetapi lepaskan apa yang Anda miliki yang ditulis sebaik mungkin
• Buat keputusan pengembangan yang mengeluarkan kode "cukup baik" untuk menjalankan semuanya, tetapi kemungkinan perlu ditangani lagi nanti

Opsi ketiga di sini sering menjadi pilihan orang. Itu akan menjadi utang teknis. Dan tidak ada yang salah dengan ini. Karena Anda membuat keputusan untuk melakukannya .

Membayar Kembali Pinjaman Utang yang Bertujuan

Pastikan Anda mendokumentasikan keputusan di balik pilihan untuk menempuh rute ini dalam kode Anda. Catat apa yang Anda lakukan versus apa solusi idealnya. Dan pastikan Anda menyertakan setidaknya beberapa jenis komentar dalam kode sumber untuk menunjukkan di mana solusi pengambilan utang ini diterapkan (dan jika Anda tahu, sistem yang terpengaruh di area lain dari proyek). Jika Anda tidak mengambil langkah ini, menambahkan proyek (bahkan dalam perbaikan bug dan tambalan, belum lagi fitur baru atau basis kode yang diperluas) dapat sangat tertunda dengan menemukan solusi tambal sulam saat Anda mengharapkan solusi lengkap.

Sekali lagi, solusi tambal sulam itu mungkin baik-baik saja dan tidak pernah memberi Anda masalah nyata. Tapi utang teknis masih ada dan perlu dipertanggungjawabkan.

Mempertimbangkan Hutang Teknis Kode Warisan

Jenis hutang teknis umum lainnya adalah yang banyak diakumulasi WordPress saat ini. WordPress dapat berjalan di PHP 5.x. Pembaruan terbaru, bagaimanapun, akan memberi tahu pengguna bahwa itu setidaknya harus PHP 5.6. Pada akhir 2019, WP Core akan membutuhkan PHP 7.x. Namun, dengan mendorong persyaratan ke atas, banyak kode lama yang harus diperbarui. Karena masih ada kode PHP 5.x di plugin, theme, dan Core itu sendiri.

Belum lagi Editor Blok baru. Itu ditulis dalam JavaScript. Bereaksi, khususnya. Itu tidak ada apa-apanya di dekat PHP. Faktanya, sebagian besar WordPress Core sedang ditulis ulang ke dalam JavaScript, sedikit demi sedikit. Tapi semua itu JS harus pujian dan cocok dengan PHP juga. Mengambil teknologi baru itu bagus, dan mengadopsi persyaratan versi baru diperlukan. Tetapi dengan melakukan itu, Anda membayar bunga atas hutang teknis yang tidak dapat dihindari yang Anda timbulkan dari perangkat lunak yang telah ada untuk sementara waktu.

Membayar Kembali Hutang Kode Warisan

Yang ini agak sulit karena tidak ada cara yang bagus untuk melakukannya. Anda dapat mengambil opsi nuklir dan melakukan penulisan ulang lengkap dari bawah ke atas dalam bahasa/kerangka/versi baru (lihat apa yang kami lakukan antara Divi 2 dan Divi 3.0, dari Backbone.js ke React). Namun, ini masih belum sepenuhnya menyelesaikan masalah hutang, karena Anda masih memiliki orang yang menggunakan perpustakaan lama. Pada titik tertentu, Anda harus menghentikan dukungan untuk basis kode lama. Yang seperti membayar kembali pinjaman. Sampai Anda harus mengambil yang berikutnya.

Jika itu bukan pilihan (atau ide terbaik untuk Anda), Anda dapat memastikan bahwa Anda tidak mengandalkan fitur khusus bahasa atau versi. Pengembang front-end harus menghadapi ini sepanjang waktu, karena beberapa browser mendukung fitur baru dengan cepat, sementara yang lain (Microsoft Edge/IE, batuk batuk) mungkin tidak akan pernah mengadopsinya. Anda dapat membuktikan proyek Anda di masa depan dengan tetap berpegang pada dasar-dasarnya, yang pada gilirannya akan membuat jumlah perubahan yang perlu ditangani saat memutakhirkan atau memfaktorkan ulang lebih sedikit daripada yang seharusnya.

Mempertimbangkan Banyak Pengembang Seiring Waktu

Ini adalah jenis hutang teknologi yang cenderung diperoleh tim besar dari waktu ke waktu lebih buruk daripada tim pengembang kecil. Meskipun bahkan yang kecil pun perlu mengkhawatirkannya. Soalnya, setiap software engineer menulis kode secara berbeda. Sangat jarang Anda memiliki dua pengembang yang memecahkan masalah yang sama dengan kode yang sama persis. Mereka mungkin melakukan fungsi yang sama, dan hasil akhirnya mungkin sama, tetapi kodenya akan ditulis dengan suara penulis (seperti Anda dapat mengetahui siapa yang menulis posting di sini, misalnya, seperti Jason, Nathan, Donjete, dan Saya semua memiliki gaya yang berbeda). Kode tidak berbeda.

Dengan mengingat hal itu, logika terkadang juga memiliki suara yang berbeda. Apa yang menurut satu dev sangat jelas, dev lain akan melihat dan tidak tahu mengapa kode melakukan apa yang dilakukannya. Masalah ini menjadi benar-benar bermasalah ketika penulis asli tidak lagi tersedia untuk berkonsultasi. Utang teknis yang ditimbulkan oleh ini bisa menjadi bencana besar. Tapi ada cara untuk mengatasinya.

Membayar Kembali Hutang Teknis Pengembang Lama

Cara termudah adalah dengan menyewa pengembang terbaik dan tidak pernah membiarkan mereka meninggalkan perusahaan Anda. Pernah.

Karena itu tidak akan terjadi sekitar 100% dari waktu, membayar kembali hutang ini dapat dikurangi sedikit lebih mudah dari yang Anda kira. Pertama-tama, pastikan Anda melatih tim pengembang Anda untuk mengomentari kode mereka. Dan untuk berkomentar dengan baik. Kapan pun mereka membuat keputusan yang bahkan mungkin dianggap ambigu oleh orang lain, mintalah mereka mencatat mengapa mereka melakukannya dan bagaimana fungsinya bekerja.

Selain itu, pastikan bahwa setiap pengembang di tim Anda mengikuti panduan gaya atau serangkaian standar. Core WordPress memiliki seperangkat standar pengkodean yang akan menjaga plugin, tema, dan kontribusi Core tetap inline sehingga siapa pun yang datang nanti tidak akan mengalami masalah dengannya. Airbnb memiliki panduan gaya untuk React yang telah diadopsi sebagai standar tidak resmi di seluruh industri. Bahkan panduan dan standar gaya internal menjaga devs Anda dari melangkah terlalu jauh sendiri karena komit semacam itu tidak akan digabungkan kecuali mereka siap untuk dihabisi.

Membungkus

Utang teknis adalah masalah yang sangat nyata. Ini juga merupakan sumber daya yang sangat nyata jika Anda tahu cara mengelolanya. Dengan mampu memutuskan kapan Anda mengambil utang teknologi dan bagaimana Anda membayarnya kembali, pengembangan Anda bisa berjalan lebih cepat dan lancar daripada yang mungkin. Dan pada saat-saat ketika memikul beban itu tidak dapat dihindari, kami berharap bahwa kami telah memberi Anda beberapa ide tentang strategi yang dapat Anda terapkan untuk membuatnya kurang berdampak daripada yang seharusnya.

Bagaimana Anda menangani utang teknis dalam proyek dan tim pengembang Anda?

Gambar unggulan artikel oleh Andrey Suslov/ shutterstock.com