Pada saat membuat sebuah program maupun software, seringkali muncul masalah-masalah yang menyebabkan prosesnya terhambat. Munculnya masalah-masalah tersebut adalah bentuk technical debt dan harus diselesaikan oleh seorang developer. Pada dasarnya, seorang developer harus bisa menyeimbangkan antara mendesain aplikasi serta melakukan coding dengan sempurna. Akan tetapi dalam dunia bisnis, tenggat waktu dan sumber daya yang terbatas seringkali menghalangi developer untuk menghasilkan kode yang sempurna sebelum mengubahnya menjadi produk.
Mengutip dari Product Plan, technical debt adalah ‘utang’ yang muncul pada saat seorang developer memprioritaskan proses rilis sebuah proyek (yang sudah berfungsi sebagian besar) daripada menyempurnakan proses coding-nya. Dengan kata lain, proses tersebut membuat sebuah proyek harus mengalami refactoring maupun restrukturisasi kode tanpa mengganggu fungsi utamanya. Istilah yang dikenal juga sebagai tech debt maupun code debt tersebut pertama kali diperkenalkan oleh Ward Cunningham. Cunningham merupakan seorang software developer yang dikenal sebagai salah satu pendiri Wiki dan penulis Agile Manifesto. Cunningham pertama kali menggunakan istilah tersebut untuk menjelaskan kepada pemangku kepentingan non-teknis di WyCash mengapa sumber daya perlu dianggarkan untuk refactoring produk. Dibawah ini merupakan tanda-tanda sebuah produk mempunyai tech debt. -Tingkat kerumitan yang lebih tinggi pada saat teknologi saling tumpang tindih. -Bug sebuah produk yang akan menyebabkan seluruh sistem crash. -Masalah gaya pengkodean produk. -Masalah persyaratan non-fungsional di mana kode melanggar batasan. Contohnya yaitu kinerja yang lambat, masalah keamanan, hasil kode yang tidak bisa diandalkan, serta hilangnya kompatibilitas dengan sistem dan device lain.
Deadline Pekerjaan yang sudah mendekati deadline dan tidak ada waktu untuk mendesain arsitektur yang sempurna dan melakukan banyak case untuk testing. Bad Design Desain sistem yang sudah buruk dari awal akan menyebabkan sulitnya penambahan fitur baru, dan apabila bisa dilakukan pun akan menyebabkan masalah yang semakin kompleks. Poor skill Kurangnya skill coding, kurangnya pelatihan serta pemahaman tentang coding dan design pattern, tidak adanya senior maupun tech lead yang me-review setiap code yang dibuat akan menyebabkan Technical Debt. Tekanan untuk segera ter-deliver Manajemen proyek dengan timeline yang singkat akan tetapi tidak seimbang dengan banyaknya task yang harus selesai merupakan menjadi salah satu penyebab terbesar adanya Technical Debt. Accelerate Velocity Pada titik ini kita diharuskan mengambil keputusan antara memotong scope atau menambah waktu rilis sebuah project. Akan tetapi manajemen tim biasanya menolak kedua opsi tersebut dan tetap mengharuskan sistem berjalan dengan semua fitur dan dengan waktu yang telah ditentukan. Disini development team dituntut untuk mempercepat kecepatan untuk dapat mencapai release date. Dengan bekerja seperti ini, development team akan dengan tidak sengaja melakukan Technical Debt. Mungkin saja desain sistem tidak akan sebagus yang semestinya, serta beberapa testing sistem tidak akan selengkap semestinya. Sedikit testing Mitos yang sering kita jumpai bahwa dalam memperbanyak testing adalah penambahan waktu. Dengan menguranginya kita bisa mempercepat velocity. Akan tetapi realitanya tidak seperti itu, pengurangan testing justru akan menambah Technical Debt. Best practice nya adalah dengan melakukan TDD (Test Driven Development). Technical Debt dibangun dari Technical Debt Technical Debt untuk masa yang akan datang terbentuk dari Technical Debt pada saat ini yang dibiarkan. Hal tersebut dapat terjadi pada saat kita tidak melakukan perbaikan apapun dan masalah menjadi kompleks.
Technical Debt yang telah terbentuk harus segera diatasi sebelum menjadi semakin kompleks dan akan menyebabkan banyak masalah. Hal-hal yang bisa kita lakukan untuk menghilangkan Technical Debt seperti: -Identifikasi existing Technical Debt Mengidentifikasi Technical Debt bisa menggunakan tool seperti SonarQube. SonarQube bisa membantu mengkategorikan Technical Debt seperti duplication, rule violation, code coverage, complexity, documentation dan lain sebagainya, dan menyediakan bentuk visual Technical Debt serta rencana untuk memperbaikinya. Metode lain kita bisa menggunakan SCALE (Software Quality Assessment based on Lifecycle Expectation) yang mengkategorikan hal-hal seperti changeability, maintainability, security, reliability, testability, efficiency, dan portability. SCALE juga tersedia sebagai plugin pada SonarQube. -Klarifikasi sejelas mungkin tentang sumber masalah yang menjadi penyebab Technical Debt termasuk tujuan bisnis, source code, testing, design serta infrastruktur. -Analisa mana Technical Debt yang ringan maupun yang berat. Yang membutuhkan waktu lama serta yang membutuhkan sedikit waktu. Prioritaskan terlebih dahulu yang memang lebih butuh untuk segera diperbaiki. -Pilih solusi terbaik untuk setiap Technical Debt: eliminate, reduce, maupun mitigate. -Praktikan development yang bisa mengurangi Technical Debt seperti Agile. Agile akan mengurangi cakupan yang akan dirilis dengan waktu yang telah ditentukan sendiri oleh tim dev jika dibandingkan dengan merilis sistem yang besar dengan fungsi yang banyak dan dengan estimasi waktu dari Project Manager. Di dalam Agile kita bisa menyisipkan task-task kecil untuk mengurangi maupun melakukan refactoring terhadap Technical Debt yang ada. -Memonitor Technical Debt Setelah sedikit demi sedikit Technical Debt dapat dikurangi, tetaplah untuk melakukan monitoring. Apakah Technical Debt benar-benar berkurang atau malah menyebabkan Technical Debt yang lainnya. Pastikan juga perbaikan Technical Debt tidak akan mengganggu berjalannya sistem.
Tidak ada solusi yang singkat untuk menangani tech debt tersebut. Hal pertama yang dilakukan adalah dokumentasi tech debt. Dalam mendokumentasikan tech debt merupakan hal yang wajib untuk engineer. Setelah itu urutkan berdasarkan dengan impact dan effort-nya. Kemudian ajukan serta presentasikan ke product team untuk meminta waktu refactoring di dalam product roadmap. Apakah semudah itu? tidak juga. Kita juga harus bisa menerjemahkan manfaat teknis dari refactoring yang akan kita lakukan ke dalam kepentingan bisnis dan produk. Hal tersebut sangat penting, karena pada saat antar-stakeholder sama-sama mengerti konteks, urgency, dan mendapatkan nilai yang lebih dari sebuah refactoring, maka akan lebih mudah untuk product team memprioritaskan antara fitur atau refactoring. Strategi pertama yang perlu kita lakukan adalah menyisipkan waktu 30% di tiap sprint untuk tech debt. Satu sprint biasanya mengalokasikan waktu 2 minggu yang dibagi menjadi 7 hari development dan 3 hari QA testing. Berarti kita dapat memakai 2 hari kerja itu tech debt di setiap sprint. Akan tetapi untuk menyelesaikan tech debt yang kompleks, 30% tiap sprint itu sangatlah kurang serta sulit untuk memecah pekerjaannya untuk tiap sprint. Strategi kedua yang kita lakukan sekarang adalah tech debt memiliki wadah sendiri yang dinamakan dengan sprint cooldown dan dieksekusi pada tiap kuartal, dengan 1 sprint yang berdurasi 2 minggu (bisa lebih atau bisa kurang, tergantung dengan pekerjaan refactoring apa yang kita angkat dan seberapa besar impact-nya). Siklus cooldown tersebut cukup efektif apabila dilakukan secara konsisten. Ingat, tidak ada yang namanya stop development berbulan-bulan untuk refactoring atau kita akan kehilangan market share dan keluar dari kompetisi bisnis itu sendiri. Selain dari sprint cooldown yang kita miliki, pada engineering team juga menerapkan sebuah peraturan yang sederhana yang sangat berguna untuk tech debt yang sifat nya kecil-kecil.
Deliberate technical debt Dikutip dari Hackernoon deliberate technical debt merujuk kepada keadaan di mana seorang developer dengan sengaja melakukan sebuah “kesalahan” agar produk dapat diluncurkan dengan segera ke pasar. Adapun pertimbangan untuk melakukan hal tersebut yakni berapa banyak waktu yang dapat dihemat dengan segera meluncurkannya serta apa yang harus dilakukan untuk dapat menyelesaikan “kesalahan” tersebut. Contoh misalnya, seorang developer dengan sengaja menunda coding yang perlu diselesaikan sehingga akan muncul utang tersebut pada backlog-nya. Utang ini harus dilacak serta dilunasi secara terstruktur supaya tidak menjadi sebuah masalah besar di kemudian hari. Pemilik produk serta pemangku kepentingan (stakeholders) harus bertanggung jawab atas utang tersebut pada saat produk diluncurkan. Accidental/outdated design tech debt Utang tersebut muncul pada saat developer mencoba untuk menyeimbangkan rencana serta desain produk dengan kesederhanaan serta proses rilis yang cepat. Pada saat sistem berkembang serta persyaratan berubah, developer mungkin akan menemukan kecacatan pada desain, maupun fungsi baru jadi lebih sulit diterapkan. Desain orisinal yang baik seringkali memudahkan proses refactoring secara bertahap, akan tetapi terkadang harus dilakukan secara signifikan. Utang dan proses refactoring kadang akan menjadi masalah besar, namun hal ini adalah hal yang lumrah yang akan terjadi secara berkala. Umumnya proses refactoring bisa dilakukan pada saat sebuah sistem maupun program dalam keadaan stabil. Bit rot technical debt Bit rot tech debt bisa terjadi seiring dengan berjalannya waktu karena sebuah komponen maupun sistem secara perlahan akan berubah dan akan semakin kompleks melalui banyaknya perubahan serta tambahan. Akan tetapi, jenis utang ini sering kali memburuk pada saat program dikerjakan oleh beberapa orang yang mungkin saja tidak sepenuhnya memahami mengenai desain aslinya. Masalah tersebut dapat ditandai dengan adanya copy-paste dan cargo-cult programming. Ini mungkin saja merupakan satu-satunya jenis tech debt yang harus dihindari secara konsisten dengan refactoring yang berkelanjutan. Untuk tim developer sebaiknya meluangkan waktu untuk memahami desain sistem yang sedang mereka kerjakan, serta secara bertahap untuk merapikan kode-kodenya.
Pada saat menambahkan fitur Pada saat menambahkan fitur baru dan fitur tersebut dibangun diatas Technical Debt, cobalah untuk mem-fixing Technical Debt nya terlebih dahulu setelah itu tambahkan fitur baru yang lebih clean code serta tanpa Technical Debt. Hal tersebut apabila dilakukan secara terus menerus akan mengurangi Technical Debt yang ada. Dan apabila kita tetap membangun fitur baru dan mengabaikan Technical Debt, terdapat kemungkinan fitur kita juga akan menjadi Technical Debt dan akan lebih menyusahkan untuk developer selanjutnya. Pada saat bug fixing Bug fixing merupakan saat yang tepat untuk clean kode yang sudah ada. Pada saat kita membenarkan bugs maka sekalian saja untuk merapikan kode nya juga untuk mengurangi Technical Debt. Pada saat Code Review Code Review sangatlah dibutuhkan untuk mereka yang baru di dunia coding. Dengan Code Review yang dilakukan oleh senior maupun Tech Lead maka akan ditemukan kesalahan-kesalahan pada seorang developer saat coding. Dan disini dapat menghilangkan hal-hal yang akan menyebabkan code menjadi Technical Debt.
Kesempatan lowongan magang terbaru di tahun 2024
Baca Selengkapnya..